MCP sin estado en la especificación del 2026-07-28: Qué cambios para la infraestructura de agentes.
La nueva revisión de MCP elimina las sesiones, agrega encabezados de enrutamiento, viajes de ida y vuelta con input_required y un OAuth más estricto. Qué significa esto para las pasarelas, la escalabilidad y la seguridad.
Fuentes: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
El Protocolo de Contexto de Modelo ha evolucionado rápidamente. Al principio, las discusiones se centraron en vincular las aplicaciones de IA con herramientas y datos. Desde entonces, ha pasado por la autorización OAuth, servidores remotos, grandes revisiones del protocolo, registros, Documentos de Metadatos de ID de Cliente y autorización empresarial. La especificación 2026-07-28 introduce un cambio aún más fundamental: el propio protocolo se vuelve sin estado.
La fase de inicialización ya no existe, al igual que las sesiones a nivel de protocolo. Un cliente ya no tiene que permanecer vinculado a la instancia del servidor que aceptó su conexión. Cada solicitud contiene suficiente información para funcionar por sí sola, y cualquier instancia compatible puede responderla.
Puede parecer una simple modificación de transporte, pero su impacto arquitectónico es mucho más profundo. Los servidores remotos pueden comportarse como cualquier servicio HTTP nativo de la nube, operando detrás de balanceadores de carga comunes, gateways API, WAF, plataformas serverless y flotas de contenedores escalables, sin necesidad de mecanismos de sesión específicos para MCP.
La revisión trae además otros beneficios: encabezados de enrutamiento estándar, resultados de detección que se pueden cachear, solicitudes de múltiples viajes, reglas de autorización más estrictas, convenciones de OpenTelemetry y un modelo de extensión formal. MCP parece menos peculiar como infraestructura, lo cual podría ser uno de los signos más claros de madurez. A continuación se explican los cambios, por qué la falta de estado es importante en entornos de producción y qué implica para la seguridad, los gateways y el entorno de ejecución general de los agentes.
Por qué las sesiones son problemáticas
MCP comenzó con un problema sencillo: proporcionar a las aplicaciones de IA una forma estándar de manejar herramientas, recursos y sistemas externos. Esto funcionaba de manera natural con clientes y servidores locales. Pero MCP a distancia cambió las cosas. Cuando los servidores pasaron a operar en contenedores, clústeres de Kubernetes, plataformas serverless e infraestructura en la nube, las sesiones a nivel de protocolo generaron los mismos problemas típicos de los sistemas distribuidos.
Un cliente iniciaba un proceso de inicialización, el servidor asignaba un Mcp-Session-Id y cada solicitud posterior debía mantener esa relación. A gran escala, esto podía significar:
- adherencia del balanceador de carga
- almacenes de sesiones compartidos
- mecanismos de conmutación por falla que comprendan las sesiones
- conexiones de larga duración
- gestión adicional del ciclo de vida
Nada de eso es imposible de gestionar, ya que los sistemas distribuidos lo han hecho durante décadas. Lo que realmente cabe preguntarse es si MCP realmente tuvo que crear esos problemas, y con 2026-07-28 la respuesta cada vez es un no.
La nueva especificación elimina por completo el proceso de intercambio initialize y notifications/initialized, las sesiones a nivel de protocolo y Mcp-Session-Id. Las solicitudes incluyen todo lo necesario para su procesamiento. Conceptualmente, la arquitectura cambia de la siguiente manera:
Cualquier instancia compatible puede manejar la siguiente solicitud. Esto se adapta mucho mejor a Kubernetes, contenedores, funciones serverless, autoscaling, infraestructura de borde y un balanceo de carga simple por round-robin.
Ya está sucediendo en la práctica. Cloudflare ha trasladado sus servidores MCP a este modelo y crea un servidor sin estado nuevo para cada solicitud. Google ha señalado que el fin de las sesiones persistentes y de la infraestructura de sesiones compartidas representa una gran ventaja para la escalabilidad. AWS AgentCore Gateway ahora admite el nuevo protocolo además de las versiones anteriores de MCP. Por lo tanto, esto forma parte del modelo de despliegue actual y no es una arquitectura teórica.
El estado no desaparece
Una distinción es importante aquí. Eliminar las sesiones MCP no impide que las aplicaciones mantengan su estado. Esto significa que el estado de la aplicación no debería ocultarse dentro del mecanismo de transporte. Tomemos como ejemplo un agente que crea un espacio de trabajo:
create_workspace()
|
v
workspace_id = ws_123
Una solicitud posterior puede especificar el resultado de forma explícita:
update_workspace( workspace_id = "ws_123" )
La primera solicitud podría llegar al servidor A y la segunda al servidor C. La aplicación sigue teniendo estado, pero ahora cuenta con un identificador explícito y no depende de un vínculo invisible entre un cliente y un proceso de servidor.
El estado del protocolo y el estado de la aplicación son cosas diferentes. El estado explícito de la aplicación es más fácil de persistir, auditar, autorizar, vencer y analizar, y los sistemas basados en agentes ganan otra ventaja: el agente puede trabajar directamente con el identificador y transferirlo entre herramientas y pasos del flujo de trabajo.
Encabezados de enrutamiento
La falta de estado soluciona un problema de infraestructura, y otro cambio puede ser igualmente importante para las implementaciones empresariales. MCP ahora estandariza los encabezados HTTP que describen la operación en curso. Por ejemplo:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
Anteriormente, un intermediario podría haber tenido que abrir el payload JSON-RPC para saber qué quería el agente. Ahora la información está visible en la capa HTTP, lo que abre algunas opciones interesantes.
Los equipos de seguridad tienen motivos para preocuparse. Los agentes tienen acceso a herramientas más potentes, y la pasarela se convierte en un lugar natural para aplicar políticas entre la intención y el efecto externo. Nada de esto elimina la necesidad de controles a nivel de aplicación o de mecanismos de gestión de agentes. De hecho, establece límites más claros entre el protocolo, la pasarela, dichos mecanismos y los sistemas que los sustentan.
Solicitar información sin sesión
Trabajar sin estado plantea un problema obvio: ¿qué pasa si un servidor necesita más información antes de poder finalizar una operación? Imagine una llamada destructiva:
delete_environment(“production”)
El servidor podría querer una confirmación primero. Mantener una sesión bidireccional abierta únicamente para ese intercambio eliminaría gran parte de las ventajas que ofrece la falta de estado.
La solución propuesta en la especificación son las solicitudes de múltiples idas y venidas (MRTR). La sesión ya no mantiene viva la interacción; en su lugar, el servidor devuelve un resultado input_required que indica qué necesita. El intercambio se lleva a cabo más o menos de esta manera:
La aprobación humana, la autenticación adicional, los parámetros faltantes, las verificaciones de políticas y otros flujos interactivos similares pueden integrarse todos en un modelo de solicitud sin estado. Esto es especialmente relevante para acciones de agentes de alto riesgo. El hecho de poder llamar a una herramienta no otorga al agente autoridad ilimitada, y las operaciones sensibles pueden incluir un punto de decisión antes de ejecutarse.
Almacenamiento en caché y observabilidad
Algunos de los cambios menos notorios pueden ser importantes a gran escala. Entre ellos se encuentran las operaciones de listado:
tools/list
prompts/list
resources/list
resources/read
Ahora es posible devolver detalles del caché como ttlMs y cacheScope, y la lista de herramientas debería aparecer en un orden determinista. Esto parece una optimización rutinaria de HTTP, pero los sistemas de IA también se benefician: definiciones estables de herramientas pueden mejorar el caché de instrucciones en el nivel del LLM, mientras que las herramientas que llegan en orden variable o que requieren ser redescubiertas repetidamente convierten una pequeña peculiaridad del protocolo en mayor latencia y costo en tokens.
La especificación también documenta cómo transportar el contexto de OpenTelemetry, con campos familiares:
traceparent
tracestate
baggage
Ese es otro caso de MCP desviándose hacia la infraestructura que los equipos de DevOps y plataformas ya conocen. El objetivo no debería ser crear un conjunto separado de herramientas de observabilidad solo para los protocolos de IA. En su lugar, se debe lograr que la actividad de los agentes sea visible dentro de los sistemas que ya utilizan las organizaciones.
La identidad cobra aún más importancia
Las solicitudes sin estado no disminuyen la importancia de la identidad; por el contrario, hacen que sea crucial manejar correctamente cada solicitud. La nueva especificación continúa con el avance de MCP hacia las prácticas establecidas de OAuth y OpenID Connect. Esto incluye la validación del emisor, cuyo propósito es contrarrestar los ataques de confusión con servidores de autorización, así como un vínculo más estricto entre las credenciales y los usuarios.
La especificación también formaliza una tendencia que ya se estaba dando: el registro dinámico de clientes está obsoleto en favor de los documentos de metadatos de ID de cliente. Los CIMD han ido emergiendo como la opción más adecuada, mientras que el DCR persiste por cuestiones de compatibilidad, y ahora el texto lo expresa claramente. Es otra señal de madurez, ya que MCP evita un sistema de identidad privado y sigue convergiendo hacia los estándares que ya utiliza la web. Esto es especialmente importante para las implementaciones de agentes empresariales, a medida que MCP pasa de unas pocas integraciones autorizadas por usuarios a un gran número de agentes, clientes, pasarelas y herramientas.
El registro es solo una parte de la autorización. A escala empresarial, la pregunta más difícil es determinar qué agentes pueden acceder a qué capacidades: cientos de agentes que llaman a cientos de servicios generan un problema de gobernanza del tipo N×M. Dos mecanismos, la Autorización Gestionada a Nivel Empresarial (EMA) y las Concesiones de Autorización por Afirmación de Identidad (ID-JAG), dirigen esa decisión hacia políticas empresariales centralizadas. Un proveedor de identidades empresariales ayuda a decidir si un agente obtiene acceso, de modo que los servidores MCP individuales no necesitan solicitar el consentimiento de los usuarios uno por uno.
MCP sin estado no reemplaza ese modelo. Solo refuerza la separación: el estado de transporte, la identidad del cliente, la política de autorización y el estado de la aplicación son aspectos arquitectónicos distintos.
Qué queda fuera del núcleo
Una parte importante de esta actualización es lo que MCP elimina o reubicación. Roots, Sampling y Logging dejan el modelo principal, y el transporte HTTP+SSE anterior da paso a Streamable HTTP. Al mismo tiempo llega un marco de extensiones formal, de modo que capacidades como Tasks pueden desarrollarse mediante extensiones sin sobrecargar el núcleo del protocolo. Eso implica un límite más claro:
MCP no necesita convertirse en todo el entorno de ejecución del agente. El mecanismo de gestión sigue controlando el entorno de ejecución más amplio, y MCP proporciona una forma estándar para que ese entorno interactúe con capacidades externas. Un protocolo maduro no se define únicamente por lo que añade, sino también por lo que decide dejar en otro lugar.
El hecho de ser sin estado no significa que sea fiable
Un servidor MCP sin estado se escala de manera más sencilla, aunque no tener estado no implica ser confiable: cada solicitud sigue atravesando una barrera de seguridad. La inyección de comandos o un contexto manipulado aún pueden influir en los agentes. Las herramientas pueden seguir teniendo privilegios excesivos, las credenciales pueden seguir estar mal configuradas, y una vulnerabilidad en la cadena de suministro aún puede introducir servidores o herramientas maliciosas.
Lo que cambia es que la arquitectura se vuelve más limpia. En lugar de tratar las sesiones de transporte como parte del modelo de seguridad, las defensas pueden centrarse en quién es de manera verificable el remitente, qué política aplica la pasarela y qué permisos otorga cada herramienta. Se deben añadir autorizaciones explícitas e identificadores de recursos explícitos, luego validar las entradas, requerir la aprobación humana para acciones sensibles, registrar datos telemétricos para auditorías y también mantener bajo control el mecanismo que utiliza el agente.
Un punto sutil: los metadatos del cliente no son automáticamente una identidad. Lo que un cliente indique sobre sí mismo en los metadatos de la solicitud no puede considerarse equivalente a una identidad establecida criptográficamente a través de OAuth u otro mecanismo confiable. Un enrutamiento e inspección más sencillos del tráfico MCP permiten a los equipos de seguridad reforzar la aplicación de las normas del protocolo sin confundir los metadatos con confianza real.
El panorama general
El cambio principal en 2026-07-28 es sencillo: MCP no tiene estado. Lo más importante es lo que esto permite. Las solicitudes MCP se comportan más como cargas de trabajo HTTP habituales. Los servidores se escalan horizontalmente sin necesidad de mantener afinidad por sesiones. Las pasarelas comprenden las operaciones MCP a través de encabezados estándar. El proceso de descubrimiento puede cachearse. Los flujos de trabajo interactivos continúan mediante solicitudes múltiples de ida y vuelta. La autorización avanza hacia las prácticas comprobadas de OAuth, la observabilidad puede utilizar OpenTelemetry y las extensiones dejan espacio para evolucionar sin convertir el núcleo en todo el entorno de ejecución del agente.
Por separado, estos parecen mejoras en los protocolos, pero juntos transmiten un mensaje más profundo. MCP comenzó resolviendo problemas de conectividad. El MCP remoto obligó al ecosistema a abordar cuestiones de identidad y autorización. CIMD y la autorización empresarial apuntan ahora hacia la gobernanza, mientras que el MCP sin estado se ocupa de la operabilidad y la escalabilidad. El protocolo se vuelve cada vez menos exótico y se adapta a las infraestructuras que las personas ya saben cómo construir, proteger, monitorear y operar. Para algo que evoluciona tan rápidamente, convertirse en una infraestructura aburrida podría ser precisamente el objetivo.
Leer más
- Notas prácticas: “MCP: Protocolo que convierte la IA de un chatbot en un agente de IA” — Guía paso a paso de las Notas prácticas: “MCP: Protocolo que convierte la IA de un chatbot en un agente de IA”: contratos, verificaciones y espacios para código listo para usar para equipos que desarrollan sistemas MCP. —
- Creación de un agente de investigación local en LM Studio con cuatro servidores MCP — Combine servidores MCP de tipo sistema de archivos, GitHub, SearXNG y Camofox en una misma conversación de LM Studio, reduzca el esquema de la herramienta, agregue una pregunta para planificar la investigación y verifique su funcionamiento con una demostración.