MCP : Model Context Protocol
How LLMs connect with tools, data and the outside world
Meaning :
Model - Model here refers to the LLM models like GPT, Gemini, Claude etc.
Context - Context means the information given to the model that it can use to understand and perform the given task. This can include the conversation, user information, files, or information provided by external sources.
Protocol - Protocol is just a set of predefined rules or a standard for how something should work or communicate.
Problem Statement :
So the problem with normal LLMs is that at their core, they generate text by predicting what should come next based on the information they learned during training. They are extremely good at this, so sometimes it feels like they know everything.
But their knowledge mainly comes from their training data, which cannot be updated every time something changes. So they don't automatically know the latest information, and they cannot directly perform external tasks like sending an email, fetching something from your database, checking current weather etc.
The important thing is that the model can understand what needs to be done and decide what kind of action is required, but it needs some way to actually perform that action.
So what if we give the LLM a way to do these things, like searching the internet, sending emails, fetching data from a database, checking the weather etc?
Basically, the LLM can have "hands" along with its "brain" now, so it can do more than just generate text.
Before MCP :
This problem was solved long before MCP came up.
The problem was that there was no common standard for connecting LLM applications with external tools and data. Different model providers and SDKs had their own ways of doing it.
This could become frustrating for developers. For example, if you wanted to build an application that supports multiple model providers, you might have to write different integrations for the same tool depending on the provider.
For example, let's say you want to fetch weather data for a given city.
You could have one way of connecting the weather function with OpenAI, another way with Google Gemini, another way with Claude, and so on.
MCP introduced a common standard for these connections, making it easier for different applications and tools to communicate.
Tools: We can think of a tool as a function that can perform some specific task. For instance, we can write a function to fetch weather data for a given city through an API call. We can expose this function as a tool and provide information about what it does and what input it needs, so the LLM can decide when it should use it.
Mental Model Before moving to MCP -
If you are wondering how an LLM can call a function or make an external request, think about how we normally build software.
We create helper functions, APIs or controllers, and something in our application calls them when a particular event happens. For example, when a user clicks a button, the browser sends a request and the required function gets executed.
A similar idea can be used with LLMs.
The LLM understands the user's query and can decide whether it needs to use a particular tool. The developer provides information about the tool, such as what it does and what input it needs.
The tool does the actual work and returns the result. The LLM then uses that result to answer the user.
Introducing MCP :
In November 2024, Anthropic introduced MCP (Model Context Protocol). MCP is an open standard for connecting applications with external data sources and tools. It provides a common way for applications to access things like files, databases, APIs and other services.
What can MCP enable?
Agents can access your Google Calendar and Email, making them more useful as personal assistants and helping automate everyday tasks.
Your coding tool can connect with a Figma design and use that information while building an application.
An organization can connect its application to multiple databases and give users information from those systems.
You can connect applications to smart devices and other external services, allowing them to perform actions through those systems.
MCP Components :
MCP Host
The application where you are using the LLM.
MCP Client
The part inside the host that communicates with the MCP server.
MCP Server
The server that provides tools and resources, and connects to external services such as databases, email, calendars, etc.
The server handles the actual connection to those external systems and exposes the available capabilities in a standard format that the MCP client can understand.
Transport Layer :
As you can see above, the MCP client and MCP server need a way to communicate with each other. This is where the transport layer comes in.
Standard input/output (stdio): Mostly used when the MCP server is running locally. The client can start the server as a local process and communicate with it through standard input and output.
Streamable HTTP: Used when the MCP server is running remotely. It allows the client and server to communicate over HTTP. It replaced the older HTTP + SSE transport in newer versions of the MCP specification.
How does MCP work?
The Model Context Protocol allows an application to connect an LLM with external tools and data to complete a user's task.
Imagine you ask an application:
"Find me the weather data for Delhi."
Here is a simple version of what can happen:
Request and tool discovery: The application knows about the tools available through its MCP server. It finds a relevant tool like
fetchWeatherData().Tool invocation: The LLM decides that it needs the weather tool and provides the required input, in this case the city name.
External action and data return: The MCP client sends the request to the MCP server. The MCP server uses the connected weather API and gets the weather data.
Result goes back: The result is sent back through the MCP connection to the application, which gives it to the LLM.
Final response: The LLM now has the weather data and can generate a response for the user.
Benefits of using MCP :
MCP provides several advantages to make your life easier -
Reduce Hallucination - When the model needs information that can change, it can use the appropriate tool or resource instead of depending only on its training data. This can make the response more accurate, although MCP itself does not guarantee that the model will always be correct.
More Personalized and Time Saving - Applications can connect the model to useful information and services, so it can perform tasks using the user's actual data instead of only giving general answers. This can save time when the same work would otherwise have to be done manually.
Increased Utility and Automation - Instead of only generating text, applications can connect the model to tools that allow it to perform useful actions. For example, it can retrieve information, update something, search data or interact with other software when the application allows it.
Easier Connections - As we discussed earlier, before MCP, developers often had to build different integrations for different systems. MCP provides a common standard for these connections, which can make development simpler and reduce the amount of custom integration work.
A Practical Problem : Too Many Tools
MCP makes it easy to connect many tools, but connecting everything at once can create another problem.
Imagine your application has 200 tools connected. If the descriptions and details of all those tools are loaded when the conversation starts, it can use a lot of context, increase latency, and increase the cost of each request.
So instead of giving the model every tool at once, we can use a gateway or similar tool-routing layer.
The gateway can sit between the application and many MCP servers and expose only the tools that are actually needed for the current task.
For example:
User asks about GitHub → Gateway exposes GitHub tools
User asks about Calendar → Gateway exposes Calendar tools
User asks about Weather → Gateway exposes Weather tools
This keeps the available tools smaller and can make the system more efficient.
So MCP solves the problem of how applications connect to tools, while a gateway or routing layer can help manage which tools should be available at a given time.
What About the Security (MCP Security) :
While MCP improves what an application can do by connecting it to outside systems and tools, it also introduces security risks.
If an application can access files, databases or other services, we need to make sure that access is properly controlled.
Some important security points are:
User consent and control: Users should understand what data is being accessed and what actions are being performed. They should have control over which actions are allowed.
Data privacy: Sensitive user data should only be shared when necessary and with proper access controls. Developers should make sure that an external server cannot access more data than it actually needs.
Tool safety: Tools can perform real actions, so developers should understand what a tool actually does before connecting it. Don't blindly trust an unknown MCP server or tool just because its description says it is safe.
Secure output handling: Data returned from tools should be handled safely before being shown or used by the application. Normal security practices such as input validation and output escaping are still important.
Supply chain security: The MCP servers and external services you connect to also need to be trusted and maintained properly. A compromised server or tool can become a security risk for the whole application.
Monitoring and auditing: Logging tool usage and important actions can help developers understand what happened and detect unusual or unwanted activity.
By following these principles, developers can use MCP while keeping better control over the data and actions connected to their applications.
MCP vs RAG -
RAG is mainly used when you want to give the model additional information from your own documents or knowledge base so it can answer based on that information.
MCP is a standard way for an application to connect the model with external tools and data sources.
So in very simple words:
RAG = "Here is some information, use it."
MCP = "Here are some tools and resources, use them when needed."
RAG and MCP are not the same thing. They solve different problems, and you can even use both together in the same application.
