¿MCP ahora es stateless? Qué cambiar en tu propio servidor MCP

Sí. MCP es stateless en la capa de protocolo desde la especificación 2026-07-28. Desaparecen el handshake initialize y Mcp-Session-Id. Cada petición lleva su versión, la identidad del cliente y sus capacidades. Una petición remota puede llegar a cualquier instancia sana sin sticky routing.

Hay un matiz importante: MCP sin estado no significa software sin estado. Tu carrito, sesión de navegador, aprobación u orden de pago pueden seguir necesitando datos duraderos. La diferencia es que ese estado debe ser explícito, direccionable y seguro dentro de tu aplicación, no memoria oculta en una sesión de transporte MCP.

Esta guía se centra en transporte y migración. Para permisos y aislamiento entre tenants, consulta nuestra arquitectura de autorización MCP empresarial. Para decidir dónde aplicar la protección, lee por qué MCP no es el límite de seguridad completo.

¿Cuál es la respuesta directa?

MCP 2026-07-28 es un protocolo de peticiones stateless y autocontenidas. Desaparece el estado del protocolo, pero el estado de aplicación sigue permitido y suele ser necesario.

La especificación oficial define las peticiones autocontenidas y la negociación de capacidades por petición como propiedades del protocolo base. En Streamable HTTP, cada mensaje es un POST nuevo. La respuesta es un objeto JSON o un stream SSE limitado a esa petición. El antiguo stream GET, la sesión de protocolo, Mcp-Session-Id y la reanudación de SSE ya no forman parte de esta revisión.

¿Qué cambió en MCP 2026-07-28?

El changelog oficial de MCP 2026-07-28 contiene la lista completa de cambios incompatibles. También documenta resultType, el fin de la reanudación de streams, JSON Schema 2020-12, nuevos códigos de error y la deprecación de Roots, Sampling, Logging y HTTP+SSE.

¿Un servidor MCP stateless puede recordar algo?

Sí. Lo que no puede hacer es depender de memoria invisible asociada a la sesión del protocolo.

Imagina que una herramienta abre un navegador y otra continúa la automatización. La primera respuesta puede devolver un browser_id opaco y aleatorio. El cliente lo entrega en la siguiente llamada. El servidor lo resuelve en un Durable Object, una base de datos u otro almacén después de validar identidad y expiración. El flujo mantiene estado, pero cada petición MCP se entiende por sí sola.

• Una petición: conserva el estado en variables locales y devuelve el resultado final.
• Varios round trips inmediatos: devuelve requestState protegido con input_required. Vincúlalo al usuario autenticado, la operación original y una expiración.
• Trabajo de larga duración: usa la extensión MCP Tasks y un taskId duradero.
• Entidades de negocio: devuelve un handle como order_id, basket_id o document_id y vuelve a autorizar cada uso.
• Notificaciones de cambios: usa subscriptions/listen. El SSE abierto pertenece a una petición, no restaura una sesión.

No incluyas secretos ni estado modificable dentro de un handle legible. Prefiere identificadores opacos o tokens de estado autenticados y cifrados con límites estrictos de tamaño, audiencia y expiración.

¿Todos los servidores MCP necesitan migración?

Todas las implementaciones necesitan una auditoría, pero no el mismo trabajo.

Un servidor puede ser stateless en operación y hablar un protocolo legacy. También puede usar el protocolo nuevo y conservar datos duraderos. Audita el comportamiento en la red y el ciclo de vida de los datos por separado.

¿Qué debes cambiar en tu propio servidor MCP?

1. Localiza estado oculto. Busca mapas de sesión, sticky cookies, Mcp-Session-Id, transportes reutilizados, listas de herramientas por conexión y almacenes de eventos SSE. Clasifica cada elemento como estado de protocolo, de petición o de negocio.
2. Implementa discovery moderno. El servidor debe soportar server/discover. Devuelve versiones, capacidades, server info, instrucciones, ttlMs y cacheScope. Nunca tomes decisiones de seguridad basadas en server info autodeclarada.
3. Valida metadatos por petición. Exige versión y datos del cliente en _meta. En HTTP, exige MCP-Protocol-Version, Mcp-Method y Mcp-Name cuando corresponda. Si header y body difieren, rechaza con HeaderMismatch.
4. Moderniza y cachea resultados. Añade resultType: "complete" a respuestas normales. Mantén tools/list en orden determinista. Configura valores reales de ttlMs y cacheScope, sobre todo cuando la autorización cambia las herramientas visibles.
5. Sustituye estado implícito por handles. Deben ser impredecibles, vinculados al usuario, limitados y revocables. Las mutaciones deben ser idempotentes para que un reintento no cobre, envíe o borre dos veces.
6. Soporta ambas eras de forma deliberada. Un servidor dual-era atiende peticiones modernas sin sesión y conserva initialize para clientes antiguos. Aísla esa ruta, mide su uso y define una fecha de retirada.
7. Prueba la arquitectura. Envía llamadas consecutivas a instancias distintas detrás de round-robin real. Prueba headers ausentes o diferentes, versiones no soportadas, handles caducados, replay, cancelación, reintentos y acceso entre tenants.

