HTTP con streaming, tres etapas y el contrato de conexión actual

El transporte HTTP remoto de MCP ha pasado por tres diseños de protocolo distintos en aproximadamente dos años. El transporte HTTP+SSE del 05-11-2024 utilizaba dos puntos de conexión y un flujo de larga duración; ha quedado obsoleto desde el 26-03-2025 y es susceptible de ser eliminado en el futuro. Streamable HTTP lo sustituyó el 26-03-2025 por un único punto de conexión, pero esa primera versión aún incluía sesiones a nivel de protocolo, un flujo GET independiente, solicitudes iniciadas por el servidor a través de SSE y flujos reanudables. La revisión del 28-07-2026 eliminó esos mecanismos. Lo que queda es inusualmente limpio: cada mensaje JSON-RPC del cliente se envía como su propio POST, las respuestas a las solicitudes son un objeto JSON o un flujo SSE limitado a esa solicitud, y los metadatos seleccionados de la solicitud se reflejan en las cabeceras para que los intermediarios puedan enrutar e inspeccionar el tráfico sin analizar el cuerpo. Esa última decisión de diseño es la que merece una lectura atenta.

Un equilibrador de carga enruta basándose en una cabecera mientras el servidor ejecuta basándose en el cuerpo, y ambos no coinciden. Esto no es una hipótesis en esta especificación; es la razón declarada por la que existe toda una regla de validación. El transporte del 28-07-2026 se adapta explícitamente a los intermediarios entre el cliente y el servidor, y gran parte del nuevo contrato de cabeceras solo tiene sentido si se lee de esa manera.

1. Tres eras

05-11-2024 — HTTP+SSE. Dos puntos de conexión. El cliente emitía un GET que abría un flujo SSE, cuyo primer evento era un endpoint evento que indicaba al cliente dónde realizar el POST. Todo lo iniciado por el servidor llegaba a través del flujo de larga duración. Obsoleto desde el 26-03-2025 según la política de ciclo de vida de funciones, y se desaconseja su adopción en nuevas implementaciones.

Del 26-03-2025 al 25-11-2025 — Streamable HTTP, primera versión. Un único punto de conexión MCP, lo que supuso una simplificación significativa. Pero cuatro mecanismos lo mantenían con estado: los servidores podían asignar una sesión mediante una cabecera Mcp-Session-Id , terminada con un HTTP DELETE; los clientes podían abrir un flujo SSE independiente con GET para recibir mensajes iniciados por el servidor; los servidores podían enviar solicitudes JSON-RPC en flujos SSE; y los flujos eran reanudables mediante Last-Event-ID.

28-07-2026 — la versión actual. Ninguno de esos cuatro mecanismos permanece. Las notas de la revisión enumeran las eliminaciones claramente: el punto de conexión de flujo GET y las sesiones a nivel de protocolo han desaparecido, y las secciones siguientes añaden que los flujos no son reanudables y que los servidores no deben enviar solicitudes independientes en un flujo.

Un servidor que implemente solo la revisión actual gestiona el tráfico antiguo con un comportamiento especificado: un GET o DELETE al punto de conexión MCP recibe 405 Método no permitido; una cabecera Mcp-Session-Id se ignora y no se crea ni se devuelve ningún identificador de sesión; una cabecera Last-Event-ID se ignora.

2. El protocolo de comunicación

El servidor expone una ruta de punto de conexión HTTP (el punto de conexión MCP) que admite POST. La base de seguridad del transporte es importante antes de cualquier optimización de la comunicación: los servidores deben validar la cabecera Origin en las conexiones entrantes y devolver un 403 si el origen está presente pero no es válido; los servidores que se ejecutan localmente deben vincularse a localhost en lugar de a todas las interfaces; y los servidores deben autenticar las conexiones. Estos requisitos existen para reducir el riesgo de rebinding de DNS y acceso no autorizado.

Envío. Cada mensaje JSON-RPC del cliente es su propio POST. El cliente debe incluir una cabecera Accept que enumere tanto application/jsonytext/event-stream, y el cuerpo debe ser una única solicitud o notificación JSON-RPC. Los clientes no deben enviar respuestas JSON-RPC. Un detalle importante para los implementadores: aunque el transporte define cómo se comporta un POST de notificación, el protocolo central del 28-07-2026 no define notificaciones de cliente a servidor a través de HTTP transmitible (Streamable HTTP) y no define requisitos de cabeceras de metadatos para los POST de notificación.

