MCP es stateless: qué cambia la spec 2026-07-28 y qué tienes que hacer ahora

La gente del Model Context Protocol congeló el 21 de mayo de 2026 el release candidate de la versión 2026-07-28 de la spec, y desde el 28 de julio de 2026 es final. El SDK de TypeScript v2.0.0 con soporte para ella también está fuera. Es el cambio más grande del protocolo desde el primer lanzamiento, y si tú mismo operas servidores MCP o estás ahora con L4 y L6, merece la pena entenderlo ya y no cuando todos los SDK hayan cambiado. Seis Specification Enhancement Proposals trabajan juntas para convertir MCP en un protocolo sin estado. Suena académico, pero tiene consecuencias muy concretas para el despliegue, la autenticación y tu código. Repaso los diez puntos que de verdad cuentan.

Paso 1, el núcleo en una frase

MCP es ahora stateless a nivel de protocolo. Hasta 2025-11-25 tenías que levantar una sesión antes de poder siquiera llamar a una herramienta. Esa sesión ataba al cliente exactamente a la instancia de servidor que la había emitido. Con 2026-07-28 cada petición se basta a sí misma y puede aterrizar en cualquier instancia.

Esa es la idea de la que depende todo lo demás. Cuando la has interiorizado, los otros nueve puntos casi se deducen solos.

Paso 2, el handshake y la sesión ya no están

El handshake initialize/initialized se eliminó (SEP-2575). La versión de protocolo, la información del cliente y las capabilities, que antes se intercambiaban una vez al establecer la conexión, viajan ahora en _meta en cada petición. Si un cliente necesita las capacidades del servidor por adelantado, las obtiene con el nuevo método server/discover.

La cabecera Mcp-Session-Id y la sesión que colgaba de ella también desaparecen (SEP-2567). Así se ve la diferencia. Antes, con sesión:

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}

Ahora, una única petición que se explica sola:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Paso 3, qué significa esto para tu despliegue

Aquí se vuelve práctico. Un servidor MCP remoto necesitaba hasta ahora sesiones sticky, un almacén de sesiones compartido y en parte deep packet inspection en el gateway. Todo eso desaparece. El mismo servidor corre ahora detrás de un balanceador round-robin completamente normal.

Si venías escalando tu servidor en horizontal y las sesiones sticky te daban dolor de barriga, esa es la mejor noticia de toda la spec. Tiras infraestructura fuera en vez de añadir más.

Paso 4, mantener estado sin sesión

Stateless no significa que tu aplicación ya no pueda tener estado. Los servidores que necesitan estado entre llamadas lo hacen ahora como las APIs HTTP lo han hecho siempre. Devuelves desde una herramienta un handle explícito, por ejemplo un basket_id o un browser_id, y el modelo te lo vuelve a pasar en llamadas posteriores como un argumento normal y corriente.

Eso es más que un simple sustituto del estado de sesión. El modelo puede combinar esos handles entre varias herramientas y pasarlos de un paso a otro. El estado es visible para el modelo en vez de estar escondido en metadatos de transporte. En la práctica esa suele ser la solución limpia.

Paso 5, nuevas cabeceras de enrutado

El transporte Streamable HTTP exige ahora las cabeceras Mcp-Method y Mcp-Name (SEP-2243). Con ellas, balanceadores, gateways y limitadores de tasa pueden enrutar por la operación sin leer el cuerpo. Importante para ti si construyes infraestructura propia. El servidor rechaza peticiones en las que cabecera y cuerpo se contradicen. Así que pon bien las cabeceras, si no te llevas errores.

Paso 6, las listas se vuelven cacheables

Los resultados de list y de lectura de recursos llevan ahora ttlMs y cacheScope (SEP-2549), modelados según HTTP Cache-Control. Tu cliente sabe así exactamente cuánto tiempo sigue fresca una respuesta de tools/list y si puede compartirla entre varios usuarios. Un stream SSE permanentemente abierto ya no es la única forma de enterarse de que una lista ha cambiado.

A eso se suma W3C Trace Context en _meta (SEP-414). Los nombres de clave traceparent, tracestate y baggage están ahora fijados en la spec, de modo que una traza desde la app anfitriona, pasando por el cliente, el servidor y todo lo que hay detrás, aparece como un único árbol de spans en un backend de OpenTelemetry.

