El protocolo MCP recibe una importante actualización: pasa a ser completamente apátrida y simplifica la comunicación HTTP

Puntos básicos: MCP Al introducir un esquema de transporte "streaming HTTP", el protocolo consigue una completa ausencia de estado y simplifica la comunicación, sentando las bases para una gama más amplia de aplicaciones futuras.

Se ha aprobado una propuesta clave de mejora técnica del Protocolo de Canal de Mensajes (MCP), lo que supone un futuro más amplio para este protocolo emergente. El núcleo de esta actualización es una revolución en la forma en que MCP transfiere datos, haciéndolo completamente apátrida y simplificando la comunicación al protocolo HTTP normal.

 

Antecedentes: Limitaciones de HTTP+SSE

Anteriormente, el protocolo MCP utilizaba HTTP más SSE (Server Sent Events) para transferir datos. Este enfoque tenía algunas limitaciones:

• No se admite la desconexión y reconexión
• Los servidores deben mantener conexiones largas para garantizar la estabilidad
• Los mensajes del servidor sólo pueden enviarse a través de SSE

Soluciones innovadoras: streaming HTTP

Para resolver estos problemas, la comunidad ha propuesto el esquema de transporte "Streaming HTTP". Este esquema contiene los siguientes ajustes clave:

• Eliminar la interfaz /sse: todos los mensajes cliente-servidor se transmiten uniformemente a través de la interfaz /message (o similar).
• Escalado de solicitudes a SSE: El servidor puede escalar una solicitud de cliente a una conexión SSE para obtener notificaciones push o datos en tiempo real.
• Gestión del ID de sesión: El cliente proporciona un ID de sesión en la cabecera de la petición HTTP, que el servidor puede utilizar opcionalmente para identificar la sesión.
• Iniciar flujo SSE: El cliente puede enviar una solicitud GET vacía a la interfaz /message para establecer un flujo SSE.

Estas mejoras permiten que los servidores MCP sean completamente apátridas, eliminando la necesidad de conectividad constante y reduciendo significativamente la complejidad del servidor y el consumo de recursos. Al mismo tiempo, el uso del protocolo HTTP puro mejora la compatibilidad de MCP, lo que le permite encajar mejor en la infraestructura de red y el middleware existentes.

 

Respuesta positiva de la comunidad

Esta propuesta de mejora ha sido muy bien acogida y ha recibido comentarios positivos de la comunidad MCP. shopify, Pydantic, Cloudflare, LangChain, Vercel y Antrópico El equipo y muchas otras organizaciones y personas han contribuido a ello.

 

Los múltiples beneficios de la apatridia

La apatridia es el punto central de esta actualización del protocolo MCP, y aporta múltiples ventajas a MCP:

• Implantación y mantenimiento simplificados: no es necesario ocuparse de la persistencia y sincronización de los datos de sesión, lo que facilita la implantación y ampliación del servidor.
• Mejorar la estabilidad del sistema: el fallo de un solo servidor no afecta al funcionamiento general del sistema, por lo que es más fácil lograr una alta disponibilidad.
• Menor consumo de recursos: elimina la necesidad de mantener conexiones largas y el estado de las sesiones, lo que reduce el uso de recursos del servidor y los costes.

 

Perspectivas de las aplicaciones

La implementación de MCP sin estado abre nuevas posibilidades para muchos escenarios de aplicación:

• Servidor de herramientas sin estado: se puede construir un servidor MCP completamente sin estado para proporcionar únicamente la funcionalidad de la herramienta de modelado del lenguaje sin gestión de estados, lo que simplifica el proceso de invocación de la herramienta.
• Servidores sin estado con soporte de respuestas en streaming: Incluso los servidores sin estado pueden aprovechar SSE para proporcionar respuestas en streaming, como enviar información de progreso en tiempo real durante la ejecución de la herramienta.

 

¿Por qué Streaming HTTP sobre WebSocket?

WebSocket también se consideró en la selección del esquema de transporte, pero finalmente la comunidad eligió "Streaming HTTP" basándose en las siguientes consideraciones:

• Sobrecarga en escenarios RPC: Para escenarios RPC (Remote Procedure Call) simples, forzar el uso de WebSocket introduce una carga operativa y de red innecesaria.
• Compatibilidad con navegadores: WebSocket no es tan flexible como SSE en términos de configuración de cabeceras de petición HTTP e implementaciones de bibliotecas de terceros en el entorno del navegador.
• Complejidad de la actualización del protocolo: WebSocket sólo admite la actualización de solicitudes GET, el proceso de actualización de solicitudes POST es complejo y aumenta la latencia.
• Especificación simplificada del protocolo: la especificación del protocolo MCP tiende a limitar la variedad de protocolos de transporte oficiales para evitar problemas de compatibilidad.

 

Exploración de la seguridad

Aunque la apatridia ofrece muchas ventajas, también plantea el debate de la seguridad, sobre todo en lo que respecta a la gestión del ID de sesión y la autorización.

Algunos desarrolladores han señalado que si un servidor utiliza la cabecera de petición Mcp-Session-Id para gestionar sesiones, debería vincular el ID de sesión al entorno de autorización para evitar que se utilice indebidamente en diferentes entornos de autorización. Esto significa que el ID de sesión debería estar asociado a un usuario o sesión de cliente específico, en lugar de ser globalmente común.

Para los desarrolladores que buscan un servidor minimalista, los mecanismos de autenticación complejos pueden no ser aplicables. En el modo con estado, la propia petición HTTP puede considerarse el límite de la sesión. Sin embargo, en el modelo sin estado, sigue preocupando cómo gestionar de forma segura la sesión sin cookies HTTP-only.

Algunos desarrolladores sugieren introducir cookies sólo HTTP para gestionar las sesiones de cliente, y asignar un ID único a cada sesión de cliente, y después gestionar múltiples ID de sesión MCP bajo él para conseguir una gestión jerárquica de las sesiones, teniendo en cuenta la seguridad y la flexibilidad.

 

Resumen y perspectivas

La evolución del protocolo MCP hacia la ausencia de estado es un paso importante hacia la practicidad y la facilidad de uso. Se espera que la adopción del esquema "Streaming HTTP" reduzca el umbral de despliegue de MCP y atraiga a más desarrolladores y escenarios de aplicación. Aunque todavía hay margen para debatir sobre la seguridad, creemos que, a medida que la comunidad siga mejorando, merecerá la pena esperar con impaciencia el futuro del protocolo MCP.

 

Propuestas pertinentes

[RFC] Sustituir HTTP+SSE por el nuevo transporte "Streamable HTTP" #206 Enlace propuesto: [RFC] Sustituir HTTP+SSE por el nuevo transporte "Streamable HTTP" #206