En esta guía, verá:
- La historia de las tecnologías de transporte MCP y por qué se produjo el cambio de SSE a Streamable HTTP.
- Qué es SSE y cómo se utilizaba en versiones anteriores de MCP.
- Qué es Streamable HTTP y cómo se aplica en la versión actual de MCP.
- Una tabla resumen que compara SSE y Streamable HTTP.
- Cómo mantenerse al día sobre la evolución de las especificaciones de los protocolos.
Sumerjámonos.
Un poco de historia sobre los protocolos de transporte utilizados por MCP
MCP(Modal Context Protocol), uno de los protocolos de IA más populares y utilizados en la actualidad, sustituyó el mecanismo de transporte HTTP+SSE por Streamable HTTP a partir de la versión 2025-03-26 del protocolo. Esto ha supuesto un cambio significativo en la arquitectura del protocolo.
Ahora bien, entendamos mejor este cambio antes de explicar en qué consisten estos dos mecanismos de transporte.
Por qué los protocolos de IA necesitan mecanismos de transporte
Los protocolos de IA como el MCP necesitan mecanismos de transporte para facilitar el intercambio de información entre los distintos componentes de la arquitectura del protocolo.
En concreto, MCP utiliza JSON-RPC 2.0 como formato de transmisión entre clientes y servidores. Para la transmisión de mensajes JSON-RPC, se basa en mecanismos de transporte estándar como HTTP+SSE o Streamable HTTP (entre stdio – para la comunicación sobre entrada estándar y salida estándar en servidores locales).
Estas capas de transporte especializadas son necesarias porque el modelo tradicional de solicitud-respuesta de HTTP es ineficaz para la comunicación de IA en tiempo real. Esto se debe a que el HTTP simple introduce una sobrecarga y una latencia elevadas debido a las frecuentes configuraciones de conexión. En cambio, MCP requiere flujos de datos continuos y de baja latencia, algo para lo que HTTP+SSE y Streamable HTTP están diseñados.
Por qué se hizo el cambio
Inicialmente, MCP utilizaba HTTP+SSE para permitir la transmisión de servidor a cliente en escenarios remotos. Sin embargo, estas tres grandes limitaciones justificaron el cambio:
- No admite flujos reanudables.
- Requiere que el servidor mantenga una conexión de larga duración y alta disponibilidad.
- Sólo permite la entrega de mensajes de servidor a través de SSE.
Streamable HTTP resuelve estos problemas. Permite la comunicación sin estado e incluso admite actualizaciones a la carta de SSE. Esto mejora la compatibilidad con las infraestructuras modernas y garantiza una comunicación más estable y eficaz.
Impacto de la transición de HTTP+SSE a Streamable HTTP
La transición de HTTP+SSE a Streamable HTTP como protocolo de transporte ha supuesto un cambio importante para MCP. Introdujo cambios notables en la implementación del protocolo, lo que obligó a muchas bibliotecas de cliente y servidor MCP de terceros a adaptarse.
Sin embargo, a partir de este escrito, los clientes y servidores MCP pueden mantener la compatibilidad con el transporte HTTP+SSE obsoleto.
SSE (Eventos enviados por el servidor)
SSE(Server-Sent Events) es un mecanismo que permite a los clientes web recibir actualizaciones automáticas de un servidor. Estas actualizaciones se conocen como “eventos” y se envían a través de una única conexión HTTP de larga duración.
A diferencia de WebSockets, SSE es unidireccional, lo que significa que los datos sólo fluyen del servidor al cliente. SSE funciona mediante el envío por parte del servidor de un flujo de eventos a través de esta conexión abierta, normalmente formateado como text/event-streamde tipoMIME.
Uso de HTTP+SSE en MCP
Así es como MCP se basó en SSE en la versión 2024-11-05:
El servidor debe proporcionar dos puntos finales:
- Un punto final SSE GET para que los clientes establezcan una conexión y reciban mensajes del servidor.
- Un punto final HTTP POST normal para que los clientes envíen mensajes JSON-RPC al servidor.
Cuando un cliente se conecta, el servidor debe enviar un evento endpoint que contenga un URI que el cliente utilizará para enviar mensajes. Todos los mensajes JSON-RPC del cliente se envían entonces como peticiones HTTP POST a esta URI.
El servidor responde transmitiendo eventos a través de la conexión SSE abierta, simulando una sesión persistente. En detalle, los mensajes del servidor se entregan como eventos de mensajes SSE, con el contenido codificado como JSON en los datos del evento.
Para respuestas únicas, el servidor envía el mensaje y cierra el flujo. Para una comunicación continua, la conexión permanece abierta.
Ventajas e inconvenientes
Estos son los principales pros y contras de usar SSE en MCP:
👍 Streaming de grandes resultados: Permite enviar resultados parciales de forma inmediata, evitando retrasos mientras las herramientas MCP procesan grandes datos o esperan respuestas de APIs externas.
👍 Activadores basados en eventos: Admite eventos del servidor no solicitados para notificar cambios a los clientes, con alertas o actualizaciones de estado.
👍 Sencillez: Utiliza HTTP estándar, sin necesidad de protocolos especiales ni configuraciones complejas.
👎 S ólo unidireccional: Los datos sólo pueden fluir de servidores a clientes en el canal SSE. Los clientes deben usar peticiones HTTP POST separadas para enviar mensajes.
👎 Uso de recursos de conexión de larga duración: Mantener conexiones abiertas puede consumir muchos recursos del servidor, especialmente a escala.
Streamable HTTP
En el contexto de MCP, el HTTP fluido es un método para transmitir datos entre el cliente y el servidor utilizando HTTP puro. Abre la puerta a la comunicación en tiempo real sin necesidad de conexiones de larga duración.
Aunque puede seguir utilizando SSE por flexibilidad y compatibilidad con versiones anteriores, ese método de transporte ya no es necesario. Esto permite a MCP soportar servidores sin estado sin la sobrecarga de mantener conexiones persistentes de alta disponibilidad.
ℹ️ Extra: ¿Por qué Streamable HTTP + SSE opcional en lugar de WebSockets?
- El uso de WebSockets para llamadas RPC sencillas y sin estado añade una sobrecarga operativa y de red innecesaria.
- Los navegadores no pueden adjuntar cabeceras como
Authorizationa los WebSockets y, a diferencia de SSE, los WebSockets no pueden reimplementarse con herramientas HTTP estándar. - Las actualizaciones de WebSocket sólo funcionan con solicitudes GET, lo que hace que los flujos basados en POST sean complejos y más lentos debido a los pasos de actualización necesarios.
Streaming HTTP en MCP
En el transporte HTTP Streamable, el servidor actúa como un proceso autónomo capaz de gestionar múltiples conexiones de clientes. Utiliza peticiones HTTP POST y GET estándar para la comunicación.
Opcionalmente, el servidor puede utilizar SSE para transmitir múltiples mensajes al cliente. Esto se adapta tanto a los servidores MCP básicos para herramientas sencillas de solicitud/respuesta como a los que ofrecen capacidades más avanzadas como streaming y notificaciones de servidor a cliente en tiempo real.
El servidor debe exponer un único punto final HTTP (denominado “punto final MCP“) que admita los métodos POST y GET.
El siguiente diagrama ilustra el flujo de comunicación entre clientes y servidores MCP utilizando Streamable HTTP:
Para poder reanudar las conexiones interrumpidas y volver a entregar mensajes potencialmente perdidos, el servidor MCP asigna ID por flujo. Estos ID actúan como cursores dentro de cada flujo.
Dada la variedad de interacciones posibles, consulte la documentación oficial de MCP para conocer todos los detalles de la implementación.
Ventajas e inconvenientes
Estas son las principales ventajas de utilizar Streamable HTTP en MCP:
Compatible con servidores sin estado: Elimina la necesidad de conexiones siempre activas y de larga duración.
👍 HTTP plano: Puede implementarse utilizando cualquier servidor HTTP estándar sin necesidad de SSE.
Compatible con infraestructuras: Compatible con middleware HTTP, proxies y plataformas de alojamiento comunes.
Compatible con versiones anteriores: Se basa en el transporte HTTP+SSE anterior.
👍 S treaming opcional: Los servidores pueden actualizarse a SSE para transmitir respuestas cuando sea necesario.
Nota: En el momento de escribir estas líneas, el mecanismo de transporte Streamable HTTP no presenta ningún inconveniente digno de mención.
SSE vs Streamable HTTP: Comparación resumida
Compare los dos mecanismos de transporte en la siguiente tabla SSE vs Streamable HTTP:
| Aspecto | HTTP+SSE | Streamable HTTP |
|---|---|---|
| Tipo de comunicación | Unidireccional (Servidor → Cliente) | Bidireccional (Cliente ↔ Servidor vía GET/POST) |
| Uso del protocolo HTTP | GET para streaming, POST separado para mensajes de cliente | Utiliza HTTP POST y GET estándar desde un único punto final |
| Estado | Con estado | Con estado, pero admite servidores sin estado |
| Requiere una conexión HTTP de larga duración | Sí | No |
| Alta disponibilidad requerida | Sí, para la persistencia de la conexión | No, funciona con servidores sin estado o efímeros. |
| Escalabilidad | Limitado | Alta |
| Soporte de streaming | Sí (a través de texto/event-stream) |
Sí (a través de SSE como mejora opcional) |
| Autenticación | Sí | Sí |
| Apoyo a la reanudación y nueva entrega | No | No |
| Número de clientes | Múltiples | Múltiples |
| Utilización en MCP | Obsoleto desde la versión 2025-03-26 del protocolo |
Introducido en la versión del protocolo 2025-03-26 |
| Compatibilidad con versiones anteriores | – | Totalmente compatible con clientes basados en SSE |
Futuro de los métodos de transporte en MCP
MCP se lanzó en noviembre de 2024, por lo que aún es un protocolo muy joven. Para ponerlo en perspectiva, HTTP 1.1 -la versión más utilizada- existe desde hace casi 20 años.
Así pues, no es de extrañar que la especificación MCP siga evolucionando. Al igual que unos meses después de su lanzamiento la comunidad decidió pasar de SSE a Streamable HTTP, es posible que pronto se produzcan más cambios.
Mantente al día consultando la página de discusiones en el repositorio oficial MCP GitHub. El sitio web de MCP también permite consultar el último borrador de la próxima versión del protocolo.
Conclusión
En esta entrada del blog de comparación entre SSE y Streamable HTTP, usted aprendió por qué MCP hizo la transición de SSE a Streamable HTTP. En concreto, comprendió qué son estos dos mecanismos de transporte y cómo afectan a la transmisión de información en el popular protocolo de IA MCP.
Como se explica aquí, los servidores MCP de terceros que quieran seguir las especificaciones MCP más recientes y no obsoletas deben implementar Streamable HTTP. Si busca un servidor MCP actualizado, potente y rico en funciones, eche un vistazo al servidor MCP de Bright Data.
El servidor MCP de Bright Data se basa en la última versión de fastmcp, lo que garantiza la compatibilidad total con Streamable HTTP, al tiempo que mantiene la compatibilidad con SSE. Ofrece más de 20 herramientas para ampliar sus flujos de trabajo de IA con datos web frescos, interacciones del navegador de agentes en cualquier página web y mucho más.
Para un tutorial completo, siga nuestro artículo sobre la integración de Google ADK con un servidor MCP para el desarrollo de agentes de IA.
Cree hoy mismo una cuenta gratuita en Bright Data y pruebe nuestra infraestructura para impulsar sus agentes y aplicaciones de IA.
