WebSocket vs SSE para comunicación de agentes: por qué MCP no eligió ninguno

Puntos clave

• La especificación MCP 2026-07-28 descartó HTTP+SSE y lo reemplazó con Streamable HTTP — no WebSocket — porque los servidores sin estado funcionan con infraestructura HTTP estándar (WAFs, balanceadores de carga, proxies de autenticación) sin gestión de conexiones persistentes (MCP specification).
• A2A usa JSON-RPC 2.0 sobre HTTP con SSE para streaming de salida de tareas — el transporte es infraestructura; las semánticas del protocolo (ciclo de vida de tareas, estado INPUT_REQUIRED) son lo que hace funcionar la comunicación entre agentes (A2A protocol).
• CVE-2026-16496 (CVSS 10.0) en Terraform MCP explotó el modo de transporte SSE con estado — un ID de sesión robado permitió a un atacante ejecutar llamadas a herramientas con las credenciales de otro usuario. El transporte sin estado elimina la superficie de ataque a nivel de arquitectura, no a nivel de parche (NVD).
• WebSocket está disponible como transporte MCP personalizado pero añade complejidad de gestión de sesiones que los autores de la especificación evitaron deliberadamente — el protocolo es agnóstico al transporte, pero los transportes estándar (stdio, Streamable HTTP) cubren los casos de producción (MCP specification).
• La sesión "Stateless: The Future of MCP Transports" en AGNTCon+MCPCon Europe el 17 de septiembre de 2026 es la primera validación en conferencia de la dirección del transporte sin estado — presentada por Google y Hugging Face, los mantenedores del MCP Transport Working Group (Linux Foundation).

La pregunta del transporte suena a infraestructura, y lo es — pero la elección tiene consecuencias de seguridad, escalabilidad y operativas que aparecen en producción. Cuando el Model Context Protocol descartó HTTP+SSE el 28 de julio de 2026 y lo reemplazó con Streamable HTTP, los autores de la especificación tomaron una decisión de ingeniería deliberada: servidores sin estado sobre conexiones persistentes, HTTP estándar sobre protocolos personalizados, y un único endpoint sobre el modelo SSE de doble endpoint. No eligieron WebSocket, a pesar de que WebSocket es bidireccional y SSE no lo es. La razón no es que WebSocket sea incorrecto — es que para la carga de trabajo específica que MCP sirve (llamadas a herramientas entre un agente y una fuente de datos), la capacidad bidireccional no justifica la sobrecarga de gestión de sesiones.

Este artículo mapea las tres opciones de transporte — SSE, WebSocket y Streamable HTTP — contra los dos protocolos de agentes que las usan (MCP y A2A), con una matriz de decisión para despliegues de agentes B2B. La sesión de AGNTCon el 17 de septiembre hace que el momento sea concreto: el transporte sin estado está pasando de especificación a validación en conferencia, y los equipos que ejecutan el transporte SSE descartado tienen una ventana de migración de 12 meses que ya tiene dos meses transcurridos.

Los tres transportes, y qué hace cada uno

SSE (Server-Sent Events) — el valor predeterminado descartado

SSE es un protocolo unidireccional: el servidor envía datos al cliente sobre una conexión HTTP de larga duración, y el cliente no puede enviar mensajes de vuelta por la misma conexión. Cada acción del cliente — cancelar una generación, dirigir un agente durante una tarea, aprobar una llamada a herramienta — requiere una petición HTTP POST separada (WebSocket.org).