Notificaciones. Si el servidor acepta una, devuelve 202 Accepted sin cuerpo; si no puede, un estado de error HTTP, que opcionalmente incluya una respuesta de error JSON-RPC sin id.

Solicitudes. El servidor devuelve o bien Content-Type: application/json con un único objeto JSON, o bien Content-Type: text/event-stream con un flujo SSE limitado a esa solicitud. El cliente debe admitir ambos; el servidor elige según la solicitud, por lo que un cliente que solo gestione uno fallará de forma impredecible.

Qué se transmite en un flujo de respuesta. El servidor puede enviar notificaciones relacionadas con la solicitud original (mensajes de progreso y registro) antes de la respuesta final, y la respuesta final debería terminar el flujo. El servidor no debe enviar solicitudes JSON-RPC independientes en él. Esta es la ruptura explícita con respecto a revisiones anteriores.

Cancelación. El cierre del flujo de respuesta SSE debe ser tratado por el servidor como una cancelación de dicha solicitud y, dado que cada solicitud tiene su propio flujo, la desconexión es inequívoca. La notificación de cancelación del protocolo central solo se utiliza en stdio; en este transporte no hay mensaje de cancelación y no se espera ninguno.

3. A dónde fue el trabajo iniciado por el servidor

Dos cosas que anteriormente requerían un canal del servidor al cliente se han separado en mecanismos distintos.

Solicitar algo al cliente (muestreo, obtención de información, raíces) ahora está integrado en los resultados como solicitudes de entrada bajo el patrón de Solicitudes de Ida y Vuelta Múltiples. El servidor devuelve un InputRequiredResult que contiene inputRequests; el cliente recopila lo solicitado y vuelve a realizar la llamada original con el inputResponses. Se trata de un segundo POST, no de un push.

Notificaciones de cambios de larga duración — cambios en la lista de herramientas, actualizaciones de recursos — se obtienen enviando una subscriptions/listen solicitud cuya respuesta es, en sí misma, un flujo SSE que permanece abierto y entrega únicamente los tipos de notificación a los que el cliente se ha suscrito. Las notificaciones con ámbito de solicitud, como el progreso, no aparecen ahí; fluyen únicamente en el flujo de la solicitud a la que pertenecen.

Esa separación es más ordenada de lo que parece. El flujo de notificaciones de larga duración estandarizado existe porque el cliente lo solicitó, y su contenido está filtrado por la propia suscripción del cliente. El trabajo de múltiples viajes de ida y vuelta puede permanecer sin estado en la capa de transporte MCP porque el servidor puede codificar el contexto necesario en requestState y el cliente devuelve ese valor opaco al reintentar.

4. Dos detalles que causan problemas tras un proxy

La especificación incluye dos notas operativas que existen debido a la difícil relación entre SSE y los proxies inversos.

Almacenamiento en búfer. Al iniciar un flujo SSE, los servidores deben incluir X-Accel-Buffering: no. Esto indica a los proxies inversos, como nginx, que deshabiliten el almacenamiento en búfer de la respuesta. Sin esto, un proxy puede acumular mensajes antes de reenviarlos, lo que introduce latencia y socava el propósito del streaming. Si las actualizaciones de progreso transmitidas llegan todas juntas al final, el almacenamiento en búfer de la respuesta es uno de los primeros comportamientos intermedios que se deben comprobar.

Keep-alives (mensajes de mantenimiento). Para los flujos de larga duración, particularmente la respuesta subscriptions/listen , se recomienda a los servidores que emitan periódicamente una línea de comentario SSE —una línea que comienza con dos puntos— como mensaje de mantenimiento, para que los intermediarios y los tiempos de espera por inactividad no cierren una conexión silenciosa. Según la especificación SSE, un comentario no contiene datos de eventos, y los clientes deben ignorar dichas líneas en lugar de tratarlas como mal formadas.

5. El contrato de cabecera

Esta es la parte que hace que el transporte sea realmente diferente de una convención JSON-RPC sobre HTTP, y la especificación establece su propósito directamente: el transporte refleja campos seleccionados del cuerpo JSON-RPC en las cabeceras HTTP para que los intermediarios (equilibradores de carga, pasarelas, herramientas de observabilidad) puedan enrutar e inspeccionar las solicitudes sin necesidad de analizar el cuerpo.

