MCP stateless: cómo funciona el protocolo sin sesiones

Monta un MCP server remoto, ponle dos réplicas detrás de un balanceador y mira qué pasa.

La primera petición del cliente aterriza en la réplica A, que hace el handshake y devuelve un Mcp-Session-Id. La segunda petición cae en la réplica B, que no tiene ni idea de qué sesión es esa. Error.

A partir de ahí solo tienes dos salidas, y ninguna es bonita: activar sticky sessions en el balanceador (y rezar para que ninguna réplica se caiga) o montar un almacén compartido de sesiones (y meterle un Redis a un servidor que solo quería devolver el tiempo que hace en Bilbao).

Ese era el peaje de MCP hasta la versión 2026-07-28 de la especificación. Y es exactamente el peaje que esa versión elimina: el core del protocolo pasa a ser sin estado.

No es un ajuste menor ni una optimización de rendimiento. Es un cambio de arquitectura que toca cómo se conecta un cliente, cómo un server pide datos a mitad de una llamada, cómo se cachean las tools y qué features siguen vivas. Si tienes un MCP en producción o estás pensando en montar uno, esto te afecta.

En este artículo te cuento:

• Por qué MCP nació con estado y qué problema real generaba eso al escalar
• Qué desaparece exactamente (initialize, Mcp-Session-Id) y qué lo sustituye
• El matiz que casi todo el mundo entiende mal: protocolo sin estado no es aplicación sin estado
• Cómo un server te pide una confirmación a mitad de llamada sin mantener un stream abierto
• Qué queda deprecado, cuánto tiempo tienes y qué no deberías adoptar ya en un proyecto nuevo
• Qué cambia en tu código según el SDK que uses, y por qué es probable que la respuesta sea “nada, de momento”

Vamos al lío.

¿Por qué MCP nació como un protocolo con estado? ¶

Porque nació pensando en tu portátil.

Cuando MCP apareció, el caso de uso dominante era un servidor local hablando con un cliente local por stdio. Un proceso, un cliente, una conexión viva de principio a fin. En ese escenario, una sesión no cuesta nada: la sesión es el proceso.

Con ese modelo mental se diseñó el arranque: el cliente enviaba initialize, el server respondía con sus capacidades, el cliente confirmaba con initialized y a partir de ahí ambos sabían con quién estaban hablando. Un handshake clásico, como el de cualquier protocolo con conexión. Si te suena a los protocolos que ya conoces, es porque MCP bebe conscientemente de ellos: lo contamos al repasar los protocolos que están definiendo cómo la IA habla con nuestras herramientas, empezando por el veterano LSP.

El problema llegó cuando MCP salió del portátil.

Los servers remotos convirtieron ese handshake en una atadura. La cabecera Mcp-Session-Id obligaba a que todas las peticiones de un cliente acabaran en la misma instancia, porque el estado de la sesión vivía en la memoria de esa instancia concreta. Y eso choca de frente con cómo se despliega cualquier otra cosa en la web moderna: contenedores efímeros, autoescalado, funciones serverless que se levantan y se mueren, balanceadores que reparten sin preguntar.

⚠️ El coste real de las sesiones no era el rendimiento. Era la infraestructura extra que te obligaban a montar: sticky sessions, almacenes compartidos y un plan para cuando una réplica se reinicia en mitad de una conversación.

Añade que MCP dejó de ser un experimento. Según el anuncio oficial de la versión 2026-07-28, los SDK de primer nivel acumulan cerca de 500 millones de descargas al mes, y tanto el de TypeScript como el de Python han superado los 1.000 millones de descargas totales. A esa escala, obligar a cada servidor del ecosistema a resolver el problema de las sesiones por su cuenta deja de ser un detalle de diseño.

¿Qué significa que el core de MCP sea stateless? ¶

Significa que cada petición se explica a sí misma y puede aterrizar en cualquier instancia de tu servidor sin que esa instancia sepa nada de lo que pasó antes.

Dos cosas desaparecen del core:

