I explain the Model Context Protocol or MCP used to interact with LLMs

One of the most convenient uses of LLMs is to use them to analyse or process our own data, for which there are several options, such as LLM fine-tuning or RAG, or manually passing our data as context as part of the prompt.

Anthropic members noticed this and proposed to standardise this process by creating a protocol for providing context to LLMs. This protocol, called the Model Context Protocol, is being sold as the next AI revolution, will it be another AI bubble or a completely groundbreaking paradigm?

MCP exists to act as a bridge between an LLM and contextual information, in a standardised and agnostic way. The key word here is standardisation.

How does the Model Context Protocol or MCP work?

The MCP conforms to a client-server architecture.

Client role in MCP

A client that implements the Model Context Protocol can connect to an LLM and a set of MCP services or servers that provide it with the appropriate context it needs.

A MCP client represents the user interface to which we would normally pass our prompts; this interface may be Claude Desktop or some other equivalent.

Server role in MCP

A server is responsible for reading information, whether from a file, a database, a web service (via an API), or any other accessible source. To do this, it will use certain predefined resources or tools that restrict what the client can or cannot read or do.

How does the MCP know what it can read or do from a server?

To know what resources a service or server can access or modify, they implement a similar functionality Reflect in Go and GraphQL , with which they expose information about themselves.

For example, in the CCM Github repository we see the list of actions that can be performed, as well as the required inputs for each of them.

Internally there is no magic at all, the services interact with the servers or information sources through their respective APIs. Take a look at the code that executes the listCommits action shown in the image above.

Notice how there is an initial validation using the familiar Zod library, but at the end of the snippet there is a function call that makes a request to a Github URL.

import { z } from "zod";
import { githubRequest, buildUrl } from "../common/utils.js";

export const ListCommitsSchema = z.object({
  owner: z.string(),
  repo: z.string(),
  sha: z.string().optional(),
  page: z.number().optional(),
  perPage: z.number().optional()
});

export async function listCommits(
  owner: string,
  repo: string,
  page?: number,
  perPage?: number,
  sha?: string
) {
  return githubRequest(
    buildUrl(`https://api.github.com/repos/${owner}/${repo}/commits`, {
      page: page?.toString(),
      per_page: perPage?.toString(),
      sha
    })
  );
}

So far I have been talking about resources and actions, but in the CMP these two actions which are in charge of giving context to an LLM have names. Of course they were not going to miss the opportunity to give some branding to their protocol.

Context types: Resources and Tools in the Model Context Protocol

The MCP context types are divided into:

• Resources.
• Tools.
• Sampling, performs queries to other models, less common.
• Prompts, prompts templates, less common.

What is the Resources context type?

You can think of Resources as a GET request to a REST API , intended to get information, without modifying anything.

What is the type of context Tools?

On the other hand, a tool would be the equivalent of a POST, UPDATE, DELETE or PATCH request.

Think of tools as a mechanism to allow a client to make modifications to your servers or services.

If you are more familiar with GraphQL-like APIs , you can think of resources and tools as queries and mutations, respectively.

How does the MCP communicate with servers?

The MCP has two communication paradigms, one is via STDIO or Standard Input Output, right out of your C programming nightmares #include <stdio.h> ideal for local communication, for example with a local database such as Postgres or SQLite.

The other type is SSE or Server Sent Events, which does POST request streaming (similar to the gRPC streaming requests I’ve already told you about ), ideal of course for communications that are not in the same environment.

The MCP protocol is stateful

Another aspect worth noting is that, to date, the protocol requires a persistent connection between client and server , so this can be a drawback for auto-scalable architectures that adapt to demand, as well as moving in the opposite direction in a world that is striving to become stateless.

Just as a reminder:

At the moment it is a matter of debate whether it will stay that way, there is no certainty whether stateless versions will be implemented or if there will be changes to it. After all, this protocol is new and who knows what the future holds for the AI world, giants can rise and fall in months, as Devin AI and Rabbit R1 did.

If you want to know more read the official Model Context Protocol documentation and the introduction to the MCP