MCP-Protocol-Version — obligatorio en cada POST, y su valor debe coincidir con la versión del protocolo incluida en el campo _metadel cuerpo. Una discrepancia se rechaza con un 400 Bad Request y un error HeaderMismatch . Una versión que el servidor no implementa recibe un 400 con un error que enumera las versiones que sí admite. Un método no implementado recibe un 404 con el código JSON-RPC -32601, que es lo que lo distingue del error de un servidor heredado 404.

Mcp-Method — refleja method. Obligatorio en todas las solicitudes JSON-RPC.

Mcp-Name — refleja params.nameoparams.uri. Obligatorio para tools/call,resources/read, yprompts/get.

Para las solicitudes JSON-RPC, esas cabeceras de solicitud estándar son obligatorias para cumplir con los ámbitos anteriores. Las notificaciones POST son un caso especial aparte: esta revisión define sus mecanismos de transporte, pero no sus requisitos de cabeceras de metadatos. Una solicitud tools/call mínima conforme se vería así en la transmisión:

POST to the MCP endpoint
POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_weather","arguments":{"location":"Seattle, WA"},
 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}

Los servidores pueden ir más allá y designar parámetros de herramientas específicos para que sean reflejados, utilizando una extensión x-mcp-header en el esquema del parámetro, lo que genera cabeceras llamadas Mcp-Param-{Name}. Un servidor que anota un parámetro de región obtiene Mcp-Param-Region: us-west1 junto al cuerpo, que es exactamente la forma que necesita un enrutador para enviar una consulta al backend regional correcto sin leer la carga útil.

Las restricciones de esa extensión son estrictas y conviene conocerlas antes de diseñar basándose en ella. Los valores no deben estar vacíos, deben cumplir con la sintaxis de tokens HTTP, no deben contener caracteres de control y deben ser únicos sin distinguir entre mayúsculas y minúsculas dentro del esquema. Solo se permiten tipos primitivos: cadena, booleano y entero, con number excluido explícitamente. Además, la propiedad anotada debe ser alcanzable estáticamente desde la raíz del esquema a través de una cadena que consista únicamente en properties claves: no a través de palabras clave de matriz, no a través de oneOf,anyOf,allOf, ono es, no a través de condicionales y no a través de $ref. Los objetos anidados son aceptables siempre que cada paso sea una clave properties . Una anotación en cualquier otro lugar invalida la definición de la herramienta, y un cliente conforme debe excluir esa herramienta de tools/list mientras registra una advertencia, de modo que una definición mal formada no deshabilite el resto.

Los valores que no pueden representarse de forma segura como ASCII plano se codifican en Base64 dentro de un centinela, =?base64?...?=, y la misma codificación se aplica a Mcp-NameUn detalle importante: un valor en ASCII plano que resulte ser igual al centinela también debe codificarse para eliminar la ambigüedad.

6. Por qué la discrepancia es un error

Los servidores que procesan el cuerpo de la solicitud deben rechazar aquellas en las que los valores de las cabeceras no coincidan con los valores correspondientes del cuerpo, devolviendo 400 con el error de JSON-RPC -32020. La especificación explica el motivo explícitamente, y se trata de un argumento de seguridad más que de orden: esto evita vulnerabilidades cuando diferentes componentes de la red dependen de distintas fuentes de información, como un equilibrador de carga que enruta basándose en el valor de la cabecera mientras el servidor MCP ejecuta la acción basándose en el valor del cuerpo.

Considérelo como un modelo de amenazas. Si un intermediario toma una decisión a partir de una cabecera y el servidor actúa sobre un cuerpo que indica algo distinto, un cliente que configure ambos de forma diferente puede provocar una condición de discrepancia en la fuente de información; por ejemplo, que el enrutamiento o la política se evalúen frente a un valor mientras la ejecución utiliza otro. La validación obligatoria en el lado del servidor elimina ese tipo de discrepancia para la revisión actual, y los valores codificados deben decodificarse antes de realizar la comparación.

7. Qué significa esto para una pasarela