• El intercambio initialize / initialized (SEP-2575)
• La cabecera Mcp-Session-Id (SEP-2567)

Lo que antes se negociaba una vez al arrancar ahora viaja en cada mensaje. La versión del protocolo va en su propia cabecera, y la identidad y capacidades del cliente van dentro del campo _meta de los parámetros:

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

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

Esa petición es autosuficiente. Da igual qué réplica la reciba: tiene todo lo necesario para responderla. Round-robin del montón, sin almacén compartido, sin afinidad de sesión.

¿Y si un cliente quiere saber qué sabe hacer el servidor antes de pedirle nada? Para eso está server/discover, un RPC nuevo que devuelve las capacidades. La diferencia con el viejo initialize es que es opcional. Ya no es un peaje obligatorio antes de la primera llamada útil: es una consulta que haces si te interesa.

El resultado práctico es que un MCP server pasa a ser una carga de trabajo HTTP normal y corriente. Se despliega, se escala y se cachea como cualquier API que ya tengas en producción. Ese es el objetivo declarado de todo el rediseño.

Guía interactiva gratis

¿Has llegado a las tripas del protocolo sin haber montado nunca un MCP?

La parada 15 del curso es justo eso: MCP explicado desde el principio, cliente y servidor, para traer el mundo real a la IA. Diecisiete paradas donde eliges agente, presupuesto y proyecto, y sales con una checklist a tu medida.

Entra en el curso gratis →

¿Protocolo sin estado significa que mi aplicación no puede tener estado? ¶

No, y este es el punto donde más gente se lía.

Que el protocolo no arrastre estado no te obliga a escribir una aplicación sin memoria. Lo que cambia es dónde vive ese estado. Antes lo escondías en el transporte, en una sesión que el modelo no veía. Ahora lo pones donde el modelo sí lo ve.

El patrón que recomiendan los propios maintainers es sencillo: si tu server necesita recordar algo entre llamadas, una tool emite un identificador explícito (un handle) y el modelo lo pasa de vuelta como argumento en las llamadas siguientes.

// La tool que abre el trabajo devuelve un handle visible para el modelo
{
  "content": [{ "type": "text", "text": "Análisis iniciado" }],
  "structuredContent": { "analysisId": "an_7f3d9c" }
}

// Y la siguiente llamada lo recibe como un argumento más
{
  "name": "get_analysis_status",
  "arguments": { "analysisId": "an_7f3d9c" }
}

Puede parecer un rodeo comparado con una sesión implícita. En realidad es mejor, y por una razón que va más allá del escalado: el modelo ve el handle. Puede razonar sobre él, puede pasarlo a otra tool, puede mencionarlo en su respuesta y puede recuperarlo del historial de la conversación. Un Mcp-Session-Id en una cabecera HTTP era invisible para el modelo, que es precisamente el actor que decide qué llamar a continuación.

🔑 La sesión no desaparece, se muda. Pasa de ser un detalle oculto del transporte a ser un dato de primera clase que el modelo maneja igual que cualquier otro argumento.

Hay una ventaja secundaria que se nota en cuanto tienes tráfico real: los handles explícitos son depurables. Aparecen en los logs, en las trazas y en el historial de la conversación. Cuando algo falla, puedes seguir el hilo.

¿Cómo pide un server datos al usuario a mitad de una llamada? ¶

Con MRTR (Multi Round-Trip Requests, SEP-2322), que es la pieza que hace viable todo lo anterior.

El problema es evidente en cuanto quitas las sesiones. Imagina una tool que va a borrar tres ficheros y quiere confirmación antes. Con el modelo antiguo, el servidor lanzaba una petición al cliente (elicitation/create) por el canal bidireccional que ya estaba abierto. Sin sesiones no hay canal abierto, así que hacía falta otra forma.

