MCP 2026-07-28: qué cambia y cómo usarlo desde AgentCore Gateway

Resumen ejecutivo

La especificación MCP 2026-07-28 es la revisión más grande del protocolo desde su lanzamiento. Entre las novedades clave están la transición a un modelo stateless (sin sesiones de protocolo), un sistema gobernado de extensiones, un refuerzo en los mecanismos de autorización alineado con prácticas empresariales de OAuth 2.0 y OpenID Connect, y garantías de ciclo de vida para reducir roturas en el futuro. Amazon Bedrock AgentCore ya soporta esta versión a través de AgentCore Gateway: pueden habilitarla con una actualización de configuración (UpdateGateway) y elegir qué versiones anunciar.

Por qué importa este cambio para empresas en América Latina

Para equipos de TI y arquitectos de soluciones en la región, la migración a un protocolo sin estado resuelve un problema práctico: escalar endpoints de modelos y agentes sobre infraestructura HTTP estándar sin depender de sesiones pegajosas en balanceadores o de almacenes de sesión compartidos. En ambientes empresariales con demandas variables —por ejemplo, comercio electrónico, fintech o servicios de atención— esto simplifica la operación, reduce costos y mejora la resiliencia.

Además, el enfoque opt-in y la compatibilidad por versión permiten una transición controlada: nada cambia automáticamente hasta que tanto su gateway como sus clientes decidan usar la nueva versión.

¿Qué significa que MCP sea ahora stateless?

En versiones previas, cada interacción Streamable HTTP con un servidor MCP empezaba con un intercambio initialize/initialized que resultaba en un Mcp-Session-Id emitido por el servidor. Ese identificador obligaba a que todas las solicitudes posteriores llevaran la cabecera Mcp-Session-Id, lo que fijaba al cliente a la instancia de servidor que generó la sesión. Para escalar horizontalmente había que usar sesiones pegajosas en el balanceador, un almacén de sesiones compartido o ambas soluciones.

La especificación 2026-07-28 elimina esa necesidad: ya no hay handshake obligatorio ni sesión a nivel de protocolo (SEP-2575 y SEP-2567 quitan estos requerimientos). En su lugar, cada solicitud incluye la versión del protocolo, información del cliente y capacidades dentro del parámetro _meta. Si una herramienta necesita conocer qué soporta un servidor, puede llamar al nuevo método server/discover en cualquier momento.

Ejemplo simplificado de una llamada autocontenida (formato tal como se utiliza en la especificación):

POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: create_basket Content-Type: application/json Accept: application/json,text/event-stream

{“jsonrpc”:“2.0”,“id”:1,“method”:“tools/call”,“params”:{“name”:“create_basket”,“arguments”:{},“_meta”:{“io.modelcontextprotocol/clientInfo”:{“name”:“my-app”,“version”:“1.0”}}}}

Y la respuesta típica:

{“jsonrpc”:“2.0”,“id”:1,“result”:{“resultType”:“complete”,“content”:[{“type”:“text”,“text”:“Created basket bsk_a1b2c3”}],“structuredContent”:{“basket_id”:“bsk_a1b2c3”},“isError”:false}}

Si una aplicación requiere continuidad de estado entre llamadas, el patrón recomendado es pasar explícitamente un identificador (por ejemplo, basket_id) como parámetro de herramienta; ese identificador proviene de sus propias capacidades o servicios, no de una sesión MCP implícita.

Beneficios operativos: enrutamiento, caching y trazabilidad

Al eliminar la opacidad de la operación (antes encapsulada por la sesión), la nueva versión permite que proxies, balanceadores y gateways tomen decisiones sin tener que reensamblar o parsear el cuerpo de la petición. Cada solicitud lleva metadatos suficientes para enrutar, aplicar límites de tasa o hacer caching a nivel de HTTP de forma más eficiente. Esto reduce la complejidad en la capa de infraestructura y facilita la integración con soluciones de observabilidad y tracing ya establecidas en la pila empresarial.

Gobernanza, extensiones y compatibilidad hacia el futuro

Para minimizar rupturas en revisiones futuras, la especificación introduce mecanismos de gobernanza: un lifecycle policy para características, un framework de extensiones gobernadas y el requisito de una suite de conformidad. La idea es permitir evolución sin afectar las capacidades centrales, y que los cambios incompatibles sean la excepción, no la regla.

Seguridad y autorización

El nuevo MCP refuerza la autorización alineándose más cercano con prácticas empresariales de OAuth 2.0 y OpenID Connect. Esto facilita la integración con sistemas corporativos de identidad y control de acceso, especialmente útil para organizaciones que deben cumplir normativas o políticas internas de gobernanza de datos.

AgentCore Gateway: cómo lo soporta y cómo activarlo

AgentCore Gateway (una capacidad de Amazon Bedrock AgentCore) ya permite habilitar la versión 2026-07-28. La activación es opt-in: deben invocar UpdateGateway con la lista de versiones que desean anunciar en el campo de configuración correspondiente. Puntos clave:

• AgentCore Gateway anuncia las versiones del protocolo que soporta mediante un campo de configuración único.
• En cada solicitud, el cliente selecciona la versión usando la cabecera MCP-Protocol-Version.
• Si el gateway anuncia múltiples versiones (por ejemplo, 2026-07-28 y 2025-11-25), los clientes que sigan solicitando la versión antigua no experimentan cambios.
• Si una solicitud llega con una versión no soportada, el gateway responde con HTTP 400 (código -32022) y una lista de versiones soportadas.
• Las solicitudes que omiten la cabecera MCP-Protocol-Version aplican por defecto la versión 2025-03-26.

Según la especificación, no hay pasos por destino ni interrupciones automáticas: los clientes existentes continúan funcionando exactamente como antes hasta que opten por usar la nueva versión.

Recomendaciones prácticas para equipos en la región

• Prueben la nueva versión en entornos de staging antes de habilitarla en producción. AgentCore Gateway permite co-existencia de versiones, lo que facilita pruebas A/B.
• Aprovechen el nuevo _meta para exponer información de cliente que facilite trazabilidad y políticas de enrutamiento en su infraestructura de red.
• Si su arquitectura requiere estado entre llamadas, adopten un identificador explícito dentro del flujo de herramientas (p. ej., basket_id) en lugar de depender de sesiones de protocolo.
• Evalúen la integración con sus sistemas de identidad corporativa para sacar partido de las mejoras en OAuth 2.0 / OpenID Connect.

Conclusión

La especificación MCP 2026-07-28 representa un cambio estructural importante: transforma a MCP en un protocolo que escala sobre infraestructura HTTP estándar, introduce mecanismos de gobernanza para evolución segura y mejora la alineación con prácticas empresariales de autorización. AgentCore Gateway ya soporta la versión y permite una adopción gradual y controlada. Para equipos y decisores en América Latina, esto significa menos complejidad operativa al escalar agentes y mejores opciones para integrar MCP dentro de arquitecturas corporativas existentes.