MCP se vuelve sin estado en su mayor actualización de protocolo hasta la fecha

Anthropic lanzó la especificación MCP 2026-07-28 el 28 de julio — la revisión más grande desde que el protocolo se lanzó en noviembre de 2024 — y cambia fundamentalmente cómo funciona MCP: el protocolo ahora es sin estado. Se acabaron los handshakes initialize, las cabeceras Mcp-Session-Id y las sesiones pegajosas en el balanceador de carga. Cada petición ahora lleva su propia versión del protocolo, identidad del cliente y capacidades en _meta. Cualquier petición puede llegar a cualquier instancia del servidor detrás de un simple balanceador de carga round-robin. Esta es la actualización que convierte MCP en infraestructura empresarial de grado de producción.

Qué ocurrió

El núcleo sin estado es el titular, pero la especificación 2026-07-28 incorpora seis cambios importantes a la vez:

• Sin handshake ni sesiones. El intercambio initialize/initialized y la cabecera Mcp-Session-Id quedan retirados. Cada petición se autodescribe — los clientes que necesitan las capacidades del servidor por adelantado llaman al nuevo RPC server/discover, pero es opcional. Los servidores MCP ahora pueden ejecutarse en despliegues Kubernetes convencionales con balanceadores de carga estándar y sin almacenes Redis compartidos (Anthropic, 2026).
• Peticiones Multi Round-Trip (MRTR). Las interacciones servidor-a-cliente como elicitación y sampling ya no requieren un flujo SSE mantenido abierto. El servidor devuelve resultType: "input_required" con un token opaco requestState, y el cliente reintenta la llamada original con las respuestas del usuario. Cualquier instancia del servidor puede retomar el reintento (Anthropic, 2026).
• Enrutamiento basado en cabeceras. Cada petición Streamable HTTP ahora expone Mcp-Method y Mcp-Name en cabeceras estándar. API gateways, limitadores de tasa y WAFs pueden enrutar, limitar y medir solo con cabeceras — sin necesidad de parsear el cuerpo JSON (Anthropic, 2026).
• Resultados de listas con cursor. Los RPCs tools/list, resources/list y endpoints similares ahora devuelven un cursor nextCursor con paginación estilo has_more. Los clientes ya no necesitan mantener el estado de paginación; el servidor emite un cursor opaco (Anthropic, 2026).
• Extensiones formalizadas. Las capacidades del servidor ahora se anuncian a través de _meta.extensions, un mapa de strings a URIs (por ejemplo, "auth": "https://spec.modelcontextprotocol.io/extensions/auth/v1"). Los clientes negocian extensiones a través de cabeceras Extensible-* estándar tipo Extensible-Accept y Extensible-Use. Cada extensión define su propio contrato — autenticación, compresión, transmisión — sin modificar el núcleo del protocolo (Anthropic, 2026).
• Guía de migración y versionado semántico. Anthropic publicó una guía de migración formal y relajó el versionado semántico: los cambios mayores ahora requieren una nueva fecha-en-slug, los cambios menores son retrocompatibles. Las implementaciones existentes deben actualizarse antes de que la especificación anterior quede obsoleta en octubre de 2026.

Todo esto está documentado en la especificación completa(se abre en una pestaña nueva) y en el repo GitHub de MCP(se abre en una pestaña nueva).

Por qué importa

MCP acaba de pasar de ser un protocolo de desarrollo a un protocolo de infraestructura. El cambio sin estado es la diferencia entre ejecutar un servidor MCP en un droplet de Digital Ocean y ejecutarlo en un clúster de Kubernetes de producción detrás de un load balancer estándar.

Cada cambio en esta especificación está motivado por la misma demanda: MCP se está utilizando a escala empresarial, y las sesiones pegajosas estaban bloqueando las arquitecturas de despliegue estándar. AWS, Microsoft, Cloudflare y GitHub ya han desplegado la nueva especificación (Anthropic, 2026). Esto ya no es un experimento.

Las extensiones formalizadas son quizás el cambio más infravalorado. Hasta ahora, cada implementación de MCP que necesitaba autenticación, compresión o transmisión personalizada lo hacía de forma diferente. Las extensiones estandarizan el mecanismo de negociación para que proveedores como Cloudflare puedan incorporar autenticación a nivel de gateway sin modificar el core del servidor.

Qué hacer

1. Si mantienes un servidor o cliente MCP, empieza a planificar la migración. La especificación anterior quedará obsoleta en octubre de 2026. La guía de migración está disponible en el repo de la especificación.
2. Si estás construyendo infraestructura de agentes de IA, el cambio sin estado de MCP cambia tu arquitectura de despliegue. Puedes ejecutar servidores MCP en Kubernetes estándar con balanceadores de carga round-robin — sin Redis, sin sticky sessions, sin estado compartido.
3. Explora las extensiones. Si necesitas autenticación, compresión o transmisión personalizada en tu stack MCP, el marco de extensiones es ahora la forma estándar de hacerlo — no necesitas bifurcar el protocolo.
4. AWS, Microsoft y Cloudflare ya están en producción con la nueva especificación. Esto no es un borrador experimental. Es la nueva base estándar para la infraestructura de agentes de IA.