MRTR le da la vuelta al flujo: en vez de que el servidor llame al cliente, el servidor responde pidiendo lo que le falta y el cliente vuelve a llamar con la respuesta.

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": { "type": "elicitation", "message": "Delete 3 files?" }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Fíjate en requestState: ahí va codificado el punto en el que se quedó la operación. El cliente reintenta la llamada original adjuntando las respuestas en inputResponses, y esa segunda petición puede aterrizar en una instancia distinta del servidor, porque trae consigo todo el contexto necesario para continuar.

MRTR sustituye a tres mecanismos que dependían de un stream abierto: elicitation/create, sampling/createMessage y roots/list.

El efecto colateral es interesante: funcionalidades que hasta ahora estaban vetadas a los servidores sin estado se vuelven posibles. En el propio anuncio de la especificación, el equipo de Supabase lo explica sin rodeos — soportar elicitaciones llevaba tiempo en su hoja de ruta, pero al ejecutar su MCP sin estado no era algo que pudieran hacer con facilidad. Con MRTR pueden confirmar con el usuario antes de actuar: el coste de crear un proyecto, o una consulta que va a borrar datos.

¿Por qué las cabeceras Mcp-Method y Mcp-Name son obligatorias? ¶

Para que la infraestructura que ya tienes delante del servidor pueda hacer su trabajo sin abrir el cuerpo de la petición.

En Streamable HTTP, la especificación 2026-07-28 exige dos cabeceras nuevas (SEP-2243):

Parece un detalle cosmético. No lo es.

Hasta ahora, un gateway, un rate limiter o un WAF que quisiera aplicar una política distinta a tools/list y a tools/call tenía que parsear el JSON del body para enterarse de qué le estaban pidiendo. Eso es caro, es frágil y en muchos productos de red directamente no es una opción.

Con las cabeceras, todo eso se resuelve donde se resuelve el resto del tráfico HTTP de tu empresa: en la capa de red. Puedes limitar por tool concreta, enrutar las llamadas pesadas a un pool distinto, autorizar por método o medir el consumo por herramienta. Sin tocar el servidor.

💡 Si alguna vez has tenido que explicar a tu equipo de plataforma por qué el MCP necesitaba reglas especiales en el balanceador, esta es la parte del cambio que te va a ahorrar esa conversación.

¿Se pueden cachear los catálogos de tools? ¶

Sí, y es de las mejoras que más se notan en la factura.

Las respuestas de tools/list, prompts/list, resources/list y resources/read incorporan dos campos nuevos (SEP-2549), modelados sobre el Cache-Control de HTTP de toda la vida:

• ttlMs: cuánto tiempo puede considerarse fresca la respuesta antes de volver a pedirla
• cacheScope: public o private, es decir, si un intermediario compartido puede cachearla o si es específica de ese usuario

A eso se suma que las listas tienen orden determinista. Y ahí está la ganancia que no es obvia: si el catálogo de tools que le inyectas al modelo llega siempre en el mismo orden y con el mismo contenido, la caché de prompts del proveedor del modelo se mantiene estable entre reconexiones. Un catálogo que se reordenaba en cada arranque invalidaba esa caché una y otra vez, y eso lo pagabas en tokens de entrada.

Estos campos complementan a las notificaciones listChanged, no las sustituyen. La diferencia es que ya no necesitas un stream SSE vivo para enterarte de que algo cambió: te basta con respetar el TTL.

¿Qué cambia en la autorización de un MCP server? ¶

La autorización es donde más tiempo se pierde al integrar un MCP, y esta versión mete mano en cuatro frentes. Si tu servidor es público o corporativo, esta sección es la que más te va a costar ignorar.

Validación del emisor (SEP-2468). Los servidores de autorización deben devolver el parámetro iss según el RFC 9207, y el cliente tiene que validarlo antes de canjear el código. Esto cierra el agujero clásico de confusión entre servidores de autorización, donde un atacante conseguía que un código emitido por un servidor se canjeara contra otro.

application_type en el registro (SEP-837). Los clientes ahora declaran su tipo de aplicación durante el registro dinámico. Si alguna vez montaste un cliente de línea de comandos y el flujo OAuth te devolvió un error de redirect_uri sin motivo aparente, la causa probable era esta: el servidor de autorización rechazaba los redirects a localhost porque te trataba como una aplicación web.