La especificación de Streamable HTTP define los headers y el comportamiento ante diferencias. Antes de elegir un corte directo, revisa la matriz oficial de versiones y compatibilidad.

¿Qué cambiamos en nuestro propio MCP de Wavect?

Aplicamos este checklist a nuestra Cloudflare Pages Function el 31 de julio de 2026 y completamos un corte directo porque no necesitábamos conservar clientes legacy.

• Stateless en proceso y protocolo: el handler no mantiene un mapa de sesiones en memoria y ahora solo acepta peticiones autocontenidas 2026-07-28.
• El estado de negocio es explícito: las herramientas de comercio usan quote IDs, order IDs, access tokens e idempotency keys.
• Discovery moderno está activo: server/discover devuelve versión, capabilities, server info, instrucciones y metadatos de caché.
• El contrato HTTP se aplica: las peticiones requieren MCP-Protocol-Version, Mcp-Method y Mcp-Name en llamadas de herramientas, con paridad entre header y body y validación explícita del origen.
• Las respuestas usan la forma 2026: discovery, listados y llamadas incluyen resultType; los listados deterministas añaden metadatos de caché veraces.
• El lifecycle legacy desapareció: initialize, ping y notifications/initialized devuelven método no encontrado en lugar de mantener un contrato antiguo.

Por eso “no guardamos sesiones MCP” no basta como prueba. La topología, la versión del protocolo y el schema de respuesta pueden estar en niveles distintos. En nuestro caso, el rediseño del estado de negocio fue pequeño. El contrato de red, los controles de seguridad y las pruebas de conformidad fueron el trabajo principal.

"MCP stateless elimina memoria oculta del transporte, no los flujos duraderos. Haz que el estado sea explícito, autenticado y seguro ante reintentos."

¿Cómo debe ser el despliegue en producción?

1. Registra versiones de clientes, transportes, funciones de sesión y tasa de errores.
2. Añade pruebas de conformidad para peticiones y resultados modernos antes de cambiar tráfico.
3. Despliega un endpoint dual-era o uno moderno separado según el control que tengas sobre los clientes.
4. Mueve clientes internos y canary a la ruta nueva. Fuerza instancias distintas en llamadas consecutivas.
5. Observa errores de versión, diferencias de headers, reintentos, latencia, efectos duplicados y fallos de autorización.
6. Publica una fecha de migración y una ventana de rollback. No borres storage legacy tras una sola prueba.
7. Retira sticky routing y sesiones solo cuando la telemetría confirme que ya no existe dependencia legacy.

Cloudflare documenta un handler stateless y una transición gradual para funciones con sesión en su guía de migración a MCP SDK v2. El mismo modelo sirve aunque uses otro runtime.

¿Qué debes preguntar a un proveedor de desarrollo MCP?

• ¿Qué versiones y eras de cliente soportará el servidor en producción?
• ¿Qué estado vive en la petición, cuál es duradero y cuál depende de una sesión?
• ¿Cómo se vinculan los handles con identidad, tenant, operación y expiración?
• ¿Cómo evita la idempotencia pagos, escrituras y efectos duplicados?
• ¿Puede el equipo demostrar dos llamadas seguidas en instancias diferentes?
• ¿Cómo valida el gateway y el origen los headers contra el body JSON?
• ¿Qué se cachea, cuánto tiempo y cómo se evita que una lista privada llegue a caché compartida?
• ¿Qué funciones deprecadas quedan y cuál es su sustitución?
• ¿Qué evidencia permite cerrar la ruta legacy: telemetría, inventario, rollback y fecha?

Si una propuesta solo dice “actualizar el SDK”, está incompleta. El entregable debe incluir inventario de estado, decisión de compatibilidad, threat model, pruebas de migración, evidencia canary y plan de rollback.

Preguntas frecuentes

¿MCP es completamente stateless ahora?

El núcleo 2026-07-28 es stateless. Las aplicaciones pueden mantener datos duraderos con handles explícitos, storage, Tasks y request state.

¿Sigue existiendo Streamable HTTP?

Sí. Sigue siendo el transporte remoto estándar, pero cada mensaje es un POST propio y ya no existen el stream GET ni la sesión de protocolo.

¿Debo seguir enviando initialize?

No en peticiones modernas. Usa metadatos por petición y, si te conviene, server/discover. Un servidor dual-era puede responder a initialize para clientes legacy.

¿Sigo necesitando Redis o Durable Objects?

No para sesiones del protocolo MCP. Sí pueden ser necesarios para jobs, órdenes, navegadores, locks, rate limits y otros datos de aplicación.

¿Puedo quitar sticky sessions de inmediato?

Solo después de probar llamadas modernas en instancias diferentes y confirmar por telemetría que ningún cliente soportado depende de la ruta antigua.

Fuentes primarias

• Especificación Model Context Protocol 2026-07-28
• Cambios y deprecaciones de MCP 2026-07-28
• Transporte MCP Streamable HTTP
• Discovery de servidores MCP
• Herramientas MCP, caché y resultados multi round-trip
• Extensión MCP Tasks
• Soporte del servidor MCP de GitHub para el protocolo stateless
• Migración de Cloudflare a handlers MCP stateless