MCP adopta un modelo sin estado: guía de migración para la especificación 2026-07-28

Resumen

• La especificación MCP 2026-07-28 es la revisión más grande desde el lanzamiento del protocolo. La versión candidata quedó cerrada el May 21, 2026, y la especificación final se publicará el July 28, 2026 (MCP Blog).
• El cambio principal es un núcleo sin estado: desaparecen el handshake initialize/initialized (SEP-2575) y el header Mcp-Session-Id (SEP-2567). Cada solicitud ahora incluye su propia versión del protocolo, identidad del cliente y capacidades en _meta.
• Este es un cambio incompatible en la capa de transporte para servidores remotos, pero no en la capa de funcionalidades. roots, sampling y logging quedan obsoletos, pero no se eliminan, con un plazo mínimo garantizado de 12 meses (SEP-2596).
• Streamable HTTP no va a desaparecer. Lo que cambia es que la conexión deja de ser la unidad de sesión, así que un servidor remoto por fin puede ejecutarse detrás de un balanceador de carga round-robin convencional.
• Tres headers de operabilidad obligatorios (Mcp-Method, Mcp-Name y traceparent de W3C) permiten enrutar y rastrear el tráfico de MCP como el de cualquier API HTTP normal.
• La autorización recibe seis SEPs de refuerzo. El primero que debes implementar es SEP-2468: valida el parámetro iss según RFC 9207 para bloquear ataques de confusión de OAuth.
• La presión de tiempo es real. Si operas un servidor MCP remoto, tienes hasta finales de July para externalizar el estado de sesión, enviar los headers de enrutamiento y auditar tu código de autenticación. Después del July 28, la nueva especificación será el estándar contra el que los clientes y registros verifiquen la compatibilidad.
• Este artículo se basa en una versión candidata. La arquitectura está definida, pero el texto exacto de la especificación y las APIs de los SDK aún pueden cambiar durante el período de validación. Considera el código siguiente como patrones ilustrativos, no como código de producción listo para copiar y pegar.

Qué aprenderás aquí

• Por qué MCP está adoptando un modelo sin estado y qué fallas de producción resuelve.
• Exactamente qué cambia en el protocolo: la eliminación del handshake y del ID de sesión, y la envoltura _meta.
• Cómo sigue funcionando el trabajo iniciado por el servidor sin una conexión de larga duración (el patrón Multi Round-Trip).
• Los tres headers obligatorios y lo que permiten para el enrutamiento, la caché y el rastreo.
• Los seis SEPs de autorización y cuál es el más urgente.
• Qué significan el framework de extensiones, MCP Apps y Tasks para tu servidor.
• Una migración concreta de un servidor remoto con estado a uno sin estado, con ejemplos del antes y el después.
• Un plan de migración semana a semana y los errores que suelen afectar primero a los equipos.
• Qué deben tener en cuenta los PM sobre los plazos y los riesgos.

Esta guía está dirigida a ingenieros que crean u operan servidores MCP remotos (transporte HTTP) y a PM que necesitan definir el alcance de la migración. Si solo distribuyes un servidor stdio local para un único cliente de escritorio, gran parte de esto tiene menos impacto para ti, pero las deprecaciones también se aplican.

Por qué está cambiando MCP

El diseño anterior tenía dos problemas, y la versión candidata es la respuesta técnica a ambos (MCP Blog).

Problema 1: un handshake con estado entra en conflicto con HTTP en producción. Antes de esta versión, cada sesión se abría con initialize desde el cliente, initialized de vuelta desde el servidor y un header Mcp-Session-Id que se reenviaba en cada solicitud posterior. El servidor mantenía esa sesión en memoria. La propuesta original de un modelo sin estado, SEP-1442 (abierta el September 8, 2025), señaló directamente la consecuencia: no se puede usar un balanceador de carga simple sin estado, porque enviaría las solicitudes de un cliente a distintos servidores backend que no comparten la sesión. En la práctica, eso implicaba sesiones persistentes, un almacén de sesiones compartido o un gateway que inspeccionara los paquetes en profundidad, y un solo reinicio del servidor interrumpía todas las sesiones en curso.

Problema 2: un año de deuda operativa. No había metadatos de caché estandarizados, ni un formato de rastreo estándar, ni una política de deprecación documentada. Además, funcionalidades «experimentales» como Tasks vivían dentro de la especificación central sin reglas que definieran cómo dejarían de ser experimentales.

