MCP 2026-07-28: la especificación stateless que rompe tus servidores (y cómo migrar sin sustos)
Respuesta directa: el 28 de julio de 2026, Model Context Protocol publicó una revisión que convierte el protocolo de stateful a stateless. Adiós al handshake initialize/initialized y a la cabecera Mcp-Session-Id; cada petición ahora se autodescribe. Si tienes servidores MCP en producción, no se rompen mañana —hay un offramp de 12 meses—, pero sí cambia cómo los despliegas, los escalas y los autorizas. Aquí tienes qué cambia de verdad, qué migrar primero y cuándo conviene no correr.
Qué ha cambiado, en una frase
MCP deja de mantener estado en el transporte. Antes, cliente y servidor negociaban una sesión (initialize), intercambiaban un Mcp-Session-Id y esa sesión vivía pegada a una instancia concreta del servidor. Eso hacía que escalar horizontalmente fuera incómodo: necesitabas sticky sessions o almacenamiento compartido para que dos réplicas hablaran del mismo cliente.
La revisión 2026-07-28 elimina esa negociación. Cada request lleva su propia identidad —versión de protocolo, identidad del cliente y capacidades— dentro de _meta. El resultado práctico: puedes poner tus servidores MCP detrás de un round-robin normal, sin estado compartido. Cualquier réplica atiende cualquier petición.
Para quien construye agentes en serio, esto es una buena noticia de arquitectura disfrazada de breaking change.
Los cambios que sí te van a tocar
1. Fin de la sesión de transporte
El initialize/initialized handshake y la cabecera Mcp-Session-Id desaparecen. Si tu aplicación necesitaba estado entre llamadas, el patrón nuevo es explícito: una tool devuelve un handle y el modelo lo pasa de vuelta como argumento en la siguiente llamada. El estado deja de ser mágico (escondido en el transporte) y pasa a ser un dato de dominio que tú controlas.
// Antes: el estado vivía en la sesión del transporte (Mcp-Session-Id)
// Ahora: la tool emite un handle explícito y el modelo lo reintroduce
{
"tool": "abrir_carrito",
"result": { "cartHandle": "cart_9f2a..." } // el servidor lo acuña
}
// siguiente llamada
{
"tool": "añadir_item",
"arguments": { "cartHandle": "cart_9f2a...", "sku": "..." }
}
Esto es más código, sí. Pero también es más honesto: el estado que importa ahora es visible, auditable y no se pierde porque un balanceador mandó la petición a otra réplica.
2. Enrutado por cabeceras
Streamable HTTP ahora exige las cabeceras Mcp-Method y Mcp-Name. ¿Por qué importa? Porque tu gateway puede enrutar y medir por esas cabeceras sin parsear el cuerpo JSON. Rate-limiting, observabilidad y multitenancy dejan de necesitar inspección profunda de payloads. Si tienes un API gateway delante (y si estás en serio, lo tienes), esto simplifica reglas.
3. Multi Round-Trip Requests (MRTR)
Antes, cuando una tool necesitaba input del usuario a mitad de ejecución, el servidor mantenía un stream abierto. Eso es exactamente lo que rompe la escalabilidad stateless. MRTR lo resuelve: el servidor responde con resultType: "input_required" y las peticiones necesarias; el cliente reintenta la llamada original con las respuestas en inputResponses. Nada de conexiones colgadas.
4. Resultados de listas cacheables
Las respuestas de tools, prompts y resources incorporan ttlMs y cacheScope. El cliente decide cuánto y con qué alcance cachear el catálogo de herramientas. Si tu servidor expone decenas de tools, esto recorta round-trips redundantes en cada arranque de agente.
5. Autorización endurecida
Aquí hay que prestar atención, porque toca seguridad:
- Validación de issuer según RFC 9207 obligatoria antes de canjear el código —mitiga ataques de OAuth mix-up.
- Soporte de
application_typepara redirects a localhost en apps de escritorio/CLI. - Credenciales de cliente ligadas al servidor de autorización que las emitió.
- Dynamic Client Registration (DCR) queda deprecado en favor de Client ID Metadata Documents (CIMD). DCR sigue funcionando con una ventana de deprecación de 12 meses, pero CIMD es el camino.
6. Tasks salen del core a una extensión
Las tasks dejan el core experimental y pasan a la extensión io.modelcontextprotocol/tasks, con endpoints tasks/get y tasks/update basados en polling, y subscriptions/listen opcional. También estrena un framework formal de extensiones (y las MCP Apps para orquestar flujos de agentes). Traducción: el core se adelgaza y lo avanzado se vuelve opt-in.
Lo que se deprecia (pero no se muere hoy)
| Elemento | Estado | Ventana |
|---|---|---|
Mcp-Session-Id / handshake | Eliminado del modelo stateless | Migrar al reintroducir estado como handle |
| Dynamic Client Registration (DCR) | Deprecado → CIMD | 12 meses mínimo |
| Roots, Sampling, Logging | Deprecados pero funcionales | 12 meses mínimo |
| Transporte legacy HTTP+SSE | Oficialmente deprecado | Offramp de ~1 año |
Los SDK Tier 1 (TypeScript, Python, Go, C#) y el SDK Rust en beta ya soportan 2026-07-28 con notas de migración para las partes que rompen.
Nuestra recomendación: qué hacer, y en qué orden
En Dribba construimos stacks agénticos para clientes con datos sensibles (FinTech, HealthTech, RetailTech), y esta es la secuencia que seguiríamos:
- No reescribas por fashion. Si tu servidor MCP funciona y no necesitas escalar horizontalmente aún, tienes 12 meses. Planifica, no corras.
- Prioriza la autorización. Los cambios de RFC 9207 y CIMD son de seguridad. Es lo primero que revisaríamos aunque no toques nada más.
- Refactoriza el estado a handles explícitos. Es el cambio con más código, pero también el que mejor envejece: te libera del sticky routing y te deja desplegar sin estado compartido.
- Actualiza el SDK antes que la lógica. Sube a la versión que soporta 2026-07-28 y apóyate en sus notas de migración; deja que el SDK absorba lo mecánico.
- Mueve tasks a la extensión solo si las usas; si no, ignóralo.
Cuándo NO migrar todavía
- Si tu servidor MCP es interno, monoinstancia y de bajo tráfico: el beneficio stateless es marginal para ti. Actualiza el SDK por seguridad y espera.
- Si dependes fuertemente de Sampling o Roots: siguen funcionando 12 meses. Migra cuando tengas un patrón de sustitución probado, no antes.
- Si estás a mitad de una entrega crítica: un cambio de transporte a mitad de sprint es cómo se introducen incidencias. Cierra la entrega, migra después.
El error caro no es migrar tarde; es migrar a medias —cambiar el transporte pero dejar el estado atado a una réplica— y descubrirlo en el primer pico de tráfico.
Por qué esto nos importa (y quizá a ti también)
MCP se está convirtiendo en el USB-C de la integración de agentes: cerca de media docena de SDK oficiales y miles de millones de descargas acumuladas. Que el protocolo pase a stateless no es un detalle académico: es lo que permite que un stack agéntico deje de ser una demo pegada con sesiones y pase a ser infraestructura que escala detrás de un balanceador como cualquier otro servicio HTTP.
En Dribba llevamos desde 2011 construyendo backend serio —Go sobre Cloud Run y Kubernetes— y somos Flutter Partner oficial de Google desde 2017, la única agencia española en su directorio. Esa mezcla, backend de producción más producto, es exactamente donde estos cambios de MCP dejan de ser teoría y se vuelven decisiones de arquitectura con coste. Si te está tocando migrar servidores MCP o diseñar un stack agéntico que no se caiga al escalar, cuéntanos tu caso: equipo 100% senior in-house, sin subcontratas.
¿Te interesa el ritmo del ecosistema? También analizamos cuándo migrar entre modelos como Claude Opus 5 y el coste de agentes con Gemini 3.6 Flash.