MCP usó SSE en su especificación 2024-11-05 como transporte para servidores remotos. El modelo requería dos endpoints: un endpoint SSE para mensajes servidor-a-cliente y un endpoint POST separado para mensajes cliente-a-servidor. El servidor mantenía el estado de la sesión a través de ambas conexiones. Tres limitaciones impulsaron la depreciación: sin soporte para flujos reanudables, el requisito de conexiones de larga duración y alta disponibilidad, y los mensajes del servidor entregados solo vía SSE (MCP specification PR #206).

A2A todavía usa SSE para su modo de streaming. El método SendStreamingMessage entrega actualizaciones de tarea como eventos SSE — deltas de tokens, fragmentos de artefactos, transiciones de estado. Esta es la elección correcta para A2A porque el streaming es unidireccional (servidor a cliente) y los mensajes de control del cliente (cancelar, suscribirse) van a través de llamadas JSON-RPC separadas (A2A protocol). SSE es simple, funciona sobre HTTP estándar y no requiere la gestión de sesiones de WebSocket para una carga de trabajo que es fundamentalmente push del servidor.

WebSocket — la opción bidireccional que MCP no estandarizó

WebSocket proporciona una conexión persistente y bidireccional entre cliente y servidor. Después de un handshake de actualización HTTP, la conexión permanece abierta y ambos lados pueden enviar mensajes en cualquier momento. Este es el primitivo correcto para aplicaciones que necesitan comunicación bidireccional real en un solo canal: chat, edición colaborativa, juegos multijugador, paneles de trading (Ably).

Para agentes de IA, el caso bidireccional es real. Los flujos de trabajo de agentes necesitan mensajes cliente-a-servidor durante la ejecución: cancelar una generación, dirigir un agente durante una tarea, aprobar o rechazar una llamada a herramienta, enviar contexto adicional. Con SSE, cada uno de estos es una petición HTTP separada. Con WebSocket, viajan en la misma conexión que el flujo de tokens (WebSocket.org).

La especificación MCP no estandariza WebSocket. Está disponible como transporte personalizado — la especificación dice "los clientes y servidores PUEDEN implementar mecanismos de transporte personalizados adicionales" siempre que preserven el formato de mensajes JSON-RPC — pero los transportes estándar son stdio (para servidores locales) y Streamable HTTP (para servidores remotos) (MCP specification). Un issue de GitHub (#493) propuso añadir WebSocket como transporte estándar para simplificar el modelo HTTP; se cerró sin adopción, y la especificación se movió a Streamable HTTP en su lugar (GitHub).

La razón por la que MCP no estandarizó WebSocket es operativa, no técnica. WebSocket requiere que el servidor mantenga conexiones persistentes, gestione la salud de la sesión, maneje la lógica de reconexión y lide con conexiones rotas. Esta es la misma carga de conexiones con estado que hizo que SSE fuera un riesgo. Los autores de MCP querían servidores sin estado — cualquier instancia puede manejar cualquier petición, sin almacén de sesión compartido, balanceo de carga round-robin simple — y el modelo de conexión persistente de WebSocket funciona contra ese objetivo.

Streamable HTTP — lo que MCP eligió en su lugar

Streamable HTTP es la respuesta de la especificación MCP a la pregunta SSE-vs-WebSocket. El servidor expone un único endpoint HTTP (por ejemplo, https://example.com/mcp) que maneja tanto POST como GET. El cliente envía cada mensaje JSON-RPC como un POST. El servidor puede responder con un cuerpo JSON simple o actualizar la respuesta a un flujo SSE si el resultado es de larga duración. La decisión de diseño clave: el servidor no necesita mantener una conexión persistente. Cada petición es autónoma (MCP specification).

Esto le da a MCP la capacidad de streaming de SSE sin el requisito de conexión de larga duración, y la capacidad bidireccional de WebSocket sin la sobrecarga de gestión de sesiones. El cliente envía mensajes vía POST (HTTP estándar), el servidor transmite respuestas vía SSE opcional (HTTP estándar), y el servidor puede ser sin estado (infraestructura HTTP estándar) (Bright Data; Auth0).

El argumento de seguridad es concreto. El análisis de Auth0: con Streamable HTTP, "podemos estampar un `Authorization: *** header estándar en cada sobre. El departamento de correo verifica el sello en cada mensaje, no solo en el primero." Con el viejo transporte SSE, el token de autenticación se establecía una vez al conectar y la conexión persistente transportaba todos los mensajes subsiguientes — incluyendo mensajes de un atacante que robó el ID de sesión (Auth0).

La matriz de decisión

Criterio	SSE (descartado)	WebSocket (personalizado)	Streamable HTTP (estándar MCP)
Dirección	Servidor → cliente solo	Bidireccional	Cliente → servidor vía POST; servidor → cliente vía SSE opcional
Modelo de conexión	Larga duración, persistente	Larga duración, persistente	Por petición (sin estado)
Estado del servidor	Con estado (sesión por conexión)	Con estado (sesión por conexión)	Sin estado (sin sesión entre peticiones)
Balanceo de carga	Sesiones sticky requeridas	Sesiones sticky requeridas	Round-robin simple
Escalado	Limitado (conexión por cliente)	Limitado (conexión por cliente)	Alto (cualquier infraestructura HTTP)
Autenticación	Al conectar	Al handshake	Por petición (Bearer en cada POST)
Reanudabilidad	No	No	No (pero sin estado significa sin sesión que reanudar)
Infraestructura	Necesita proxy compatible SSE	Necesita proxy compatible WebSocket	HTTP estándar (WAFs, LBs, CDN, proxies de auth)
Superficie de seguridad	Robo de ID de sesión (CVE-2026-16496)	Secuestro de sesión en conexión persistente	Ninguna a nivel de transporte (sin sesión que robar)
Estado MCP	Descartado, puesta de sol de 12 meses	Transporte personalizado (no estandarizado)	Transporte remoto estándar desde 2026-03-26
Estado A2A	Usado para modo streaming	No usado	No usado (A2A usa JSON-RPC sobre HTTP + SSE)
Mejor para	Push simple del servidor (streaming de tareas A2A)	Bidireccional real (chat, colaboración)	Llamadas agente-a-herramienta (MCP)

La tabla responde la pregunta que la mayoría de equipos B2B hacen: si tu agente necesita llamar a una herramienta en un servidor MCP remoto, usa Streamable HTTP. Si tu agente necesita transmitir la salida de una tarea a otro agente, usa el modo de streaming SSE de A2A. Si estás construyendo una interfaz colaborativa en tiempo real donde el cliente envía mensajes con la misma frecuencia que el servidor, WebSocket es el primitivo correcto — pero es un transporte personalizado, no un estándar de protocolo.

Los tres transportes comparados:

La dimensión de seguridad — por qué lo sin estado importa

El CVE que validó la elección del transporte sin estado es CVE-2026-16496, una bypass de autorización CVSS 10.0 en el Terraform MCP Server de HashiCorp. La vulnerabilidad afectó el modo de transporte streamable-HTTP con estado: un usuario que obtuviera el ID de sesión MCP de otro usuario podía ejecutar llamadas a herramientas usando las credenciales de Terraform de ese usuario. El vector de ataque existe solo porque el servidor mantiene un estado de sesión que un atacante puede robar y reutilizar. Un servidor sin estado no tiene sesión que robar (NVD; The Hacker News).

Esta es la evidencia de producción de que el modo de transporte con estado es un riesgo de seguridad, no solo una complejidad operativa. La ventana de depreciación de 12 meses de SSE es ahora un plazo de seguridad, no solo operacional. Los 1.227 servidores que aún ejecutan el transporte HTTP+SSE descartado son la población más afectada — y la población que carga con la superficie de ataque de secuestro de sesión.

Para un tratamiento más profundo del protocolo sin estado y el patrón de handle explícito que reemplaza el estado de sesión del lado del servidor, ver MCP 2026-07-28: Qué significa el protocolo sin estado para despliegues de agentes B2B.

Qué hace A2A diferente — y por qué funciona

A2A usa SSE para streaming, no Streamable HTTP. La diferencia es la carga de trabajo. Las llamadas a herramientas MCP son operaciones cortas de petición/respuesta — consultar una base de datos, obtener un registro, ejecutar un cálculo. El servidor procesa la petición y devuelve un resultado. El streaming es opcional y raro. Las tareas A2A son operaciones de larga duración con gestión explícita del ciclo de vida — una evaluación de precios que toma dos minutos, una verificación de cumplimiento que toma una hora. El streaming son las actualizaciones de progreso, no el resultado en sí.

El streaming SSE de A2A es solo push del servidor, que es la dirección correcta para el progreso de tareas: el agente que trabaja en la tarea envía actualizaciones al agente que la llamó. Los mensajes de control del agente que llamó (cancelar, suscribirse a actualizaciones) van a través de llamadas JSON-RPC separadas. No hay necesidad de comunicación bidireccional en el canal de streaming porque el canal de control es una petición HTTP estándar separada (A2A protocol; Google Developers Blog).

Por eso la pregunta del transporte es infraestructura, no arquitectura. MCP y A2A usan transportes diferentes porque tienen cargas de trabajo diferentes, pero ambos están construidos sobre HTTP estándar. Las semánticas del protocolo — las llamadas a herramientas sin estado de MCP y el ciclo de vida de tareas con estado de A2A — son lo que hace funcionar la comunicación entre agentes. El transporte lleva los mensajes; no los define.

Para la comparación a nivel de protocolo completa (alcance, transporte, autenticación, estado, humano-en-el-bucle), ver A2A vs MCP: elegir el protocolo correcto para comunicación de agentes.

Cuándo WebSocket es la respuesta correcta

WebSocket no es incorrecto. Es el transporte correcto para cargas de trabajo específicas que MCP y A2A no estandarizan:

• Interfaces colaborativas en tiempo real donde el cliente envía mensajes con la misma frecuencia que el servidor — un panel de agente compartido donde múltiples operadores dirigen el mismo agente simultáneamente.
• Comunicación bidireccional de alta frecuencia donde la sobrecarga por mensaje HTTP es prohibitiva — un agente de trading que recibe datos de mercado y envía órdenes en el mismo canal.
• Transportes MCP personalizados donde los transportes estándar no encajan — la especificación permite explícitamente transportes personalizados siempre que preserven el formato de mensajes JSON-RPC y los requisitos del ciclo de vida (MCP specification).

La contrapartida es complejidad operativa. Mantener conexiones bidireccionales de larga duración requiere lógica explícita para salud de sesión, reintentos, conexiones rotas y protocolos de mensajes (Nimble Way). Para la mayoría de despliegues de agentes B2B — un agente llamando a NetSuite, un agente de aprovisionamiento delegando a un agente de precios — esta complejidad no está justificada por la carga de trabajo.

La tendencia sin estado

La dirección de la industria es clara. MCP pasó a sin estado el 28 de julio de 2026. A2A usa máquinas de tareas con estado pero transporte sin estado (HTTP + SSE, sin sesión persistente en el servidor). La sesión de AGNTCon+MCPCon Europe el 17 de septiembre — "Stateless: The Future of MCP Transports", presentada por Kurtis Van Gent (Google) y Shaun Smith (Hugging Face, mantenedor del MCP Transport Working Group) — es la primera sesión de conferencia dedicada a la dirección del transporte sin estado (Linux Foundation; sched.com).

Shaun Smith también dará un keynote en la misma conferencia: "Getting to Stateless MCP: In Production" — lo que señala que el transporte sin estado está pasando de especificación a guía de despliegue en producción. Para los equipos que ejecutan el transporte SSE descartado, la ventana de migración de 12 meses (que termina en julio de 2027) es el plazo operacional. El plazo de seguridad es más pronto: cada día que un servidor ejecuta transporte SSE con estado es un día que carga con la superficie de secuestro de sesión que CVE-2026-16496 explota.

La pregunta de WebSocket vs SSE, para comunicación de agentes, tiene una respuesta clara: ninguno, si estás construyendo sobre MCP. Usa Streamable HTTP. Usa SSE si estás transmitiendo la salida de tareas A2A. Usa WebSocket solo cuando la carga de trabajo es genuinamente bidireccional y la complejidad operativa está justificada. El transporte es infraestructura. Las semánticas del protocolo — llamadas a herramientas sin estado, ciclos de vida de tareas con estado, handles explícitos, estados humano-en-el-bucle — son lo que hace que los sistemas de agentes funcionen en producción.

Lecturas relacionadas

• MCP 2026-07-28: Qué significa el protocolo sin estado para despliegues de agentes B2B — el tratamiento completo de la especificación del protocolo sin estado, el patrón de handle explícito y la ventana de depreciación de 12 meses de SSE
• A2A vs MCP: elegir el protocolo correcto para comunicación de agentes — la matriz de decisión a nivel de protocolo que cubre alcance, transporte, autenticación, estado y humano-en-el-bucle entre los dos protocolos de agentes
• Patrones de agentes de larga duración: mantener agentes vivos durante horas y días — la capa de persistencia sobre el transporte: checkpoint/resume, monitoreo a nivel de trayectoria y límites de coste para agentes que funcionan durante horas

---

Un distribuidor de mercado intermedio que ejecuta NetSuite, BigCommerce y tres catálogos de proveedores despliega un agente de cotización basado en MCP. El agente llama a NetSuite para precios escalonados, consulta catálogos de proveedores para disponibilidad y reserva stock con una fecha de caducidad. Cada una de estas es una llamada a herramienta sin estado sobre Streamable HTTP — sin conexión persistente, sin sesión que gestionar, sin balanceador de carga con sesiones sticky. Cuando el agente delega una negociación compleja multi-proveedor a un agente de precios, esa delegación cruza la frontera del protocolo A2A como una tarea con streaming SSE para actualizaciones de progreso. La elección de transporte no fue WebSocket vs SSE — fue Streamable HTTP para llamadas a herramientas y SSE para streaming de tareas, con las semánticas del protocolo haciendo el trabajo que el transporte no necesita hacer.

Solicita un build con alcance definido. Descubrimiento de una semana. Obtienes un inventario del sistema, mapa de flujos de trabajo y alcance fijo — construyas con nosotros o no.