El roadmap de MCP para 2026 (publicado el March 9, 2026) estableció cuatro áreas de trabajo: escalabilidad del transporte, comunicación entre agentes, maduración de la gobernanza y preparación para entornos empresariales. La versión 2026-07-28 aborda las cuatro.

Nota editorial (inferencia, no especificación): el hilo conductor de esta versión es «hacer explícito el estado de los agentes y simplificar el protocolo de comunicación». Las aplicaciones basadas en agentes tienen estado; el protocolo que las transporta no necesita tenerlo. HTTP ha funcionado así durante dos décadas.

Los cinco pilares

Es fácil perderse entre los más de 20 SEPs. Se agrupan en cinco cambios fundamentales (análisis de MCP.Directory):

┌──────────────────────────────────────────────────────────┐
│              MCP 2026-07-28 — five pillars                │
├──────────────────────────────────────────────────────────┤
│  1. Stateless core      no handshake, no session id       │
│  2. Operability layer   routing headers, ttl, tracing     │
│  3. Extensions          MCP Apps + Tasks + framework      │
│  4. Auth hardening      6 SEPs aligning with OAuth/OIDC    │
│  5. Deprecation policy  12-month window, written rules     │
└──────────────────────────────────────────────────────────┘

Ten presentes estos cinco pilares y la especificación se vuelve mucho más sencilla de entender.

Pilar 1: el núcleo sin estado

Este es el cambio que afecta a todos los servidores remotos.

• SEP-2575 elimina el handshake initialize / initialized.
• SEP-2567 elimina el header Mcp-Session-Id.

En lugar de negociar una vez y recordar el resultado, cada solicitud ahora lleva su propia versión del protocolo, identidad del cliente y capacidades negociadas dentro del objeto _meta de la envoltura JSON-RPC. Cuando un cliente realmente necesita descubrir lo que puede hacer un servidor, llama a un nuevo método server/discover, que también es sin estado y admite caché.

Esta es la ventaja operativa, según la propia versión candidata: un servidor MCP remoto que antes necesitaba sesiones persistentes, un almacén de sesiones compartido e inspección profunda de paquetes en el gateway ahora puede ejecutarse detrás de un balanceador de carga round-robin convencional, enrutar mediante un header y permitir que los clientes almacenen en caché las respuestas de tools/list.

        BEFORE (2025-11-25)                    AFTER (2026-07-28)

  client                                   client
    │ initialize ───────────► server         │ tools/call (+ _meta) ─► LB ─► any replica
    │ ◄──────────── initialized │             │ ◄──────────────────────────── result
    │ Mcp-Session-Id: abc123                  │ tools/call (+ _meta) ─► LB ─► any replica
    │ tools/call (echo abc123) │             │ ◄──────────────────────────── result
    │   server holds session in memory        │   no session; any replica answers
    │   sticky routing required               │   round-robin is fine

Qué debes hacer

Si tu servidor mantiene datos de cada sesión en la memoria del proceso —un ID de carrito de compras, una referencia a un navegador o sesión, un cursor de workflow—, debes externalizarlos en una referencia opaca que conserve el cliente. El servidor la genera; el cliente la devuelve en la siguiente llamada; el servidor reconstruye el estado a partir de ella. Es el mismo patrón que una cookie firmada o un token opaco de paginación.

Trabajo iniciado por el servidor sin una conexión

Algo que suele pasarse por alto: en el modelo anterior, las llamadas del servidor al cliente (por ejemplo, para hacerle una pregunta al usuario durante una llamada a una herramienta) necesitaban un stream SSE de larga duración. Sin sesión, ese mecanismo cambia.

El reemplazo es el patrón Multi Round-Trip (SEP-2322):

1. El servidor responde a un tools/call con un InputRequiredResult que contiene un arreglo inputRequests y un requestState opaco.
2. El cliente recopila las entradas y luego vuelve a emitir la llamada con inputResponses, devolviendo el mismo requestState.
3. El servidor reconstruye lo que necesita a partir de requestState. El protocolo nunca mantiene una conexión abierta.