Es poco habitual que un protocolo especifique qué debe hacer el elemento intermedio. Dado que este lo hace, el mapeo es inusualmente directo.

Enrutar sin analizar. Mcp-MethodyMcp-Name significa que un proxy puede distinguir una llamada a una herramienta de una lectura de recursos, y saber de qué herramienta se trata, solo con las cabeceras. Esa es la diferencia entre una capa compatible con MCP y una que debe deserializar cada carga útil para tomar una decisión (visión general de MCP).

Exponer la identidad de la herramienta a una capa de autorización sin analizar el cuerpo. Una solicitud tools/call conforme lleva el nombre de la herramienta en Mcp-Name. Esto proporciona a un intermediario compatible con MCP una entrada definida por el protocolo que puede utilizar al aplicar políticas por herramienta; la autenticación y la autorización deben seguir siendo aplicadas por la pasarela o el servidor, en lugar de inferirse a partir de la propia cabecera (Documentación sobre autenticación y seguridad de MCP).

Limitación de tasa por herramienta o inquilino. La especificación designa la limitación de tasa por inquilino como un uso intermedio previsto de las cabeceras reflejadas, utilizando la comprobación de versión como condición de seguridad (limitación de tasa).

Observabilidad con dimensiones útiles. El nombre del método y de la herramienta disponible sin necesidad de analizar el cuerpo es exactamente lo que requiere la telemetría por herramienta, y se alinea con las convenciones de llamada a herramientas que están surgiendo en los estándares de telemetría (documentación sobre análisis y seguimiento).

Eliminar la afinidad de sesión MCP de la capa de transporte. Al eliminar las sesiones a nivel de protocolo y limitar los flujos de respuesta a solicitudes individuales, el transporte MCP ya no requiere enrutamiento persistente ni un almacén de sesiones MCP compartido. Las aplicaciones aún pueden mantener un estado duradero mediante identificadores explícitos o almacenes compartidos, por lo que "transporte sin estado" no debe interpretarse como "aplicación sin estado". Para obtener información sobre la estructura de transporte anterior de 2025, consulte nuestra comparativa entre stdio y HTTP transmitible; los patrones generales de distribución de pasarelas se tratan en conmutación por error y equilibrio de carga.

Existe una obligación que funciona en sentido contrario y se aplica a cualquier elemento situado en la ruta. Un intermediario que no reconozca una Mcp-Param-{Name} cabecera debe reenviarla y, de lo contrario, ignorarla. Eliminar cabeceras desconocidas —un valor predeterminado común en proxies reforzados— romperá los servidores conformes que las esperan.

Dónde encaja un entorno de pruebas de agentes. El transporte sigue necesitando un llamador que decida cuándo debe invocarse una herramienta. TrueForge, el entorno de pruebas de agentes de código abierto de TrueFoundry, ejecuta ese bucle de ejecución a través de llamadas a modelos, herramientas MCP remotas, habilidades, entornos aislados, aprobaciones, gestión de contexto y estado de sesión. Su conector MCP admite servidores remotos con autenticación de cabecera u OAuth, incluida una pausa de autorización en el chat cuando un usuario aún no ha conectado un servidor. Esto hace que la separación sea clara: TrueForge orquesta el paso del agente; el HTTP transmitible define el contrato de comunicación cliente-servidor; y una pasarela MCP de TrueFoundry puede controlar el tráfico de herramientas que se enruta deliberadamente a través de ella. Ninguna de estas capas sustituye a las demás.

8. Una postura desplegable

Si gestiona servidores MCP, valide Origen, autentique las conexiones y vincule los servidores locales de forma conservadora antes de preocuparse por pulir el streaming. A continuación, emita X-Accel-Buffering: no en las respuestas SSE y comentarios de keep-alive en flujos de larga duración; el almacenamiento en búfer y los tiempos de espera por inactividad pueden enmascararse como latencia de la aplicación o fallos en el streaming. Valide la concordancia entre la cabecera y el cuerpo en lugar de confiar solo en una de las dos, y decodifique los valores codificados con centinelas antes de compararlos. Para el tráfico de revisiones anteriores de Streamable HTTP, devuelva el comportamiento de compatibilidad especificado: 405 en GET y DELETE, e ignore las cabeceras de sesión y de ID de evento, de modo que los clientes antiguos fallen o se adapten de forma predecible.

