El problema fundamental que MCP 2.0 aborda es la complejidad inherente y los riesgos de seguridad asociados con la integración de herramientas externas en frameworks de agentes basados en Large Language Models (LLM). Históricamente, la interacción entre un agente y una herramienta ha requerido la gestión de estado de sesión, lo que introduce fricción en la implementación, dificulta la escalabilidad horizontal y aumenta la superficie de ataque.
La evolución de los agentes LLM ha mostrado una tendencia hacia entornos más permisivos (ej., acceso a shell y curl), lo que si bien ofrece flexibilidad, magnifica los desafíos de seguridad y control. MCP 2.0 emerge como una respuesta a esta problemática, proponiendo un protocolo de comunicación stateless que simplifica radicalmente la interacción, haciendo que la integración de herramientas sea más robusta, auditable y segura, incluso para modelos más pequeños y entornos con recursos limitados. Este cambio de paradigma permite a los desarrolladores construir sistemas de agentes con una comprensión más clara de las capacidades y riesgos asociados a cada herramienta.
Arquitectura del Sistema
La arquitectura del Model Context Protocol (MCP) 2.0 se centra en un diseño fundamentalmente stateless, a diferencia de su predecesor que requería la inicialización de una sesión y el mantenimiento de un Mcp-Session-Id.
En MCP 2.0, cada interacción de llamada a herramienta se encapsula en una única solicitud HTTP POST. Los metadatos de la sesión y la información del cliente, que antes se gestionaban en una fase de inicialización separada, ahora se incluyen directamente en los encabezados HTTP (MCP-Protocol-Version, Mcp-Method, Mcp-Name) y en un campo _meta dentro del cuerpo JSON de la solicitud. El cuerpo de la solicitud sigue el estándar JSON-RPC 2.0, especificando el método (tools/call) y los argumentos (params) para la herramienta invocada. Esta eliminación del estado de sesión en el servidor simplifica la lógica de enrutamiento y la gestión de recursos, ya que cada solicitud puede ser procesada de forma independiente por cualquier instancia del servicio, facilitando la escalabilidad horizontal y la resiliencia. La respuesta del servidor también es un objeto JSON-RPC, conteniendo el resultado de la operación. Este diseño se alinea con los principios de las arquitecturas RESTful y de microservicios, donde la idempotencia y la independencia de las solicitudes son clave.
Flujo de Llamada a Herramienta Stateless (MCP 2.0)
- 1 Agente LLM Determina la herramienta y argumentos a invocar.
- 2 Cliente MCP Construye una única solicitud HTTP POST con encabezados MCP y cuerpo JSON-RPC.
- 3 Servidor MCP Recibe la solicitud, extrae metadatos de encabezados y argumentos del cuerpo.
- 4 Servicio de Herramienta Ejecuta la lógica de la herramienta con los argumentos proporcionados.
- 5 Servidor MCP Envía la respuesta JSON-RPC al cliente.
- 6 Agente LLM Procesa el resultado de la herramienta para continuar la tarea.
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | HTTP/1.1 | Protocolo de transporte subyacente para las comunicaciones entre el cliente y el servidor MCP. |
| messaging | JSON-RPC 2.0 | Formato de mensaje para la invocación de métodos remotos y el intercambio de datos entre el cliente y el servidor MCP. |
| orchestration | Model Context Protocol (MCP) 2.0 | Especificación de protocolo para estandarizar la exposición y el consumo de herramientas por parte de frameworks de agentes LLM. vs Legacy MCP (stateful), Acceso directo a shell/curl Uso de encabezados HTTP para metadatos de protocolo y cliente. |
| data-processing | JSON Schema | Descripción de la estructura de entrada y salida de las herramientas MCP, facilitando la validación y el descubrimiento. |
Trade-offs
Ganancias
- ▲ Complejidad de implementación (cliente y servidor)
- ▲ Escalabilidad horizontal del servicio MCP
- ▲ Seguridad y auditabilidad de las interacciones agente-herramienta
- △ Facilidad de uso para modelos LLM más pequeños
Costes
- △ Overhead de datos por solicitud (metadatos repetidos)
uvx mcp-explorer call \
https://agentic-mermaid.dev/mcp \
render_svg \
-a source 'graph TD; A-->B' \
-a options '{"padding":24}'Fundamentos Teóricos
La transición de un protocolo stateful a uno stateless en MCP 2.0 resuena con principios fundamentales de la computación distribuida y la arquitectura de sistemas. La eliminación del estado de sesión en el servidor se alinea con el concepto de 'Statelessness' propuesto por Roy Fielding en su tesis doctoral sobre REST (Architectural Styles and the Design of Network-based Software Architectures, 2000). Fielding argumentó que los servidores stateless mejoran la escalabilidad, la fiabilidad y la visibilidad de los sistemas distribuidos al eliminar la necesidad de replicar o sincronizar el estado de la sesión entre múltiples instancias de servicio.
Desde una perspectiva de seguridad, la reducción de la superficie de ataque y la mejora de la auditabilidad en sistemas de agentes LLM, como se menciona en el artículo, se relaciona con los principios de 'Least Privilege' y 'Defense in Depth'. Al limitar las capacidades de las herramientas y hacer que cada invocación sea atómica y explícita, se reduce el riesgo de 'prompt injection' y exfiltración de datos, problemas que han sido ampliamente estudiados en el contexto de la seguridad de sistemas y la interacción humano-computadora.