Credenciales atadas a su emisor (SEP-2352). Unas credenciales sirven solo contra el servidor de autorización que las emitió. Nada de reutilizarlas cruzando emisores.

DCR deja paso a CIMD. El Dynamic Client Registration queda deprecado en favor de los Client ID Metadata Documents. Sigue funcionando por compatibilidad, pero desaparecerá en una versión futura. Si estás arrancando una integración nueva, mira hacia CIMD.

Construye agentes con criterio

MCP es un nivel de la arquitectura, no la arquitectura entera

Seis niveles para que un agente aguante en producción: tools, guardarraíles, memoria, skills, MCP y orquestación multiagéntica revisada por otro modelo. Con código, Mastra y Open Code, para que el protocolo encaje en un sistema y no al revés.

Ver la masterclass entera →

Masterclass premium · 6 niveles de arquitectura, en directo

¿Qué son las extensiones oficiales de MCP? ¶

Son la respuesta del proyecto a una tensión que llevaba tiempo acumulándose: cómo añadir funcionalidad ambiciosa sin engordar el core ni romperlo cada seis meses.

SEP-2133 formaliza las extensiones como componentes de primera clase, con identificadores en formato DNS inverso y versionado independiente del protocolo. Cada extensión evoluciona a su ritmo, en su propio repositorio, y pasa por un carril específico del proceso SEP.

Tasks es el primer inquilino de peso. Sale del core experimental y se convierte en la extensión io.modelcontextprotocol/tasks (SEP-2663). El ciclo de vida cambia: el servidor responde a un tools/call con un handle de tarea y el cliente consulta el progreso con tasks/get (por sondeo) y tasks/update. El método tasks/list desaparece, precisamente porque enumerar las tareas de “tu sesión” no significa nada cuando no hay sesión. Si implementaste Tasks con la API experimental de la versión 2025-11-25, aquí hay migración de verdad.

MCP Apps (SEP-1865) también pasa a ser extensión oficial, con lo que las interfaces HTML renderizadas por el servidor dentro de iframes aislados dejan de ser terreno experimental. Si quieres ver cómo se construyen, lo desarrollamos en la guía de MCP Apps y su SDK oficial.

¿Qué queda deprecado y cuánto tiempo tengo? ¶

Doce meses como mínimo, y esa cifra es en sí misma la mejor noticia de esta versión.

SEP-2577 introduce una política formal de ciclo de vida: Activo → Deprecado → Eliminado, con una ventana mínima de doce meses entre la deprecación y la retirada. Suena a burocracia hasta que recuerdas cuántas veces has tenido que reaccionar a un cambio de una librería porque nadie te avisó con tiempo. Esto te permite planificar.

Lo que entra en la lista:

Todo eso sigue funcionando. Nadie te va a romper el servidor mañana. Pero la señal para quien empieza algo nuevo es inequívoca: no construyas sobre estas cinco cosas.

La deprecación de Sampling merece un comentario aparte, porque es la que más levanta cejas. La idea original era elegante: que el servidor pudiera pedirle al cliente que ejecutara una inferencia, aprovechando el modelo que el usuario ya estaba pagando. En la práctica, la adopción por parte de los clientes fue escasa y el mecanismo exigía mantener el canal bidireccional abierto. La recomendación ahora es que, si tu servidor necesita un modelo, hable con el proveedor por su cuenta.

¿Se rompe mi MCP server actual? ¶

No. Y conviene decirlo con todas las letras porque la palabra “breaking” ha circulado mucho.

Los clientes y servidores existentes siguen funcionando. Actualizar el SDK no cambia el protocolo de tu servidor: adoptar la versión 2026-07-28 es una decisión explícita que tomas tú cuando te venga bien. Los SDK de Python y TypeScript en su versión 2 responden tanto al nuevo server/discover como al initialize de toda la vida.

Dicho eso, el camino de migración no es igual en los cuatro SDK de primer nivel:

