With an open, plug-and-play architecture, MCP is the key to enabling AI agents to interact seamlessly with external tools and real-world data.
What is the Model Context Protocol? MCP defined
The Model Context Protocol (MCP) is an open source framework that aims to provide a standard way for AI systems, like large language models (LLMs), to interact with other tools, computing services, and sources of data. Helping generative AI tools and AI agents interact with the world outside themselves on their own is a key to allowing autonomous AI to take on real-world tasks. But it has been a difficult goal for AI developers to realize at scale, with much effort being put into complex, bespoke code that connects AI systems to databases, file systems, and other tools.
Several protocols have emerged recently that aim to solve this problem. MCP in particular has been adopted at an increasingly brisk pace since it was introduced by Anthropic in November 2024. With MCP, intermediary client and server programs handle the communication between AI systems and external tools or data, providing a standardized messaging format and set of interfaces that developers use for integration. In this article, we’ll introduce you to the Model Context Protocol and talk about its impact on the world of AI.
What is an MCP server?
Before diving into the details of the different building blocks of MCP architecture, we first need to define the MCP server, since it has become nearly synonymous with the protocol itself. An MCP server is a lightweight program that sits between an AI system and some other service or data source. The server acts as a bridge, communicating with the AI (via an MCP client) in a standardized format defined by the Model Context Protocol, and with the other service or data source via whatever programmatic interface it exposes.
MCP servers are relatively simple to build. A wide variety of them, which can do anything from interact with a database to get the latest weather reports, are available on GitHub and elsewhere. The vast majority are free to download and use (though paid MCP servers also are emerging). This is part of what has made MCP so popular so quickly: Developers and users of all sorts of AI systems found that they could use these readily available MCP servers for a variety of tasks. And that widespread adoption was made possible by the way that MCP servers connect to the AI tools themselves.
MCP vs. RAG vs. function calling
MCP isn’t the first technique developed to connect AIs to the outside world. For instance, if you want an LLM to integrate documents that aren’t part of its training data into its responses, you can use retrieval augmented generation (RAG), though that involves encoding the target data into a vector-formatted database.
Many LLMs are also capable of what’s variously known as function calling or tool use. The LLMs can recognize when a user prompt or other input is requesting functionality that requires the use of a helper tool, and instead of a natural language response, it would instead provide the appropriate commands to invoke that tool. So, for instance, if you asked a general-purpose chatbot about the climate in Los Angeles, it could almost certainly give you all that information from its training data; but if you asked it what the weather in Los Angeles was going to be tomorrow, it would need to connect to a service that provides weather forecasting data.
This connection task was far from impossible: After all, LLMs are at the heart text generators, and the commands these services expect take the form of text. But building out the tools necessary to connect LLMs to outside services turned out to be a daunting task, and many developers found themselves reinventing the wheel each time they had to code a connector.
“If you were doing tool calling a year ago, every agentic framework had its own tool definition,” says Roy Derks, Principal Product Manager, Developer Experience and Agents at IBM. “So if you switched frameworks, you’d have to redo your tools. And since tools are just mappings to APIs, databases, or whatever, it was hard to share them.”
MCP builds on LLMs’ capability to make function calls, providing a much more standardized way to connect to services and data sources. “The LLM is not aware of MCP,” Derks says. “It only sees a list of tools. Your agentic loop, however, knows the mapping of the tool name to MCP, so it knows MCP is my mode of calling tools. If my get-weather tool is being called or suggested by the large language model, it knows it should call the get-weather tool and then—if this happens to be a tool from an MCP server—it uses the MCP client-server connection to make that tool call.”
MCP architecture: How MCP works
Now we’re ready to take look in more detail at the different components that make up the MCP architecture and how they work together.
- An MCP host is the AI-based application that will be connecting to the outside world. When Anthropic rolled out MCP, the company built it into the Claude desktop application, which became one of the first MCP hosts. But hosts aren’t limited to LLM chatbots—an AI-enhanced IDE could serve as a host as well, for instance. A host program includes the core LLM along with a variety of helper programs.
- An MCP client is, for our purposes, the most important of these helpers. Each LLM needs a client that has been customized to accommodate the way it calls tools and consumes data. However, all MCP clients provide a standard set of services to their hosts. They discover accessible servers and report back on those services and the parameters required to call them, all of which information goes into the LLM’s prompt context. When the LLM recognizes user input that should trigger a call to an available service, it uses the client to send out a request for that service to the appropriate MCP server.
- We’ve already discussed the MCP server, but now you have a better sense of how it fits into the bigger picture. Each server is built to communicate with a data source or external service in a language that data source or service understands, and communicates with the MCP client in accordance with the Model Context Protocol, serving as a middleman between the two.
- The MCP client and MCP server communicate with one another using a JSON-based format. The MCP transport layer converts MCP protocol messages into JSON-RPC format for transmission and converts JSON-RPC messages back into MCP protocol messages on the receiving end. Note that a server might run locally on the same machine as the client, or might run online and accept client connections over the internet. In the former scenario client-server communications take place via stdio, and in the latter via streamable HTTP.
The figure below illustrates how these components all work together. As noted, servers can run either locally or remotely to clients, and servers can connect to either local or remote services.
MCP server ecosystem
The increasing popularity of MCP is largely due to the wide variety of servers available free of charge to anyone who wants to use them. And while having all these components in the architecture might at first seem more complex than simply connecting an LLM directly to an outside service, MCP’s modularity, portability, and standardization make everything much easier for developers:
- An MCP server can communicate with any AI application that includes a properly implemented MCP client. That means that if you want to expose your service for access by AI agents, you can write a single server and know it will work across different types of LLMs.
- Conversely, while an MCP client must be tailored to a specific host, it can connect to any properly implemented MCP server. There is no need to figure out how to connect your specific LLM to Google Docs, or to a MySQL database, or to a weather forecasting service. You just need to create an MCP client and it can, via MCP servers, connect to services of all types.
To take a deep dive into the ecosystem of MCP servers, check out the Model Context Protocol servers GitHub repo.
MCP security issues
Just about any method that opens up new lines of communication also provides potential new avenues for attackers. When MCP first launched, it mandated session identifiers in URLs, a big security no-no. MCP originally also lacked message signing or verification mechanisms, which allows for message tampering.
Many of these vulnerabilities have been patched in subsequent updates, but there are others that are harder to eliminate. Plus, the fact that so many people simply use MCP servers they find online increases the risk of servers that are misconfigured or plain malicious going into production. For more on this topic, read “MCP is fueling agentic AI—and introducing new security risks” at CSO Online.
What’s ahead for MCP?
Nevertheless, MCP’s utility and ease of use is overriding security concerns and ensuring that the technology will be around for some time to come. What’s on the horizon for this protocol? IBM’s Derks says that enterprises are starting to build tools and come up with strategies to manage proliferating MCP servers that AI agents will be making use of.
“One interesting pattern is the composition and orchestration of MCP servers,” Derks says. “What we see a lot is, instead of people connecting multiple MCP servers to a single client, they orchestrate multiple MCP servers into a single server and then connect that server to a client. If you think about clients on the left and servers on the right, there are some patterns emerging on the right to reduce the number of MCP servers needed, so as to reduce clutter—because if you provide 100 tools to a model, it’s going to get confused.
“That’s what I see a lot of the enterprise interest moving towards,” Derks adds. “How do you orchestrate and arrange all these servers, rather than how do you build the best possible client.” MCP is still in its early days, but expect enterprises to adapt quickly to keep up.
—