client                                  server (any replica)
  │  tools/call "book_flight"  ────────►│
  │ ◄──── InputRequiredResult           │  needs: confirm date
  │        { inputRequests, requestState }
  │  (ask the user / agent)             │
  │  tools/call  + inputResponses  ─────►│  rebuilds from requestState
  │        + requestState (verbatim)     │
  │ ◄──────────────── final result      │

Trampa de migración: requestState es opaco para el cliente, pero no es un secreto. El servidor firma o cifra lo que deba sobrevivir al intercambio; el cliente lo devuelve sin modificar. Tratarlo como un ID de sesión (almacenarlo del lado del servidor y usarlo como clave en memoria) reintroduce exactamente el estado que el rediseño eliminó.

Pilar 2: operabilidad — enrutamiento, caché y rastreo

Tres SEPs hacen que el tráfico de MCP se comporte como HTTP normal desde el punto de vista del enrutamiento y la observabilidad.

• Headers obligatorios (SEP-2243): cada solicitud Streamable HTTP debe incluir Mcp-Method (por ejemplo, tools/call) y Mcp-Name (el nombre de la herramienta o del recurso). Los balanceadores de carga enrutan usando estos headers sin analizar los cuerpos JSON-RPC.
• Metadatos de caché (SEP-2549): los resultados de tools/list, resources/list y resources/read incluyen ttlMs y cacheScope, basados en Cache-Control de HTTP. Los clientes obtienen una forma definida de almacenar en caché y los servidores, una forma definida de invalidar la caché.
• Rastreo distribuido (SEP-414): W3C Trace Context (traceparent, tracestate, baggage) se propaga por defecto, de modo que los colectores de OpenTelemetry pueden rastrear MCP de extremo a extremo sin código de integración adicional.

Una solicitud enrutable después de 2026-07-28 se ve así:

POST /mcp HTTP/1.1
Host: server.example.com
Authorization: Bearer <token>
Mcp-Method: tools/call
Mcp-Name: search_issues
Mcp-Protocol-Version: 2026-07-28
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

{"jsonrpc":"2.0","id":"req-1","method":"tools/call",
 "params":{"name":"search_issues","arguments":{"query":"crash"},
 "_meta":{"clientInfo":{"name":"claude","version":"3.5"}}}}

Es fácil pasar por alto los headers de enrutamiento, pero son obligatorios. Los gateways que validan el tráfico de MCP rechazarán las solicitudes que no incluyan Mcp-Method o Mcp-Name, así que un SDK de cliente antiguo que no los envíe simplemente dejará de funcionar a través de un gateway estricto.

Pilar 3: extensiones, MCP Apps y Tasks

MCP obtiene un sistema de extensiones completo. Las extensiones se identifican mediante IDs de DNS inverso, viven en sus propios repositorios ext-* con sus propios mantenedores, tienen versiones independientes de la especificación central y se negocian mediante un mapa extensions en el anuncio de capacidades. Dos se lanzan oficialmente desde el primer día:

• MCP Apps (SEP-1865): un servidor puede declarar una interfaz HTML que el cliente renderiza dentro de un iframe aislado. Las herramientas declaran de antemano qué plantillas de UI usan para que el cliente pueda precargarlas y revisarlas desde el punto de vista de la seguridad. La UI renderizada se comunica a través del mismo protocolo JSON-RPC, sin un nuevo formato de comunicación.
• Tasks (migrado fuera del núcleo experimental): trabajo de larga duración. El servidor responde a un tools/call con una referencia a la tarea; el cliente la gestiona mediante tasks/get, tasks/update y tasks/cancel. El servidor determina la creación de tareas. Ten en cuenta que se eliminó tasks/list: sin sesiones, «listar tareas entre clientes» no tiene un alcance bien definido.

Por qué esto importa más allá de las funcionalidades (inferencia): el framework de extensiones es la respuesta de gobernanza a la gran variedad de solicitudes —interfaces enriquecidas, trabajos duraderos, transferencia entre agentes— que no pertenecen a una especificación de comunicación. Un protocolo solo sigue siendo útil si la superficie sobre la que evoluciona tiene límites.

Pilar 4: refuerzo de la autorización

Seis SEPs mejoran la implementación de OAuth 2.1 / OpenID Connect en MCP. Estos son los puntos principales:

