Una mirada crítica a MCP

• MCP es un protocolo basado en JSON-RPC que busca que los LLM/Agent manejen herramientas externas y fuentes de datos de forma estandarizada, pero recibe críticas porque el diseño de su transporte sobre HTTP y la calidad de su documentación aumentan la carga de implementación
• El mayor punto de controversia es que, al implementar una comunicación bidireccional simple sobre HTTP, reconstruye de forma indirecta un comportamiento parecido a WebSocket mediante HTTP+SSE y Streamable HTTP
• Streamable HTTP divide la creación de sesiones, la conexión SSE y las rutas de entrega de respuestas en múltiples variantes, lo que incrementa la carga de gestión de estado, depuración, interoperabilidad, escalabilidad y seguridad
• Al transporte HTTP se le añaden requisitos de autorización centrados en OAuth2, mientras que stdio está definido para tomar credenciales desde variables de entorno, por lo que el modelo de autenticación cambia según el método de transporte
• El transporte HTTP debería simplificarse usando WebSocket, que es lo más cercano a los flujos de entrada y salida de stdio, y optimizar el diseño para los casos de uso más comunes en vez de para casos excepcionales

---

MCP se está expandiendo rápidamente

• MCP(Model Context Protocol) es un protocolo abierto que estandariza cómo las aplicaciones proporcionan contexto a los LLM
• Anthropic compara MCP con el puerto USB-C de las aplicaciones de IA y lo describe como una forma estándar de conectar modelos de IA con diversas fuentes de datos y herramientas
• Durante el último mes, MCP se ha expandido con rapidez, y cada día aparecen nuevos MCP Server y Client, que pueden verse en sitios como mcp.so y pulsemcp.com
• IBM publicó Agent Communication Protocol(ACP) como un “estándar ortogonal” a MCP, y Google también presentó Agent2Agent(A2A)
• La crítica central es que, aunque las grandes empresas gastan enormes sumas en entrenamiento y ajuste de modelos, la madurez de la documentación, los SDK y las guías de implementación sigue siendo baja

El protocolo en sí y la capa de transporte

• MCP es un protocolo JSON-RPC con métodos y endpoints predefinidos para usarse junto con LLM
• Sus principales métodos de transporte se dividen entre stdio, más cercano a la ejecución local, y el transporte basado en HTTP

  • stdio

    • Se inicia un MCP Server local y se conectan los pipes stdout y stdin con el Client para intercambiar JSON, mientras stderr se usa para logging
    • Aunque puede criticarse el uso del paradigma de pipes de Unix/Linux para comunicación bidireccional, funciona fácilmente en todos los sistemas operativos y es sencillo de entender porque no requiere manejo de sockets

  • Transporte basado en HTTP

    • Funciona sobre HTTP y existen HTTP+SSE y Streamable HTTP, que busca reemplazarlo
    • Ambos intentan implementar un intercambio bidireccional simple de mensajes mediante una combinación de solicitudes HTTP y conexiones SSE, lo que aumenta la complejidad

Críticas a HTTP+SSE y Streamable HTTP

• El transporte HTTP existente usa HTTP+SSE(Server-Sent Events), y la nueva especificación intenta reemplazarlo con Streamable HTTP
• En HTTP+SSE, para lograr full duplex, el Client abre una sesión SSE de lectura con una solicitud como GET /sse, recibe en la primera respuesta una URL de escritura y luego envía una solicitud como POST /a-endpoint?session-id=1234
  • El servidor devuelve 202 Accepted con un cuerpo vacío
  • La respuesta real debe leerse desde la conexión /sse que ya estaba abierta
• Streamable HTTP maneja el ID de sesión mediante headers HTTP en lugar de un endpoint separado, y puede abrir una sesión SSE con GET o POST /mcp
  • La respuesta puede llegar en un nuevo stream SSE
  • Puede llegar en el cuerpo de la respuesta al POST con 200
  • Puede entregarse más tarde a través de uno de los streams SSE ya existentes
• Este diseño se parece más a una estructura que intenta funcionar como WebSocket sobre SSE, y en modelcontextprotocol/pull/206 se discute la lógica de no usar WebSocket real
• El transporte HTTP intenta imitar a stdio, pero como no es realmente un socket, la implementación del servidor termina cargando con la tarea de unir (join) múltiples llamadas y conexiones HTTP

Problemas de documentación y SDK visibles en la experiencia de implementación

