El Model Context Protocol (MCP) se ha convertido en el estándar para conectar LLMs con herramientas externas. Su primer transporte remoto, HTTP + SSE (Server-Sent Events), funcionó al inicio, pero pronto mostró límites: requería dos endpoints, era difícil de escalar, sufría bloqueos con firewalls o proxies y no tenía mecanismos de recuperación si la conexión fallaba.
Para resolverlo, la actualización v2025-03-26 introdujo Streamable HTTP, un transporte con un único endpoint que combina la simplicidad de HTTP con la flexibilidad del streaming. Esto reduce la complejidad, mejora la compatibilidad con infraestructuras de red y ofrece respuestas más rápidas y estables.
En este artículo veremos:
- Por qué SSE resultaba problemático.
- Cómo funciona Streamable HTTP.
- Sus beneficios prácticos y técnicos.
- Recomendaciones para desarrolladores MCP.
El Problema de SSE en MCP
La arquitectura inicial con HTTP + SSE requería dos endpoints:
/sse: conexión persistente para recibir mensajes./messages: endpoint separado para enviar mensajes.
Aunque era operativo, este diseño presentaba problemas:
- Dos conexiones por cliente (POST y SSE).
- Escalabilidad limitada en escenarios de alta concurrencia.
- Incompatibilidades con firewalls y proxies que bloqueaban conexiones largas.
- Falta de mecanismos para recuperar mensajes tras caídas.
- Más lógica y código en cliente y servidor para coordinar canales.
En la práctica: servidores complejos, clientes frágiles y una comunicación poco confiable.
Cómo funciona Streamable HTTP
La nueva especificación reemplaza el esquema de dos endpoints con uno solo (ej. /mcp).
Dependiendo del caso, el servidor responde con:
- Una respuesta HTTP normal, o
- Una conexión en streaming para enviar eventos.
Esto simplifica el modelo: un único canal para todo.
Beneficios de Streamable HTTP
El cambio aporta ventajas claras:
- Simplicidad: menos endpoints, menos código.
- Escalabilidad: reutiliza conexiones TCP en lugar de mantener miles abiertas.
- Compatibilidad: funciona bien detrás de firewalls, proxies y balanceadores.
- Flexibilidad: sirve tanto para respuestas rápidas como para streams largos.
- Robustez: mejor manejo de errores y posibilidad futura de reanudar sesiones.
SSE vs. Streamable HTTP en la práctica
| Aspecto | SSE (HTTP + SSE) | Streamable HTTP |
| Conexiones TCP | Crecen rápidamente con la concurrencia. | Reutiliza conexiones existentes. |
| Tasa de éxito | Se degrada al alcanzar el límite de conexiones. | Mantiene alta disponibilidad con miles de clientes. |
| Tiempos de respuesta | Latencia inestable incluso en baja carga. | Respuestas más rápidas y consistentes. |
| Complejidad del cliente | Requiere reconexiones y dos endpoints. | Un único POST y procesamiento de respuesta. |
Recomendaciones para desarrolladores MCP
- Nuevos servidores: implementa directamente Streamable HTTP.
- Servidores con SSE: añade soporte dual para una transición gradual.
- Clientes MCP: prioriza Streamable HTTP, pero mantén SSE como alternativa para compatibilidad.
Conclusión
El paso de SSE a Streamable HTTP no es un detalle menor: es un cambio estructural que simplifica la arquitectura, mejora la escalabilidad y hace más confiable el ecosistema MCP.
SSE seguirá disponible por compatibilidad, pero el futuro es claro: Streamable HTTP será el estándar de facto.
Si construyes un servidor MCP nuevo, comienza con Streamable HTTP.
Si mantienes uno con SSE, añade soporte dual cuanto antes.