Si solo puedes actuar sobre uno, elige SEP-2468. Los ataques de confusión de OAuth se han explotado en casos reales durante años, y tratar los servidores MCP como recursos protegidos significa que los clientes MCP heredan ese modelo de amenazas. Si ya creaste un servidor autenticado (por ejemplo, siguiendo Cómo crear un servidor MCP con inicio de sesión de Auth0 en Go), esto requiere una auditoría adicional, no una reescritura.

Otros puntos importantes: esquemas y códigos de error

• JSON Schema 2020-12 (SEP-2106): inputSchema y outputSchema de las herramientas pasan al borrador 2020-12. Obtienes composición (oneOf, anyOf, allOf), condicionales (if/then/else) y $ref/$defs. Los esquemas de salida ya no tienen que estar envueltos en un objeto. Se prohíbe resolver automáticamente URIs externas de $ref y los validadores deben limitar la profundidad y el tiempo: ambas medidas protegen contra ataques de denegación de servicio.
• Cambio de código de error (SEP-2164): el código -32002 de «recurso inexistente», específico de MCP, se reemplaza por el código estándar de JSON-RPC -32602 Invalid Params. Las herramientas genéricas de JSON-RPC ahora funcionan sin una tabla de códigos específica de MCP.

Deprecaciones, no eliminaciones

La versión candidata es clara: no se elimina ninguna funcionalidad en 2026-07-28. Tres quedan obsoletas con reemplazos documentados, y la política de ciclo de vida (SEP-2577 + SEP-2596) garantiza un mínimo de 12 meses entre los estados Deprecated y Removed.

El código de un SDK que llame a roots/list el July 29 seguirá recibiendo una respuesta válida. No rompas la interfaz pública de tu API el día de la publicación final: migra al ritmo de tu SDK.

Una migración concreta

Así se ve el trabajo para un servidor remoto con estado. El ejemplo es una herramienta que agrega un artículo a un carrito de compras: el caso clásico de «mantuve el estado en la sesión». El código es pseudocódigo ilustrativo (con estilo de TypeScript) que muestra el patrón, no una API específica de un SDK.

Antes: el estado vive en el proceso del servidor

// 2025-11-25 style: the server remembers the basket per session.
const baskets = new Map<string, Basket>(); // keyed by Mcp-Session-Id

server.tool("add_to_basket", async (args, ctx) => {
  const basket = baskets.get(ctx.sessionId) ?? newBasket();
  basket.items.push(args.item);
  baskets.set(ctx.sessionId, basket); // breaks if the next request hits another replica
  return { content: [{ type: "text", text: `Basket has ${basket.items.length} items` }] };
});

El problema: baskets está en la memoria del proceso y usa un ID de sesión como clave. Detrás de un balanceador de carga, la siguiente solicitud puede llegar a una réplica que nunca ha visto ese carrito.

Después: el cliente conserva una referencia opaca

// 2026-07-28 style: no session. State travels as a signed, opaque handle.
server.tool("add_to_basket", async (args, ctx) => {
  // Reconstruct prior state from the handle the client passed back (if any).
  const basket = args.basketHandle
    ? decodeAndVerify(args.basketHandle)   // server-signed; tamper-evident
    : newBasket();

  basket.items.push(args.item);

  // Mint a fresh opaque handle for the client to echo on the next call.
  const basketHandle = signAndEncode(basket);

  return {
    content: [{ type: "text", text: `Basket has ${basket.items.length} items` }],
    structuredContent: { basketHandle }, // JSON Schema 2020-12: any JSON value is fine
  };
});

El estado ahora está externalizado. Cualquier réplica puede atender cualquier solicitud porque los datos viajan con el cliente. Si el carrito crece demasiado, almacénalo en Redis/Postgres y usa la referencia como clave (más una firma) en lugar de incluir todo el objeto. Al protocolo no le importa, siempre que ninguna réplica necesite enrutamiento persistente.

Y el despliegue se simplifica

        BEFORE                                AFTER
  ┌────────────┐                        ┌────────────┐
  │  Gateway   │  parses JSON-RPC,      │  Gateway   │  routes on Mcp-Method/
  │ (sticky)   │  pins session→replica  │ round-robin│  Mcp-Name header
  └─────┬──────┘                        └─────┬──────┘
        │ always replica A                    │ any replica, any request
   ┌────▼────┐  ┌─────────┐             ┌─────▼───┐ ┌─────────┐ ┌─────────┐
   │replica A│  │replica B│             │replica A│ │replica B│ │replica C│
   │ baskets │  │ (empty) │             │ stateless         autoscale freely │
   └─────────┘  └─────────┘             └─────────┘ └─────────┘ └─────────┘