• En un intento de implementar un MCP Server en Go, no existía un SDK oficial para Go, y para entender el protocolo fue necesario, en la práctica, hacer ingeniería inversa
• La documentación de modelcontextprotocol.io omite o pasa por alto detalles importantes del protocolo y tampoco ofrece ejemplos del flujo de conversación
• El sitio web tiene un enfoque fuerte en llevar al lector a tutoriales de implementación con SDK más que a leer el estándar en sí
• Los servidores de ejemplo están implementados en Python o JavaScript y asumen ejecución local mediante stdio
  • Se critica que Python y JavaScript no son buenas opciones para herramientas locales que deben funcionar de manera estable en la computadora de otra persona
  • El hecho de que también se ofrezcan ejemplos en contenedores Docker parece mostrar cierto reconocimiento de este problema
• Se plantea que, para ejecución local de MCP, lenguajes más portables o alternativas basadas en VM como Rust, Go, Java o C# serían más adecuados

La complejidad que introduce Streamable HTTP

• En Streamable HTTP, una nueva sesión puede crearse de tres maneras
  • Una solicitud GET vacía
  • Una solicitud POST vacía
  • Una solicitud POST que contiene una llamada RPC
• SSE también puede abrirse por cuatro caminos
  • GET para inicialización
  • GET para unirse a una sesión previa
  • POST para inicializar la sesión
  • POST con una solicitud y respuesta por SSE
• Las respuestas a solicitudes pueden entregarse nuevamente de tres maneras
  • En la respuesta HTTP del POST que contiene la llamada RPC
  • Como evento SSE abierto en respuesta a ese POST
  • Como un evento SSE arbitrario abierto con anterioridad
• Al multiplicarse las rutas para obtener el mismo resultado, aumenta la carga cognitiva, la dificultad de depuración y el costo de mantenimiento
• Si Client y Server implementan solo algunas de las variantes que cada uno considera necesarias, pueden surgir problemas de interoperabilidad y comportamientos inesperados
• En configuraciones de servidor distribuidas entre varias máquinas, la gestión del estado de conexión y de los mecanismos de respuesta puede convertirse en un cuello de botella de escalabilidad

Problemas de seguridad y autorización

• La flexibilidad de Streamable HTTP genera varias preocupaciones de seguridad
  • La gestión del estado de sesión entre HTTP y SSE es compleja y puede abrir la puerta a secuestro de sesión, ataques de repetición y posibilidades de DoS
  • Al haber más puntos de entrada para creación de sesión y conexión SSE, se amplía la superficie de ataque
  • La variedad de formas de iniciar sesiones y entregar respuestas puede usarse para ocultar actividad maliciosa
• La especificación más reciente de authorization recomienda que las implementaciones de transporte basado en HTTP sigan esa especificación
• La misma especificación recomienda que las implementaciones de transporte STDIO no la sigan y, en cambio, obtengan credenciales del entorno
• En esta estructura surge la queja de que, si se usa transporte HTTP, hay que implementar el flujo de OAuth2, mientras que con stdio parecería posible un acceso al nivel de API key

Propuesta: simplificar el transporte HTTP con WebSocket

• MCP tiene un único protocolo JSON-RPC, y stdio parece claramente el método de transporte preferido
• El transporte HTTP debería parecerse lo más posible a stdio, introduciendo diferencias solo cuando sean realmente necesarias
• Las variables de entorno de stdio pueden corresponder a los headers HTTP en HTTP
• Los flujos de entrada y salida tipo socket de stdio pueden corresponder a WebSocket en HTTP
• Usar WebSocket permitiría reducir la compleja gestión de estado entre servidores para sesiones y muchos corner cases
• Aun así, la autorización podría volverse más compleja en algunos casos, algunos firewalls pueden bloquear WebSocket, en sesiones cortas puede haber overhead y reanudar sesiones interrumpidas puede ser más difícil
• La propia especificación de MCP también afirma que es un protocolo agnóstico al transporte que puede implementarse sobre cualquier canal de comunicación que soporte intercambio bidireccional de mensajes
• La industria debería optimizar para los casos de uso más comunes y no para los corner cases

Evaluación adicional sobre ACP y A2A

• MCP es un protocolo para exponer APIs a los LLM, mientras que ACP y A2A se parecen más a protocolos para exponer Agent a los LLM
• Al revisar la especificación de A2A, su necesidad parece limitada, y muchas de sus funciones parecen poder resolverse con MCP tal cual o con pequeñas extensiones
• ACP y A2A podrían implementarse no como protocolos separados, sino como herramientas de un MCP Server
• IBM también presenta en la documentación de MCP adapter la idea de ver un ACP Agent como un recurso MCP que puede invocarse como herramienta MCP
• Se evalúa que ACP tiene un carácter de promoción de BeeAI, la herramienta de construcción de agentes de IBM
• Las ventajas que sí aportarían ACP y A2A serían una capa de transporte más completa y una forma de descubrimiento de Agent