The Model Context Protocol (MCP)

The Model Context Protocol is a protocol proposed by Anthropic (Claude) that makes it easy to integrate external sources and tools into applications using LLMs. Instead of calling tools directly, the LLM calls the MCP server to enrich its context. This makes it much easier to build agents by quickly providing integration with various services that LLMs can leverage.

How does this protocol work?

There are 3 main components in the MCP protocol:

• The host, which centralizes and coordinates the various actions within the system.
• The clients, each of which communicates with a single server.
• The servers, which provide additional context and new capabilities.

Source: https://modelcontextprotocol.io

The MCP protocol is based on JSON/RPC, a JSON standard that allows calling a function on the recipient by sending a method and its parameters. Example request:

{
"jsonrpc": "2.0",
"id": 1,
"method": "roots/list"
}

Communication happens between servers and clients, and each server is treated as a tool that provides capabilities it declares. The goal of the MCP protocol is to make it easier to integrate tools into LLMs. To achieve this, creating servers is straightforward, and they can easily evolve to offer more features. We also want the capabilities offered by the various servers connected to our host to interact and complement each other seamlessly, without the servers needing to know the full context, including other servers. This isolation is important to ensure data impermeability between servers.

Let's look at how MCP components interact and what role each plays in the protocol.

The server

The server's role is to provide a number of capabilities to enrich the host's LLM. It provides 3 types of capabilities:

• Prompts
• Resources
• Tools

The prompts provided by the server are designed to be controlled by the user to help discover the server's other capabilities. Typically, this is a command the user can enter. The server associates a description with it and, if the prompt requires it, the arguments that can be passed.

Next, we have resources, which are generally files the server makes available to enrich the context of the user's request. As mentioned, this can be a file, but also a resource on the web (via URL) or a Git repository. When a server declares a resource, it also includes a description.

Finally, tools are actions the server can perform. They are intended to be used by the LLM when it needs to retrieve information or when asked to perform an action. This is exactly like the tools used with LLMs, as explained in the article on the ReAct pattern. The server also provides a description of each tool.

The server declares these capabilities to the client during protocol initialization.

The server may also need resources from the client, in which case it requests them. The client then decides what to send from the resources it has access to.

The client

The client's role is to relay requests from the host to the servers and vice versa. It handles communication with the server and also manages what the server can and cannot access. To do this, the client provides 2 types of capabilities to the server:

• Roots
• Samplings

Roots are simply the various resources/files the server will have access to. This is generally restricted to a specific folder or workspace.

Samplings are not really resources the client provides. Rather, they offer the server the ability to make a request to the system for more information. For example, the server might ask the client to provide tomorrow's weather forecast in order to return the requested information. The request can contain text, an image, or audio. The client approves or rejects the request, and if approved, it is forwarded to the host.

When making a sampling request, the server can also provide hints about which model to use, either by specifying the model name or by giving general guidance based on the importance of cost, speed, or intelligence. However, these hints are purely advisory: the client ultimately chooses which LLM will be used.

{
"hints": [
{ "name": "claude-3-sonnet" }, // Prefer Sonnet-class models
{ "name": "claude" } // Fall back to any Claude model
],
"costPriority": 0.3, // Cost is less important
"speedPriority": 0.8, // Speed is very important
"intelligencePriority": 0.5 // Moderate capability needs
}

Finally, the client is also responsible for prompting the user to confirm certain actions. In this way, it plays a dual security role: on one hand, it can hand control back to the user, and as we saw with roots, it also controls what information a server can access.

The host

Lastly, we have the host. The host's role in the MCP protocol is to orchestrate calls to the various servers based on what the application needs. It has knowledge of the entire context of a user's request and, therefore, decides what should or can be sent to each MCP server. This also means it aggregates the context it receives from different clients and redistributes it.

It also knows about all the models available to the full system. It controls the lifecycle of clients as well: it creates them and defines what each client can do. It also ensures the user's intent is respected by requesting consent for certain actions and enforcing security rules.

How does an interaction with the MCP protocol unfold?

Now that we've covered the main actors of this protocol, how does a typical interaction with MCP work?

It can be summarized with the following sequence diagram:

Source: https://modelcontextprotocol.io

What does this diagram show? During initialization, the host creates the clients it needs to interact with the servers it knows about. When a client is created, it starts a session with the server. It sends its roots and samplings during initialization, and the server responds with its prompts, resources, and tools. The client and server now know what each can do.

Then, several types of interactions are possible:

1. The host initiates an action (i.e., the user enters a prompt or a model needs information). In this case, the client best suited to handle the request (chosen by the LLM) sends a request to the server asking for a resource or calling the necessary tool. The server responds, and the client relays the information either to the model or to the user.

2. The server makes a sampling request to the client because it needs additional information. The client forwards the request to the host, which may send it to the LLM, with or without requesting user consent. It then relays the LLM's response to the client, which forwards it to the server.

3. The server or client has been updated with additional or removed capabilities, so it notifies its counterpart of these changes.

The session between the server and client only ends when the host asks the client to terminate it, or when the server cuts it off (which should be less common).

Conclusion

That's a quick overview of the MCP protocol. I've left out some details, notably the not-so-anecdotal part about authorization between client and server (note that implementing the OAuth 2.1 and 2.0 specifications is recommended). The protocol is ultimately quite simple to understand, and I believe this simplicity is what has given it a strong lead in the race to become the standard for tool definitions. Several SDKs are already available to implement and communicate with this protocol, whether in Python, JS, C#, Java, Swift, or Kotlin. The fact that several major companies, such as Microsoft with Azure or Hashicorp with Terraform, have provided MCP servers for their platforms also helps drive adoption.

If you want to learn more, I recommend the protocol's official website, which is the primary source for this article. The site is well-designed, with plenty of examples and diagrams if you want to dive into the details, as well as tutorials if you prefer a more hands-on approach.