Paso 7, las extensiones pasan a primera clase

Extensiones ya había en 2025-11-25, pero sin proceso formal. SEP-2133 cambia eso. Las extensiones tienen ahora IDs de DNS inverso, se negocian mediante un mapa extensions en las capabilities, viven en repositorios ext-* propios y se versionan de forma independiente de la spec.

Dos extensiones oficiales vienen de entrada. MCP Apps (SEP-1865) permite a los servidores servir interfaces HTML interactivas que el host renderiza en un iframe aislado. Y Tasks, que en 2025-11-25 todavía era una funcionalidad central experimental, pasa a ser extensión. Si construiste contra la vieja API experimental de Tasks, tienes que migrar. tasks/list desaparece, porque sin sesiones no se puede acotar con seguridad. En su lugar manejas una tarea con tasks/get, tasks/update y tasks/cancel.

Paso 8, la autenticación se pone más estricta

Seis SEPs endurecen la autorización para acercarla a despliegues reales de OAuth 2.0 y OpenID Connect. Dos de ellas deberías conocerlas.

Los clientes tienen que validar ahora el parámetro iss en las respuestas de autorización, según RFC 9207 (SEP-2468). Es una protección barata contra una clase de ataques mix-up especialmente frecuente en el patrón MCP de un cliente con muchos servidores. En una versión futura los clientes rechazarán respuestas sin iss, así que empieza ya a enviarlo. Además los clientes declaran su application_type en el registro dinámico de clientes (SEP-837). Eso evita el caso habitual de que un servidor de autorización clasifique erróneamente como "web" a un cliente de escritorio o de línea de comandos y rechace su URI de redirección a localhost.

Paso 9, deprecaciones y un código de error que cambia

Tres funcionalidades centrales quedan deprecadas bajo la nueva política de ciclo de vida (SEP-2577). Roots, sampling y logging. Son deprecaciones de mera anotación, siguen funcionando, al menos un año más. Los sucesores recomendados son parámetros de herramienta y URIs de recurso en lugar de roots, integración directa con las APIs de los proveedores de LLM en lugar de sampling, y stderr u OpenTelemetry en lugar de logging.

Un detalle que te puede morder si no prestas atención. El código de error para un recurso que falta pasa del -32002 propio de MCP al estándar de JSON-RPC -32602 Invalid Params (SEP-2164). Si tu cliente compara con el valor literal -32002, ajústalo. Y inputSchema y outputSchema son ahora JSON Schema 2020-12 completo (SEP-2106), incluidos oneOf, anyOf, $ref y $defs. Eso sí, las URIs $ref externas no puedes resolverlas automáticamente.

Paso 10, qué deberías hacer ahora en concreto

La ventana entre RC y final se acabó, la spec rige. Si operas un servidor, esto ya no es prepararse sino migrar: hazte con la spec y el changelog contra 2025-11-25 y prueba tu servidor contra la versión final. Sobre todo los tres puntos que son breaking changes de verdad. El handshake que falta, la cabecera de sesión eliminada y el código de error cambiado. El SDK de TypeScript se ha puesto al día con la v2.0.0, para los demás SDK de tier 1 merece la pena mirar sus notas de versión.

Si estás empezando ahora con MCP, esto no es motivo de pánico. Los conceptos básicos de L4, servidor, cliente y herramientas, se quedan exactamente igual. Lo que cambia está un nivel más abajo, en el transporte. Aprende primero el modelo, después los detalles de transporte.

Qué sigue

Si el modelo mental todavía no lo tienes asentado, pasa primero por Qué es MCP. Quien planee un servidor propio encuentra la entrada en Planificar un servidor MCP. Para la parte de autenticación, que esta spec endurece, el siguiente paso es el playbook Auth de servidor MCP con OAuth 2.1. Y cuando hayas terminado y quieras publicar, ayuda Publicar un servidor MCP.

Fuente

• Anuncio oficial con todos los números de SEP: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• Spec y changelog contra 2025-11-25: https://modelcontextprotocol.io