Capítulo 2 — Desentrañando el Model Context Protocol (MCP)
Segunda entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que construimos el modelo mental — tres roles, un formato JSON-RPC, una superficie de descubrimiento dinámico y un ciclo de vida de sesión — con el cuidado suficiente como para que el resto del libro pueda apoyarse encima.
Por qué existe este capítulo
El Capítulo 1 puso nombre al problema. Éste construye el modelo mental de la respuesta. MCP se puede resumir en una frase y malinterpretar en un párrafo, así que el capítulo se toma su tiempo: qué es el protocolo a nivel de cable, qué significan los tres roles y qué posee cada uno, en qué se diferencia de una API REST en los casos que importan de verdad en producción, y qué pasa en una sesión desde la conexión hasta el cierre. El objetivo es que, al terminar, puedas predecir — antes de leer el siguiente capítulo — qué tiene que ser una primitiva de servidor, qué tiene que ser una primitiva de cliente, y por qué MCP se gana la estructura que tiene.
2.1 Qué es MCP y qué significa de verdad "USB-C para la IA"
El Model Context Protocol es una especificación abierta de cómo las aplicaciones LLM descubren, describen e invocan capacidades externas. En el cable es JSON-RPC 2.0 sobre uno de un pequeño número de transportes. A nivel arquitectónico es el contrato que permite a un host trabajar con cualquier servidor conforme sin código de integración hecho a mano. Una herramienta construida una sola vez contra el protocolo funciona con cada host que lo hable. Un host construido una sola vez contra el protocolo puede usar cada herramienta que lo hable.
La fórmula que ha cuajado es "USB-C para la IA". La forma estructural sí se parece a USB-C — un único estándar de conexión que media entre una población abierta de dispositivos y una población abierta de hosts. Los límites de la metáfora conviene nombrarlos: USB-C estandariza un conector más una pila por encima; MCP estandariza sólo el protocolo. USB-C corre a escalas de tiempo eléctricas con encuadre forzado por hardware; MCP corre a escalas de tiempo de red con encuadre definido por software, lo que le permite ser más flexible y también lo obliga a manejar conexiones caídas y pares lentos que USB-C no tiene que considerar.
Una comparación más cercana, para ingenieros, es LSP. El Language Server Protocol definió un protocolo que cualquier editor y cualquier language server pudieran hablar; MCP define uno que cualquier host LLM y cualquier proveedor de capacidades pueden hablar. La forma de la victoria es idéntica — muchos-a-muchos colapsado por un protocolo compartido en algo que escala de forma aditiva. La decisión de basar MCP en JSON-RPC 2.0 en vez de inventar un formato nuevo fue deliberada: JSON-RPC es pequeño, maduro, agnóstico al lenguaje y poco glamuroso. Las decisiones arquitectónicas interesantes no están a nivel del cable. Están en cómo Hosts, Clientes y Servidores reparten responsabilidades.
2.2 Hosts, Clientes y Servidores — qué posee cada rol
MCP define tres roles, y lo primero que conviene entender es que "Cliente" y "Servidor" no significan lo que suelen significar en otros sitios. Un Servidor expone capacidades — herramientas, recursos, prompts. Un Cliente es una única conexión hablando el protocolo con un único Servidor, administrada dentro de una aplicación más grande. La aplicación más grande es el Host. El Host posee el modelo, la sesión del usuario y la política sobre lo que el modelo tiene permitido hacer. Los Servidores poseen sus superficies de capacidad. Los Clientes son los cables entre ambos, uno por Servidor.
La división importa porque cada rol tiene responsabilidad distinta y postura de confianza distinta. El Host es la frontera de confianza que importa desde el punto de vista del usuario; todo lo demás es algo que el Host ha decidido dejar entrar. Un Host que habla con cinco Servidores tiene cinco Clientes corriendo dentro, cada uno con su propio estado de sesión, sus suscripciones y su vista de qué capacidades se han negociado. Si un Servidor se cae, el Cliente correspondiente se cae; los demás Clientes siguen vivos; el Host sigue en pie. Los Clientes son aisladores por conexión que evitan que un Servidor en mal estado envenene la sesión entera.
Hay también un argumento de seguridad en la división. Cada Servidor es, como mínimo, código escrito por otra persona. El Cliente media todo lo que el Servidor pueda hacer que afecte al Host — notificaciones, elicitaciones, peticiones de sampling, recursos publicados — y es donde corresponde la política por Servidor. Host, Cliente y Servidor son roles lógicos, no estrictamente físicos: en local el Servidor suele ser un subproceso por stdio; en un despliegue remoto es un servicio sobre transporte basado en HTTP. Al protocolo le da igual; a las fronteras de roles no.
2.3 MCP frente a REST — qué te compran el descubrimiento dinámico y las descripciones semánticas
La pregunta razonable es "¿esto no es REST?". Las diferencias no son cosméticas. Las más consecuentes son el descubrimiento dinámico, las descripciones semánticas escritas para un LLM y un modelo de mensajería bidireccional.
Una API REST publica endpoints en documentación escrita para desarrolladores humanos. El conjunto de endpoints que un cliente usa queda fijado en tiempo de compilación; los endpoints nuevos requieren redeploy. MCP invierte esto. Al inicio de la sesión, el Cliente pregunta "¿qué ofreces?" y el Servidor responde con un catálogo tipado — esquemas, descripciones, metadatos — que el host usa programáticamente. Si el Servidor añade más adelante una herramienta, una notificación listChanged actualiza al Cliente a mitad de sesión sin reinicio. El Servidor es la fuente autoritativa de verdad sobre sus propias capacidades; la descripción no puede divergir de la implementación porque no hay una copia separada del lado del cliente que pueda divergir.
Las descripciones semánticas son la segunda diferencia. Los docs de un endpoint REST se escriben para un desarrollador que va a leerlos y decidir. La descripción de una herramienta MCP se escribe para un LLM que la leerá como parte de su prompt y decidirá de forma autónoma. Una descripción que dice "POST a /users/:id/orders" no le sirve a un LLM, que necesita saber qué operación conceptual realiza la herramienta, cuándo debería preferirla, qué efectos secundarios tiene, y qué significan sus inputs en términos del dominio. El trabajo de traducir la API a términos legibles para un LLM se ha hecho una sola vez, dentro del Servidor, donde las personas más cercanas a la capacidad pueden mantenerlo.
La tercera diferencia es la bidireccionalidad. REST es petición-respuesta; la conexión se cierra. MCP es bidireccional por diseño. El Servidor puede enviar notificaciones en cualquier momento, puede iniciar peticiones de sampling de vuelta al Cliente, puede pedirle datos al usuario a mitad de flujo. Nada de esto es técnicamente imposible sobre REST. Todo resulta incómodo allí. En MCP es parte del estándar.
2.4 Negociación de capacidades y ciclo de vida de la sesión
Una sesión empieza cuando el Cliente abre un transporte y envía una petición initialize con su versión de protocolo y sus capacidades. El Servidor responde con sus propias capacidades — si expone herramientas, si expone recursos, si ofrece suscripciones, si soporta funciones avanzadas. El Cliente confirma con una notificación initialized. La sesión queda entonces en estado operativo, y los tipos de mensaje disponibles son exactamente el subconjunto que ambas partes acordaron.
Esta negociación es lo que permite que un Cliente y un Servidor con conjuntos distintos de funcionalidades convivan de manera productiva. Es también donde se maneja el versionado: el Servidor escoge la versión más alta que ambas partes soportan. Operativamente, el ciclo de vida tiene consecuencias. Inicializar no es gratis — hay un coste de ida y vuelta y, para servidores remotos, un coste de establecimiento de conexión encima. Las sesiones de larga vida son el patrón preferido; los cambios de capacidad fluyen como notificaciones en vez de como reconexión. Los Hosts que respetan esto — manteniendo sesiones calientes, reconectando en segundo plano tras caídas de red — obtienen latencias materialmente mejores. Los Hosts que tiran y reinicializan por cada petición funcionan correctamente pero de forma ineficiente.
Una asimetría que conviene fijar: las peticiones tienen respuesta; las notificaciones no. Los eventos de list-changed son notificaciones, así que un Cliente que se pierda una debe estar preparado para refrescar su vista volviendo a llamar a list_tools. La notificación es una optimización, no una garantía. El código MCP robusto la trata como una pista, no como un registro.
Lo que prepara el Capítulo 2
Ya tienes el modelo mental. MCP es un protocolo JSON-RPC con tres roles, descubrimiento dinámico que hace al Servidor autoritativo sobre sus propias capacidades, descripciones escritas pensando en una audiencia LLM, un modelo de mensajería bidireccional con notificaciones y peticiones iniciadas por el servidor, y un ciclo de vida que abre con una negociación explícita de capacidades y opera dentro del subconjunto que ambas partes acordaron. Es suficiente andamiaje para hablar concretamente de qué exponen Servidores y Clientes, que es lo que hacen los dos capítulos siguientes.
Próximamente — Capítulo 3: Primitivas del servidor — Recursos, Prompts, Herramientas. Los tres sustantivos que un servidor puede ofrecer, por qué cada uno importa, y la disciplina de elegir la primitiva correcta en vez de sobrecargar una en el territorio de otra.