Un plan de migración semana a semana

Adaptado de las recomendaciones de la versión candidata. La RC está cerrada; la arquitectura es definitiva.

1. Ahora (June): lee el borrador de la especificación. Haz un inventario de los servidores que mantienen estado de sesión y decide dónde externalizar cada dato. Audita tu código de autenticación frente a los seis SEPs de autorización; comienza con SEP-2468.
2. June–July: recompila usando los SDK de la RC a medida que estén disponibles (se espera que los SDK de nivel 1 —TypeScript, Python, C#, Java, Swift— ofrezcan soporte para la RC durante el período de validación). Verifica que el cliente que elijas (Claude Desktop, Cursor, Claude Code, VS Code, ChatGPT) envíe Mcp-Method y Mcp-Name.
3. July: despliega una variante sin estado de un servidor remoto detrás de un balanceador de carga HTTP convencional. Mide los resultados: ¿escala automáticamente? ¿Un despliegue gradual interrumpe las llamadas a herramientas en curso? Si antes mantenías conexiones abiertas para solicitar entradas iniciadas por el servidor, migra a Multi Round-Trip.
4. July 28 y después: cambia la versión del protocolo que declaras a 2026-07-28. Mantén operativas las funcionalidades obsoletas (roots, sampling, logging); no las elimines durante al menos 12 meses.

Errores de migración que debes evitar

• Almacenar el estado de sesión en el proceso del servidor. El nuevo contrato espera que externalices los datos de cada sesión en una referencia opaca que conserve el cliente. Migrar un servidor con estado sin cambios fallará detrás de un balanceador de carga.
• Omitir los headers de enrutamiento porque «el cuerpo tiene la misma información». Son obligatorios. Los gateways estrictos rechazan las solicitudes que no los incluyen.
• Manejar incorrectamente requestState. Es opaco para el cliente, lo firma el servidor y se devuelve sin modificar. No es un ID de sesión ni una estructura legible por el cliente.
• Apresurarse a eliminar funcionalidades obsoletas. Obsoleto no significa eliminado. Tienes un plazo mínimo de 12 meses; no rompas la interfaz pública de tu API el July 28.
• Suponer que Streamable HTTP está muerto. Sigue siendo el transporte. Solo desapareció la vinculación a la sesión: abrir y cerrar por solicitud o multiplexar, ambas opciones funcionan.

Qué significa esto para los PM

• Es un riesgo de dependencia, no una funcionalidad. Si tu producto incluye un servidor MCP remoto o depende de uno, hay trabajo considerable de transporte y autenticación que debe completarse antes de finales de July. Define su alcance ahora.
• El plazo es amplio para las funcionalidades, pero ajustado para el transporte. Las capacidades obsoletas se mantienen durante 12 meses o más, pero el transporte sin estado y los headers obligatorios son el estándar que los clientes y registros verificarán a partir del July 28.
• La ventaja es real. Después de la migración, los servidores MCP escalan automáticamente en infraestructura común, se enrutan mediante gateways estándar y se rastrean con OpenTelemetry: menor costo operativo y menos incidentes que activan alertas.
• Sigue siendo una versión candidata. La arquitectura está definida, pero planifica posibles cambios menores en la especificación y los SDK durante el período de validación.

Fuentes

Fuentes primarias:

• La versión candidata de la especificación MCP 2026-07-28 — MCP Blog (May 21, 2026)
• El roadmap de MCP para 2026 — MCP Blog (March 9, 2026)
• Explorando el futuro de los transportes de MCP — MCP Blog (December 19, 2025)
• RFC 9207 — Identificación del emisor del servidor de autorización OAuth 2.0 (referenciada por SEP-2468)

Gobernanza y análisis:

• MCP está madurando — Agentic AI Foundation (May 27, 2026)
• MCP 2026-07-28: explicación de la versión candidata sin estado — MCP.Directory
• ¿Es MCP el futuro de la integración de IA? Roadmap y próximos pasos — Knit

Lectura relacionada en este sitio:

• Cómo crear un servidor MCP con inicio de sesión de Auth0 en Go