La trampa del estado que limitaba a MCP
El protocolo inicial de MCP imponía una restricción arquitectónica significativa: la naturaleza intrínseca del estado. Anteriormente, un cliente iniciaba la interacción con una solicitud initialize a un endpoint de MCP. El servidor entonces creaba y devolvía un session ID único, un token crítico para toda comunicación posterior entre cliente y servidor. Cada solicitud de seguimiento tenía que llevar este identificador.
Este diseño creó un defecto fundamental para despliegues escalables. El session ID obligatorio vinculaba al cliente a la instancia específica del servidor que procesó inicialmente la llamada initialize. Esto rompía los paradigmas estándar de balanceo de carga. Si un balanceador de carga, por ejemplo un router round-robin, dirigía una solicitud posterior a una instancia diferente, ese servidor carecería de cualquier registro de la sesión. El resultado era un error 400 "session not found" debilitante, que detenía las operaciones del cliente. Del mismo modo, si una instancia fallaba, todos sus estados de sesión activos se perdían instantáneamente, causando fallos inmediatos en las solicitudes del cliente.
Los desarrolladores se veían obligados a implementar soluciones alternativas complejas e ineficientes para mitigar estos problemas. Las soluciones comunes incluían implementar sticky sessions, que aseguraban que un cliente llegara constantemente a la misma instancia del servidor. Otro enfoque implicaba desplegar almacenes de estado compartidos, como una instancia de Redis, para centralizar y sincronizar los datos de sesión en todos los servidores. Ambos métodos introducían una sobrecarga operativa innecesaria, aumentaban la latencia de red y elevaban significativamente los costos de infraestructura. Estas eran cargas impuestas por el protocolo, no elecciones.
Sin estado por defecto: Un protocolo renacido
La nueva especificación de MCP, '2026-07-28', introduce un cambio radical. Dos propuestas clave, SEP-2575 y SEP-2567, redefinen el núcleo del protocolo. SEP-2575 elimina el handshake de initialize e initialized, mientras que SEP-2567 elimina el encabezado MCP-Session-Id y su sesión asociada a nivel de protocolo.
Estos cambios transforman una llamada de herramienta de varios pasos en una única solicitud HTTP autónoma. Anteriormente, el contexto estaba fragmentado; ahora, toda la información necesaria viaja en un campo meta dentro del cuerpo JSON. Este diseño hace que cada solicitud sea independiente, reflejando los principios HTTP sin estado.
La alineación con la infraestructura HTTP estándar es completa. Los nuevos encabezados, MCP-Method y MCP-Name, ahora transportan información de enrutamiento crítica. Esto permite que los componentes de red como gateways, firewalls y limitadores de tasa tomen decisiones sin analizar el payload JSON. Tal eficiencia es crucial para el rendimiento, especialmente en Cloudflare.
El protocolo ya no requiere Durable Objects para hablar MCP, simplificando el despliegue. Los servicios pueden escalar a cero cuando están inactivos, reduciendo significativamente los costos operativos y ampliando las opciones de despliegue. Este cambio elimina los puntos críticos de las sticky sessions o las instancias compartidas de Redis, haciendo que MCP sea verdaderamente sin estado por defecto.
Infraestructura más inteligente y estado de la aplicación
La ausencia de estado desbloquea enormes ventajas de despliegue. Las plataformas serverless como Cloudflare Workers y Google Cloud Run ahora escalan a cero cuando están inactivas, reduciendo drásticamente los costos operativos. Los servidores ya no mantienen conexiones persistentes, eliminando la necesidad de instancias siempre activas para mantener el estado de la sesión. Esto cambia fundamentalmente el aprovisionamiento de infraestructura.
El protocolo ya no sobrecarga la gestión de estado. En su lugar, el estado se convierte en una preocupación a nivel de aplicación. Las herramientas pueden crear identificadores explícitos, como un basket_id o browser_id. El modelo devuelve este identificador como un argumento ordinario en llamadas posteriores a la herramienta. Esto otorga a los desarrolladores una mayor flexibilidad, permitiéndoles gestionar el estado exactamente según sea necesario, en lugar de ajustarse a patrones impuestos por el protocolo.
MCP adopta el almacenamiento en caché inspirado en HTTP para mejorar la eficiencia del lado del cliente. Las nuevas sugerencias de time to live y cache scope informan a los clientes sobre la frescura de las listas de herramientas, prompts y recursos. Esto permite a los clientes almacenar respuestas con confianza, evitando conexiones persistentes para las actualizaciones. Para obtener más información sobre el diseño robusto de API sin estado, explore Statelessness in API Design: Understanding & Examples - Unkey. Estas sugerencias aseguran que los clientes sepan exactamente cuánto tiempo permanecen válidos los datos entre usuarios.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Nuevos patrones para interacciones complejas
Las interacciones complejas ahora siguen un patrón claro impulsado por el cliente. Anteriormente, el servidor enviaba preguntas de seguimiento no solicitadas, un riesgo de seguridad. La nueva especificación evita esto. Para interacciones de múltiples turnos, el servidor devuelve un resultado input_required.
Este resultado incluye una carga útil serializada request_state, que encapsula todo el contexto para la acción pendiente. Un cliente recibe input_required, solicita al usuario (por ejemplo, "¿Estás seguro?") y luego vuelve a iniciar la solicitud original. El cliente adjunta la respuesta del usuario y repite el request_state. Esto asegura que el cliente siempre dirija la interacción. Cualquier instancia del servidor puede retomar la solicitud reanudada, reforzando la naturaleza sin estado.
Las operaciones de larga duración aprovechan la extensión 'tasks' ahora oficial. Esta característica pasó de un estado experimental a uno oficial. Para una tarea como procesar un reembolso, el servidor reconoce inmediatamente la solicitud. Devuelve una respuesta indicando que el trabajo se está ejecutando, evitando el bloqueo de la conexión.
Los clientes realizan un seguimiento del progreso de forma asíncrona. Pueden consultar mediante tasks/get o suscribirse a través de subscriptions/listen. Esto permite recuperar el resultado final una vez que se completa la tarea de larga duración. Este diseño elimina la necesidad de conexiones persistentes durante cálculos prolongados, mejorando la eficiencia y resiliencia del protocolo.
Preguntas frecuentes
¿Cuál era el problema principal con el antiguo MCP con estado?
El protocolo antiguo requería IDs de sesión que vinculaban a los clientes con instancias específicas del servidor. Esto dificultaba el equilibrio de carga, requería soluciones complejas como sesiones persistentes (sticky sessions) o Redis, y hacía que el sistema fuera frágil, ya que un reinicio del servidor podía provocar la pérdida del estado de la sesión.
¿Cómo resuelve estos problemas el nuevo MCP sin estado?
Elimina por completo los apretones de manos de sesión y los IDs (especificación 2026-07-28). Cada solicitud es autónoma, lo que permite un equilibrio de carga estándar de tipo round-robin, una mayor resiliencia y la capacidad de los servidores para reducirse a cero, reduciendo los costos.
¿Cómo se gestiona el estado en el nuevo MCP si el protocolo no tiene estado?
El estado ahora se gestiona a nivel de aplicación, no a nivel de protocolo. Los desarrolladores pueden hacer que una herramienta cree un identificador explícito (por ejemplo, 'browser_id') que el modelo devuelve en llamadas posteriores, un patrón flexible común en las API HTTP estándar.
¿Qué sucede con las llamadas a herramientas de larga duración sin una conexión persistente?
La nueva especificación convierte la extensión 'tasks' en una característica oficial. Para un trabajo de larga duración, el servidor puede devolver inmediatamente un ID de tarea, y el cliente puede consultar o suscribirse a esa tarea para obtener actualizaciones de progreso y el resultado final de forma asíncrona.