El SDK de Rust soporta la nueva especificación en beta.

La división del paquete de TypeScript es la que más ruido genera, y tiene una lectura positiva que se pasa por alto: separar cliente y servidor adelgaza lo que acabas instalando. El equipo de Manufact, que mantiene el framework mcp-use, reporta en el anuncio oficial haber recortado el tamaño del paquete alrededor de un 83% y ganado un 25% de velocidad gracias a esa separación.

🛡️ Antes de tocar nada: si tu servidor está en producción y funciona, fija la versión de tus dependencias. En Python y TypeScript hay un salto de versión mayor, y no quieres descubrirlo en un despliegue de viernes.

Si estás empezando de cero, el orden sensato es otro: monta primero un servidor que funcione y luego decides el modo de protocolo. Para esa parte tenemos un tutorial completo para crear un MCP desde cero con TypeScript, con tools, validación de esquemas y los dos transportes. Y si lo que quieres es conectar servidores ya existentes a tu agente, la guía de instalación de MCP en los 16 agentes más usados te ahorra el rato de adivinar el formato de cada fichero de configuración.

¿Qué otros cambios pequeños trae la especificación? ¶

Tres, y los tres se agradecen más de lo que aparentan.

Esquemas JSON completos (SEP-2106). Los campos inputSchema y outputSchema de una tool soportan JSON Schema 2020-12 entero: composición con oneOf, anyOf y allOf, condicionales y referencias $ref. Adiós a aplanar esquemas que en tu dominio eran claramente una unión de casos.

Errores estandarizados (SEP-2164). Cuando un recurso no existe, el error pasa a ser el -32602 (Invalid Params) de JSON-RPC, en lugar del -32002 propio de MCP. Un código estándar menos que tratar de forma especial en tu cliente.

Trazas distribuidas (SEP-414). El estándar W3C Trace Context (traceparent, tracestate, baggage) viaja dentro de _meta, lo que permite correlacionar una llamada a través de SDK y gateways con tu OpenTelemetry de siempre. Cuando una llamada a una tool tarda ocho segundos y no sabes en qué salto se fue el tiempo, esto es exactamente lo que echabas de menos.

¿Merece la pena migrar ya? ¶

Depende de dónde te duela hoy.

Migra pronto si tu servidor es remoto y multiusuario, si estás pagando sticky sessions o un almacén de sesiones que solo existe para MCP, si despliegas en serverless o en contenedores efímeros, o si tienes un gateway al que le vendría bien enrutar por cabeceras.

Puedes esperar si tu servidor es local por stdio y de un solo usuario. En ese escenario, las sesiones nunca fueron el problema y el beneficio inmediato es pequeño. Aprovecha para no adoptar lo deprecado y ya migrarás cuando toque.

Migra sí o sí, aunque no corras prisa, si implementaste Tasks con la API experimental anterior. Ahí el cambio de forma es real y tasks/list no va a volver.

Y en cualquiera de los tres casos, hay una decisión que puedes tomar hoy sin migrar nada: no construir sobre Roots, Sampling ni Logging en lo que empieces a partir de ahora. Es gratis y te ahorra el trabajo del año que viene.

TL;DR ¶

• 🚀 Desde la versión 2026-07-28, el core de MCP es sin estado: fuera el handshake initialize/initialized y fuera la cabecera Mcp-Session-Id. Cada petición se explica a sí misma vía _meta.
• 🔧 Protocolo sin estado no es aplicación sin estado: si necesitas memoria entre llamadas, emite un handle explícito desde una tool y deja que el modelo lo pase de vuelta.
• ⚡ MRTR sustituye a elicitation, sampling y roots: el servidor responde input_required con un requestState codificado y el cliente reintenta con las respuestas, sin streams abiertos.
• 🎯 Roots, Sampling, Logging, HTTP+SSE legacy y DCR quedan deprecados con una ventana mínima de 12 meses. No los adoptes en proyectos nuevos.
• 📚 Tu servidor actual no se rompe: actualizar el SDK no cambia el protocolo, es una decisión explícita. Fija versiones antes de tocar nada.

