Mi Explicación Del Model Context Protocol (MCP) para interactuar con LLMs

Uno de los usos más útiles de los LLM es consultarles sobre nuestros propios datos, para eso hay varias opciones, tales como realizar fine-tuning de un LLM o RAG o pasárselos como contexto en la petición.

Los integrantes de Anthropic proponen estandarizar este proceso y crear un protocolo para dotar de contexto a los LLM. Este protocolo, de nombre Model Context Protocol, se vende como la siguiente revolución de AI, ¿será esta otra burbuja de AI o una afirmación completamente fiel a la realidad?

MCP existe para servir como un puente entre un LLM y la información relacionada al contexto, esto de una forma estandarizada y agnóstica. Aquí la palabra clave es “estandarización”.

¿Cómo funciona el Model Context Protocol o MCP?

El MCP se ajusta a una arquitectura de cliente-servidor.

Rol del cliente en el MCP

Un cliente que implemente el Model Context Protocol puede conectarse a un LLM y a una serie de servicios o servers MCP que le proveeran de la información de contexto que necesita.

El cliente representa la interfaz de usuario a la que nosotros le pasaremos nuestros prompts, esta interfaz puede ser Claude Desktop o alguna otra opción.

Rol de un server en el MCP

Un server se encargará de leer información, ya sea un archivo, una base de datos, un servicio web (por medio de una API) o cualquier otro origen que sea accesible. Para hacerlo echará de mano de ciertos recursos o herramientas previamente predefinidos, que restringen lo que el cliente puede o no puede leer o hacer.

¿Cómo sabe el MCP qué puede leer o hacer de un server?

Para saber que recursos puede leer o modificar un servicio o server, estos implementan una funcionalidad similar ´ Reflect en Go y GraphQL , con la cual exponen información sobre ellos mismos.

Por ejemplo en el repositorio de Github del MCP vemos la lista de acciones que se pueden llevar a cabo, así como los inputs requeridos para ello.

Internamente no hay nada mágico, los servicios interactuan con los servidores o fuentes de información por medio de sus respectivas APIs. Observa el código que lleva a cabo la acción listCommits que aparece en la imagen de arriba.

Aprecia como hay una validación inicial usando la conocida librería Zod, pero al final existe una llamada a una función para realizar una petición a una URL de Github.

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
    })
  );
}

Hasta ahora he estado hablando de recursos y acciones, pero en el MCP estas dos acciones que se encargan de darle contexto a un LLM tienen nombres, por supuesto no iban a perder la oportunidad de darle branding a su protocolo.

Tipos de contexto: Resources y Tools

Los tipos de contexto del MCP se dividen en:

• Resources.
• Tools.
• Sampling, realiza queries a otros modelos, menos común.
• Prompts, plantillas de promps, menos común

¿Cuál es el tipo de contexto Resources?

Puedes pensar en los Resources como una petición GET de una API REST , destinada a obtener información, sin modificar nada.

¿Cuál es el tipo de contexto Tools?

Por otro lado, una tool sería el equivalente de una petición POST, UPDATE, DELETE o PATCH.

Piensa en las tools un mecanismo para permitir que un cliente realice modificaciones en tu servidor o servicio.

Si te sientes más familiarizado con APIs del tipo GraphQL , puedes pensar en resources y tools como queries y mutations, respectivamente.

¿Cómo se comunica el MCP con los servers?

El MCP tiene dos paradigmas de comunicación, uno de ellos es por medio del STDIO, o Standard Input Output, sacado directamente de tus pesadillas programando en C #include <stdio.h> ideal para comunicaciones locales, por ejemplo con una base de datos local, como Postgres o SQL.

El otro tipo es SSE o Server Sent Events, el cual realiza streaming de peticiones POST (similar al streaming de peticiones en gRPC del que te hablé ), ideal obviamente para comunicaciones que no ocurren en el mismo entorno.

El protocolo MCP es Stateful

Otro aspecto a destacar, es que, a la fecha, el protocolo requiere una conexión persistente entre cliente y servidor , por lo que puede ser complicado para arquitecturas autoescalables que se adaptan a la demanda, además de ir completamente en contra de la corriente en un mundo que se esmera en volverse stateless.

Solo para refrescar tu memoria:

Por ahora es una discusión si permanecerá así, se implementarán versiones stateless o si habrá cambios al respecto. Después de todo este protocolo es nuevo y quien sabe que vaya a pasar en el futuro en el mundo de la AI, para ejemplos tenemos casos como el de Devin AI y Rabbit R1.

Si quieres saber más dale una leída a la documentación oficial del Model Context Protocol y la introducción al MCP