Introducción
Desde su lanzamiento, el Model Context Protocol arrastraba una limitación estructural que cualquier equipo de ingeniería que intentó desplegarlo a escala reconoce de inmediato: su arquitectura stateful exigía mantener sesiones persistentes entre cliente y servidor. Sin round-robin, sin serverless, sin despliegues edge — cada conexión debía permanecer anclada a la misma instancia. El escalado horizontal, trivial en cualquier API REST, se convertía en un problema de arquitectura de primer orden.
La especificación publicada el 28 de julio de 2026 cierra definitivamente ese capítulo. Es la quinta revisión del protocolo, y con diferencia la más profunda desde su lanzamiento.
Un protocolo verdaderamente sin estado
El cambio central es de naturaleza arquitectónica: MCP abandona su modelo bidireccional con sesiones para adoptar un enfoque request/response sin estado. Cada solicitud se vuelve autodescriptiva — lleva consigo la versión del protocolo y las capacidades del cliente en sus metadatos. La cabecera Mcp-Session-Id desaparece. El handshake initialize/initialized queda eliminado de la especificación.
Para los equipos de DevOps, las consecuencias son inmediatas: un servidor MCP puede ahora operar detrás de cualquier infraestructura HTTP estándar — balanceadores de carga round-robin, funciones serverless, nodos edge. Sin sesiones pegajosas, sin estado compartido entre instancias. El escalado horizontal vuelve a ser tan sencillo como en cualquier microservicio sin estado.
Para las interacciones que aún requieren varios intercambios — recolección de entradas adicionales, validación progresiva — la spec introduce las Multi Round-Trip Requests: el servidor señala que una respuesta está incompleta sin necesidad de mantener una conexión persistente abierta, preservando la compatibilidad con infraestructuras stateless.
Un marco oficial de extensiones
Más allá de la arquitectura de red, la spec 2026-07-28 establece un framework oficial para extender el protocolo sin modificar su núcleo. Dos extensiones inauguran este marco. Tasks — gestión de trabajos asíncronos de larga duración — sale del estado experimental para convertirse en la extensión io.modelcontextprotocol/tasks, dotada de un mecanismo de consulta (tasks/get) y actualización (tasks/update). MCP Apps permite integrar interfaces de usuario directamente en los flujos MCP. Una tercera extensión, Enterprise Managed Authorization, apunta a despliegues corporativos con requisitos estrictos de identidad.
OAuth 2.0 y OIDC reforzados
En el terreno de la autenticación, la spec refuerza su alineación con OAuth 2.0 y OpenID Connect. La validación del issuer según la RFC 9207 pasa a ser obligatoria. El Dynamic Client Registration queda deprecado en favor de los Client ID Metadata Documents, un enfoque más adecuado para entornos enterprise conectados a sistemas de identidad como Microsoft Entra u Okta.
Los cuatro SDK Tier 1 listos para producción
Los SDK de TypeScript, Python, Go y C# se publican simultáneamente con soporte completo de la especificación 2026-07-28. Un quinto SDK, en Rust, está disponible en versión beta. En cuanto a deprecaciones, las capacidades Roots, Sampling y Logging disponen de un período de transición de al menos doce meses. El transporte HTTP+SSE heredado también tiene un año para ceder paso a la nueva arquitectura.
Qué conviene anticipar ahora
Para los equipos que mantienen servidores MCP en producción, esta versión supone una ruptura beneficiosa, pero que exige una auditoría. El handshake de sesión desaparece, el transporte SSE queda deprecado y ciertas capacidades core cambian de estatus. La ventana de doce meses es generosa — pero conviene hacer el inventario cuanto antes, antes de que las dependencias se consoliden alrededor de comportamientos que pronto serán eliminados.