Si gestiona un intermediario en la ruta, reenvíe las cabeceras Mcp-Param-* desconocidas, compruebe la versión del protocolo antes de tratar las cabeceras reflejadas como autoritativas y aproveche lo que la duplicación se diseñó para permitir: enrutamiento, entradas de políticas, limitación de tasa y telemetría basada en el método y el nombre de la herramienta sin deserializar cada carga útil. La cabecera proporciona metadatos; su capa de identidad y autorización sigue decidiendo si el emisor puede realizar la acción.

Si está escribiendo un cliente, admita ambos tipos de contenido de respuesta, trate las líneas de comentarios SSE como ignorables y siga la secuencia de reserva: intente una solicitud moderna y, ante un 400 , inspeccione el cuerpo antes de concluir nada, ya que los servidores modernos también devuelven 400 para versiones no compatibles y fallos de validación de cabeceras. Un error moderno reconocido significa reintentar en lugar de recurrir a la reserva.

9. Lo que el protocolo resuelve —y lo que no—

El transporte del 28-07-2026 simplifica el contrato de red; no decide la lógica de negocio del agente. Elimina la afinidad de sesión a nivel de MCP, define cómo funcionan el streaming y los reintentos con ámbito de solicitud, y proporciona a los intermediarios metadatos validados que pueden utilizar para el enrutamiento y las entradas de políticas. No elige qué herramienta debe llamar un agente, no otorga al emisor permiso para usar esa herramienta, no define la política de aprobación, no persiste la memoria de la aplicación ni demuestra que un efecto secundario posterior fuera autorizado por el sistema de registro.

Esas responsabilidades pertenecen a capas adyacentes. Un tiempo de ejecución de agente como TrueForge controla el bucle de ejecución y puede gestionar conectores MCP, aprobaciones, contexto y estado de la sesión. Una pasarela MCP de TrueFoundry puede centralizar la autenticación, la autorización, el acceso a herramientas y la observabilidad del tráfico que se enruta a través de ella. El servidor MCP y la aplicación de nivel inferior siguen siendo responsables de su propia autorización de negocio y de sus efectos. Mantener esos límites explícitos es más útil que tratar un transporte más limpio como un modelo de seguridad de agentes completo.

Este artículo describe una revisión de una especificación en rápida evolución. Los niveles de requisitos aquí expuestos provienen del texto del 28-07-2026; los clientes y servidores del mundo real pueden ir por detrás de las revisiones, y la especificación prevalece sobre cualquier resumen. Esta publicación tampoco afirma que una versión específica de la pasarela TrueFoundry desplegada consuma internamente cada encabezado reflejado del 28-07-2026.

Referencias

• Model Context Protocol — Especificación de transporte HTTP transmitible (28-07-2026), la fuente de los mecanismos de transporte, la base de seguridad, los metadatos de solicitud, la validación y las reglas de compatibilidad descritas aquí.
• Model Context Protocol — Registro de cambios del 28-07-2026, y la revisión de transporte del 25-11-2025 para la configuración anterior.
• Model Context Protocol — Solicitudes de ida y vuelta múltiplesysuscripciones.
• TrueFoundry — stdio frente a HTTP transmitible: contexto de transporte anterior;Autenticación y seguridad en MCP;limitación de tasa;analítica.
• TrueForge — entorno de pruebas de agentes de código abiertoyConfiguración del servidor MCPdocumentación de conectores MCP remotos con autenticación de cabecera u OAuth, autorización en el chat, aprobaciones, gestión de contexto y sesiones persistentes.

Los mecanismos, niveles de requisitos, nombres de cabeceras, códigos de error, reglas de compatibilidad y requisitos de seguridad de estado MRTR se han parafraseado a partir del texto de la especificación del 28 de julio de 2026; el ejemplo de solicitud está adaptado de la propia ilustración de la especificación. El diseño de conexión HTTP remota de MCP ha cambiado sustancialmente a lo largo de tres etapas, por lo que la especificación prevalece sobre este resumen. Las declaraciones sobre los productos de TrueFoundry se limitan a las capacidades documentadas en las páginas actuales enlazadas; esta publicación no afirma que una versión específica de la pasarela implementada utilice internamente todas las cabeceras reflejadas en la especificación del 28 de julio de 2026.

‍