La especificación Model Context Protocol lanzada el 28 de julio de 2026 elimina infraestructura en lugar de agregar capacidad. El handshake initialize desapareció. El encabezado Mcp-Session-Id desapareció. Lo que permanece es un núcleo de protocolo stateless donde cada solicitud lleva todo lo que un servidor necesita para responderla — ninguna conexión previa requerida. Google y Hugging Face co-lideraron el MCP Transports Working Group bajo la Agentic AI Foundation. Los SDKs TypeScript y Python superaron 1 billón de descargas totales cada uno antes de la publicación.

El problema es la escala. Bajo la especificación de 2025-11-25, los clientes se fijaban a un único contenedor que contiene estado de la sesión. Tres pods detrás de un balanceador de carga significaba que la segunda solicitud podría caer en la máquina equivocada, devolviendo 400 Session Not Found. Las soluciones eran costosas: reglas de sesión pegajosa que impedían el escalado automático, almacenes Redis que agregaban una lectura y escritura a cada llamada de herramienta, e inspección de paquetes a nivel de puerta de enlace para enrutar por sesión. Un fallo de pod eliminaba las sesiones activas. Hugging Face midió la sobrecarga como más de 100 mensajes de protocolo MCP por cada llamada de herramienta.

La motivación de Google era la escala a costo. Su MCP Toolbox for Databases registró más de 20 millones de llamadas de herramienta en más de 40 bases de datos en un único mes. Los viajes de ida y vuelta de Redis y el enrutamiento pegajoso son partidas en una factura de infraestructura. Kurtis Van Gent, mantenedor central MCP de Google Cloud, escribió que los equipos necesitaban que MCP se escalara a través de millones de consultas concurrentes en Google Cloud.

La solución elimina el handshake initialize/initialized y el encabezado Mcp-Session-Id. La versión del protocolo, las capacidades del cliente y la identidad ahora viajan en un campo _meta en cada solicitud. Tres nuevos encabezados HTTP — Mcp-Protocol-Version, Mcp-Method y Mcp-Name — permiten que las puertas de enlace enruten, autoricen y establezcan límites de velocidad sin analizar el cuerpo JSON-RPC. Las respuestas List pueden incluir instrucciones de caché. Resultado: cualquier instancia de servidor responde a cualquier solicitud, los balanceadores round-robin estándar funcionan sin cambios, y los servidores MCP se ejecutan como funciones serverless que escalan a cero cuando están inactivos. El GitHub MCP Server, impulsado por el SDK Go v1.7.0 de Google, ya eliminó el almacenamiento de sesión Redis.

Protocolo stateless no significa aplicación stateless. Si una herramienta crea una sesión del navegador, carrito de compras o transacción de base de datos, devuelve un identificador. El modelo lo devuelve como un argumento ordinario en la siguiente llamada. Así es como funcionan las APIs HTTP. Los identificadores explícitos permiten que el modelo razone sobre el estado, componga entre herramientas y lo transmita entre pasos de maneras que los metadatos de transporte opacos nunca permitieron.

La especificación trae dos preocupaciones para los equipos en 2025-11-25. Primero, migración: dejar de confiar en Mcp-Session-Id, mover el estado por sesión a argumentos explícitos de herramienta, emitir los nuevos encabezados en solicitudes Streamable HTTP y apuntar a un lanzamiento del SDK de Tier 1 que incluya soporte 2026-07-28. Segundo, deprecación: Roots, Sampling y Logging están deprecados con una ventana de eliminación de 12 meses — más pronto julio de 2027. Las adiciones de seguridad incluyen verificación del emisor RFC 9207 e indicadores de recurso RFC 8707.

Para los equipos que construyen con MCP, la lista de verificación de migración es corta. El SDK maneja la mayoría del trabajo de transporte. El riesgo real: servidores de terceros no mantenidos que nadie actualizará antes de que se cierre el período de deprecación.