Preguntas frecuentes sobre MCP stateless ¶

¿Qué versión de la especificación MCP introduce el core sin estado? ¶

La versión 2026-07-28. Es la revisión más grande del protocolo desde su lanzamiento y elimina el handshake initialize/initialized (SEP-2575) junto con la cabecera Mcp-Session-Id (SEP-2567).

¿Mi MCP server actual deja de funcionar con la nueva especificación? ¶

No. Los servidores y clientes existentes siguen funcionando, y actualizar el SDK no cambia de forma automática el protocolo que habla tu servidor. Adoptar la nueva versión es una decisión explícita. Los SDK v2 de Python y TypeScript responden tanto a server/discover como al initialize clásico.

¿Cómo mantengo estado entre llamadas si el protocolo ya no tiene sesiones? ¶

Con un handle explícito. Una tool devuelve un identificador (por ejemplo analysisId) y el modelo lo pasa como argumento en las llamadas siguientes. La ventaja frente a una sesión oculta en el transporte es que el modelo ve ese identificador y puede razonar con él.

¿Qué es MRTR en MCP? ¶

Multi Round-Trip Requests (SEP-2322) es el mecanismo que permite a un servidor pedir datos al usuario a mitad de una llamada sin mantener un stream abierto. El servidor responde con resultType: "input_required", los inputRequests que necesita y un requestState codificado; el cliente reintenta la llamada original adjuntando inputResponses.

¿Para qué sirven las cabeceras Mcp-Method y Mcp-Name? ¶

Permiten que gateways, rate limiters y WAFs enruten, autoricen y midan el tráfico MCP sin parsear el cuerpo JSON de cada petición. Mcp-Method indica la operación (tools/call) y Mcp-Name el recurso concreto (search). Son obligatorias en Streamable HTTP desde la versión 2026-07-28.

¿Puedo cachear la lista de tools de un MCP server? ¶

Sí. Desde SEP-2549, las respuestas de tools/list, prompts/list, resources/list y resources/read incluyen ttlMs (cuánto tiempo son frescas) y cacheScope (public o private). Además tienen orden determinista, lo que ayuda a mantener estable la caché de prompts del proveedor del modelo.

¿Qué funcionalidades de MCP están deprecadas? ¶

Roots, Sampling y Logging, además del transporte HTTP+SSE legacy y el Dynamic Client Registration. Todas siguen funcionando, con una ventana mínima de doce meses antes de su retirada según la política de ciclo de vida de SEP-2577.

¿Qué cambia en el SDK de TypeScript para MCP? ¶

La versión 2 no llega como una versión nueva de @modelcontextprotocol/sdk, sino como dos paquetes separados: @modelcontextprotocol/server y @modelcontextprotocol/client. Los esquemas de tools adoptan Standard Schema, con soporte para Zod v4 y Valibot.

¿Sigue existiendo tasks/list en MCP? ¶

No. Tasks pasa a ser la extensión io.modelcontextprotocol/tasks (SEP-2663) y el método tasks/list se elimina, porque enumerar las tareas de una sesión pierde sentido sin sesiones. El ciclo se gestiona con tasks/get por sondeo, tasks/update y tasks/cancel.

¿Qué es CIMD y por qué sustituye a DCR en MCP? ¶

Los Client ID Metadata Documents son el mecanismo hacia el que se mueve MCP para identificar clientes OAuth, en lugar del registro dinámico (DCR). DCR queda deprecado por compatibilidad pero desaparecerá en una versión futura, así que las integraciones nuevas deberían apuntar a CIMD.

Fuentes ¶

• The 2026-07-28 Specification — Model Context Protocol Blog
• The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol Blog
• Beta SDKs for the 2026-07-28 MCP Spec Release Candidate — Model Context Protocol Blog
• SEP-2549: TTL for List Results — modelcontextprotocol/modelcontextprotocol

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter