MCP publica la revisión 2026-07-28, la mayor desde su lanzamiento

El Model Context Protocol (MCP) publicó el 28 de julio de 2026 la especificación 2026-07-28, la revisión más grande y significativa desde que se creó el estándar. El cambio central es que MCP deja de depender de sesiones fijas entre cliente y servidor y pasa a operar como un protocolo sin estado (stateless), capaz de escalar sobre infraestructura HTTP común. Amazon ya lo soporta en AgentCore Gateway, la puerta de enlace de Amazon Bedrock AgentCore que conecta agentes con funciones Lambda, APIs y servidores MCP detrás de un único endpoint.

En las versiones anteriores del protocolo, cada conexión por Streamable HTTP arrancaba con un intercambio inicial entre cliente y servidor para acordar versión de protocolo y capacidades. Al cerrarlo, el servidor entregaba un identificador de sesión (el header Mcp-Session-Id) que el cliente tenía que repetir en cada pedido siguiente. Ese identificador ataba al cliente a la instancia de servidor que lo había emitido, así que escalar un servidor MCP en paralelo obligaba a usar sesiones pegajosas en el balanceador de carga, un almacén de sesiones compartido entre instancias, o ambas cosas.

Cada pedido viaja solo

Con 2026-07-28, ese esquema desaparece: los cambios están descriptos en las propuestas SEP-2575 y SEP-2567. Cada pedido incluye ahora la versión de protocolo, la información del cliente y sus capacidades dentro de un parámetro llamado _meta, por lo que ya no hace falta ningún intercambio previo. Un método nuevo, server/discover, permite consultar en cualquier momento qué soporta un servidor determinado. El resultado es que una llamada a una herramienta queda autocontenida y puede enrutarse a cualquier instancia disponible, sin depender de contexto de sesión previo. Para las aplicaciones que sí necesitan continuidad entre llamadas, como armar y completar un carrito de compras, el protocolo sigue permitiendo pasar un identificador explícito como parámetro de la propia herramienta, siguiendo el mismo patrón que ya usan las APIs HTTP convencionales.

La revisión también suma un sistema de extensiones gobernado, refuerza la autorización alineándola con las prácticas empresariales de OAuth 2.0 y OpenID Connect, y fija garantías de ciclo de vida: una política de vigencia de funciones, el propio marco de extensiones y una exigencia de suite de conformidad, pensadas para que futuras revisiones no vuelvan a romper capacidades centrales del protocolo.

Cómo lo activa AWS

En AgentCore Gateway, los operadores habilitan la nueva versión llamando a UpdateGateway con la lista de versiones de protocolo que quieren que su gateway soporte, sin tener que tocar cada target por separado. La adopción es opcional: un gateway puede anunciar 2026-07-28 junto con una versión anterior, como 2025-11-25, y los clientes que sigan pidiendo la versión vieja no notan ningún cambio. Cada pedido llega con un header Mcp-Protocol-Version; si la versión solicitada no figura entre las que soporta el gateway, este responde con un error HTTP 400 (código -32022) junto con la lista de versiones disponibles. Los pedidos que no incluyen ese header se procesan por defecto con la versión 2025-03-26.

El cambio de fondo apunta también a los intermediarios de red. Hasta esta revisión, la operación que ejecutaba cada pedido era opaca para cualquier componente entre cliente y servidor: balanceadores de carga, gateways de API y limitadores de tasa debían parsear el cuerpo JSON-RPC completo para saber qué método se estaba invocando. Al mover la información de versión y de la llamada a headers y metadatos explícitos, esos componentes pueden tomar decisiones de ruteo, cacheo y trazabilidad sin abrir el contenido de cada pedido.