La especificación de MCP del 2026-07-28 eliminó el handshake de initialize y la cabecera Mcp-Session-Id. Este artículo compara servidores stateless y stateful, muestra dónde va ahora el estado de las herramientas con handles, tareas y solicitudes de varios viajes de ida y vuelta, y enumera los pasos de migración.
Es probable que cada servidor MCP que creaste antes de este verano empiece igual: un cliente se conecta, envía initialize, espera la respuesta, envía initialized y solo entonces puede hacer trabajo real. La revisión del Model Context Protocol del 2026-07-28 elimina ese ritual. No hay handshake, ni cabecera Mcp-Session-Id, ni sesión a nivel de protocolo fijada a un proceso. Si ejecutas un servidor MCP detrás de un balanceador de carga, o si aplazaste ese despliegue porque las sesiones persistentes parecían una trampa, este es el cambio que esperabas.
Este artículo desglosa la especificación stateless de MCP, qué significan en la práctica los servidores stateless frente a stateful y, lo más importante, qué pasa con el estado que tus herramientas siguen necesitando. Verás los campos y cabeceras exactos que cambiaron, una lista de verificación para la migración y una breve sección sobre cómo encaja una conexión de generación de imágenes en el mismo patrón.
La Agentic AI Foundation, el proyecto de la Linux Foundation que ahora gestiona MCP, resumió la publicación en su entrada de migración. En pocas palabras: el protocolo dejó de suponer una conversación larga entre un cliente y un servidor, y empezó a tratar cada llamada como una solicitud HTTP normal.
Con el protocolo de la era 2025, lo primero que hacía un cliente era negociar. La solicitud initialize llevaba una versión del protocolo y una lista de capacidades, el servidor respondía con las suyas y el cliente confirmaba con initialized. Todo lo que venía después dependía de lo acordado en esa conexión concreta.
La nueva revisión elimina ese intercambio por completo. El servidor ya no construye una memoria privada de cada cliente, así que dos solicitudes del mismo cliente pueden responderlas dos máquinas distintas sin que ninguna lo note.
Como nada se negocia por adelantado, cada solicitud se identifica a sí misma. Un objeto _meta dentro del sobre JSON-RPC transporta la versión del protocolo, la identidad del cliente y los indicadores de capacidades. La información del cliente tiene este aspecto:
{
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
El efecto práctico es un servidor que lee todo lo que necesita de la solicitud que tiene delante. Esto es lo que cambió:
| Aspecto | Protocolo de la era 2025 | Protocolo del 2026-07-28 |
|---|---|---|
| Acuerdo de versión | Negociado una vez en initialize | Enviado en _meta en cada solicitud |
| Identidad del cliente | Guardada en la sesión | Enviada en _meta en cada solicitud |
| Capacidades | Negociadas al conectar | Enviadas por solicitud, más una llamada de consulta opcional |
| Seguimiento de sesión | Cabecera Mcp-Session-Id | Eliminada |
| Endpoints de listado | Podían variar por conexión | La misma respuesta para cualquier llamador |
💡 Consejo: Un cliente aún puede pedir las capacidades de un servidor al principio, si lo desea. Ahora es una llamada opcional, no un primer paso obligatorio.
Sobre Streamable HTTP, la especificación también define cabeceras que permiten a la infraestructura enrutar el tráfico sin analizar el cuerpo JSON:
MCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: searchUn gateway puede enviar tools/call de search a un grupo y el resto a otro, usando solo cabeceras. La limitación de tasa y el registro se simplifican por la misma razón.
Nada cambia en la forma en que el modelo ve tu servidor. Herramientas, recursos y prompts siguen siendo las tres primitivas, las solicitudes siguen siendo JSON-RPC y una herramienta sigue recibiendo argumentos y devolviendo un resultado. La diferencia está entre bastidores: los endpoints de listado ya no varían por conexión, así que tools/list devuelve la misma respuesta a todos los llamadores en lugar de una variación por sesión. Esa regla es la que hace que sea seguro guardar en caché la lista de herramientas en el borde.
Estos términos se usan a menudo sin rigor, así que aquí va la definición de trabajo. Un servidor stateful conserva algo entre solicitudes, y la siguiente solicitud solo tiene sentido si llega al mismo lugar. Un servidor stateless no conserva nada entre solicitudes, y cada solicitud contiene todo lo necesario para responderla.
Imagina una cafetería donde la camarera conoce tu pedido, tu nombre y que no tomas azúcar. Pedir te lleva tres palabras porque el contexto vive en su cabeza. Eso es un servidor stateful. Es rápido y amable, hasta que ella se va a descansar y su sustituta no tiene idea de quién eres.
Una carta funciona al revés. La dirección, el remitente y el sello van por fuera, así que cualquier empleado de cualquier sucursal puede clasificarla sin llamar a nadie. Eso es un servidor stateless, y es exactamente cómo se comporta una solicitud MCP del 2026-07-28: la versión del protocolo, la identidad del cliente y las capacidades viajan todas con la llamada.
El transporte Streamable HTTP introducido en la revisión 2025-03-26 permitía que un servidor emitiera un Mcp-Session-Id durante la inicialización. El cliente lo devolvía en cada solicitud posterior, y el servidor lo usaba para encontrar la página correcta de su libro: las capacidades negociadas, el contexto por usuario y, a veces, las suscripciones abiertas. Los servidores con transporte stdio eran stateful de una forma aún más simple, porque el propio proceso era la sesión.
Una vez que ese libro está en la memoria de un solo proceso, el balanceador de carga tiene que seguir enviando al mismo cliente al mismo proceso. Los equipos lo resolvieron de dos maneras. Las sesiones persistentes desequilibran el tráfico y se rompen cada vez que se reinicia un nodo. Un almacén compartido, como Redis, añade latencia y un nuevo punto único de fallo. Ninguna de las dos es gratis.
Sin sesiones, cualquier solicitud puede caer en cualquier instancia detrás de un balanceador round-robin sencillo, como los coches que llenan carriles de peaje idénticos. Esta es la comparación lado a lado:
| Pregunta | Servidor stateful | Servidor stateless |
|---|---|---|
| ¿Dónde vive la memoria? | En el proceso o en un almacén de sesiones | En la solicitud o en tu propia base de datos |
| Balanceador de carga | Enrutamiento persistente o almacén compartido | Round robin simple |
| Un nodo cae | Se pierden las sesiones de ese nodo | La siguiente solicitud va a otro sitio |
| Escalar horizontalmente | Añadir nodos más la infraestructura de sesiones | Añadir nodos |
| Depuración | Reproducir una sesión completa | Reproducir una sola solicitud |
| Encaje con serverless | Complicado | Natural |
Quitar las sesiones del protocolo no convierte tu aplicación en stateless. Un carrito de compra, una pestaña del navegador o un flujo de trabajo a medio terminar siguen existiendo. La diferencia es que el estado ahora vive donde debe, en tu propio almacenamiento, y el protocolo ya no lo oculta.
💡 Regla general: Si el modelo necesita continuar algo más tarde, dale un handle. Si el usuario debe responder algo a mitad de la llamada, usa una solicitud de múltiples viajes de ida y vuelta. Si el trabajo es lento, usa una tarea.
El patrón recomendado es el que llevan décadas usando las API REST. Una llamada a una herramienta genera un identificador y lo devuelve, y el modelo lo pasa de vuelta como argumento en las llamadas posteriores. La etiqueta de papel de esa cesta cumple la misma función que un basket_id.
create_basket() -> {"basket_id": "b_47f2"}
add_item(basket_id="b_47f2", sku="widget-123")
checkout(basket_id="b_47f2")
El servidor busca la cesta en una base de datos en cada llamada. Cualquier instancia puede atender cualquier paso, un reinicio no pierde nada y el modelo puede retomar el trabajo en una conversación completamente nueva mientras siga conservando el ID.
A veces una herramienta necesita una confirmación a mitad de camino, por ejemplo "¿eliminar estos 40 archivos?". En un mundo basado en sesiones, el servidor se pausaría y esperaría con una conexión abierta. Con SEP-2322, la respuesta lleva en cambio resultType: "input_required" y un token requestState opaco. El cliente reintenta la misma llamada con las respuestas en inputResponses.
Como el progreso viaja dentro de ese token, cualquier instancia que reciba el reintento puede continuar exactamente donde se quedó la anterior.
Los trabajos largos siguen el modelo del ticket de recogida. Con la extensión Tasks (SEP-2663), el cliente recibe de inmediato un taskId y consulta tasks/get hasta que el trabajo termina. La llamada se desacopla de su ejecución, así que un render de diez minutos nunca mantiene una conexión abierta, y cada consulta puede llegar a cualquier instancia.
| Situación | Patrón | Qué viaja entre llamadas |
|---|---|---|
| Trabajo que continúa más tarde | Handle explícito | Un ID como basket_id |
| Confirmación a mitad de llamada | Solicitud de múltiples viajes de ida y vuelta | requestState y inputResponses |
| Trabajo que tarda minutos | Extensión Tasks | Un taskId para consultar |
Empieza por localizar cada lugar donde tu servidor recuerda algo sobre un cliente entre solicitudes. Los sospechosos habituales son:
initialize_metaCada una necesita un nuevo hogar: la propia solicitud, tu base de datos o un handle explícito.
El SDK de TypeScript v2 se divide en paquetes específicos por lado y trae un codemod para los cambios mecánicos:
npm install @modelcontextprotocol/server
npx @modelcontextprotocol/codemod@latest v1-to-v2 .
Los SDK v2 siguen hablando el protocolo de la era 2025 por defecto, y servir la versión 2026-07-28 es una activación explícita. Eso te permite publicar primero el cambio de código y activar el protocolo cuando tus clientes estén listos. La línea v1.x seguirá recibiendo correcciones de errores y de seguridad durante al menos seis meses después de la v2.
Los mantenedores prometen al menos doce meses entre la deprecación y la eliminación, y la fecha más temprana para eliminar funciones obsoletas es el 28 de julio de 2027. Las guías de migración citan Roots, Sampling y Logging entre las funciones obsoletas (SEP-2577), con los flujos iniciados por el servidor pasando a solicitudes de múltiples viajes de ida y vuelta. Planifica el trabajo, pero no es una emergencia.
Una sesión permitía que el servidor dijera "este cliente inició sesión antes". Ese atajo desaparece. Cada solicitud debe llevar credenciales, y cada solicitud debe verificarse. Si el costo de la validación te preocupa, guarda el resultado en memoria durante unos segundos, pero nunca confíes en una solicitud solo porque la anterior parecía correcta.
Haz que los handles sean imposibles de adivinar. Un handle es solo un ID, y los ID son objetivos clásicos de ataque. b_47f2 funciona en un diagrama. En producción, genera valores aleatorios largos, guarda el propietario junto al registro y verifica en cada llamada que quien llama es dueño del handle. Caduca los que ya no necesites.
Las nuevas cabeceras de enrutamiento también ayudan aquí. Como Mcp-Method y Mcp-Name son visibles sin abrir el cuerpo, un gateway puede aplicar una política por herramienta, como límites de tasa más estrictos en una herramienta de pagos o una lista de permitidos para una herramienta destructiva, antes de que la solicitud llegue a tu código. La defensa en profundidad es más fácil cuando la capa exterior puede leer la etiqueta del sobre.
💡 Regla general: Trata cada handle como un parámetro de una URL pública. Supón que alguien probará el siguiente.
En la mayoría de los servidores, sí. Las consultas de solo lectura, el CRUD sobre una base de datos, la búsqueda y cualquier cosa que envuelva una API REST no tienen nada que recordar, así que el cambio consiste sobre todo en eliminar código. Ganas despliegues más sencillos, un encaje natural con las plataformas serverless y fallos que afectan a una sola solicitud en lugar de a una conversación entera.
Algunas herramientas mantienen algo activo: una página del navegador, una shell, un render en curso. Conserva ese estado, pero mantenlo detrás de un handle con caducidad, en un almacén al que pueda acceder cada instancia. El protocolo es stateless. Tu backend no tiene por qué serlo.
Una prueba rápida te dice lo preparado que está un servidor. Elige cualquier solicitud en curso, detén la instancia que la atiende y reintenta la misma llamada contra otra instancia. Si la respuesta es idéntica, eres stateless donde importa. Si el reintento falla, pide al cliente que empiece de nuevo o devuelve algo sutilmente distinto, todavía hay un libro oculto en memoria, y ese es el código que debes mover primero a una base de datos o detrás de un handle.
| Tipo de servidor | Mejor opción | Por qué |
|---|---|---|
| Consultas de datos de solo lectura | Totalmente stateless | Nada que recordar |
| CRUD sobre base de datos | Stateless, con el ID del registro como handle | La base de datos ya guarda la verdad |
| Control de navegador o shell | Protocolo stateless, backend stateful | El recurso activo queda detrás de un handle con caducidad |
| Renders largos y trabajos por lotes | Extensión Tasks | El sondeo sustituye a las conexiones abiertas |
MCP también es el camino por el que los asistentes llegan a herramientas creativas, y la generación de imágenes es un buen ejemplo del patrón de handles. PicassoIA expone sus modelos mediante una API para desarrolladores y una conexión MCP. La API está en https://api.picassoia.com/v1, usa un token Bearer que empieza por pia_sk_ y sigue una estructura al estilo Replicate: POST /v1/models/{owner}/{name}/predictions para iniciar un trabajo, GET /v1/predictions/{id} para consultarlo y POST /v1/predictions/{id}/cancel para detenerlo.
La generación es asíncrona. Iniciar un trabajo devuelve de inmediato un ID de predicción, y el asistente llama a la herramienta de estado con ese ID después de la espera sugerida, una y otra vez, hasta que el estado indique succeeded o failed. Ninguna conexión abierta permanece inactiva mientras trabaja la GPU, y el ID lleva toda la continuidad. Es el patrón basket_id aplicado a píxeles.
Algunos límites que conviene conocer al planificar un flujo de trabajo: 5 predicciones simultáneas por cuenta, compartidas entre tokens y conexiones MCP, prompts de hasta 4.000 caracteres y un tiempo de espera de 3 horas por trabajo.
Estos cuatro modelos están disponibles tanto a través de la API como de la conexión MCP:
Las fotos de este artículo proceden de P Image, uno de los muchos modelos de texto a imagen de la plataforma. Cuando escribas las descripciones de herramientas y los esquemas JSON que expondrá tu propio servidor MCP, un modelo de lenguaje te ahorrará tiempo. Claude Sonnet 5, GPT 5.6 Sol y Gemini 3.5 Flash están disponibles para redactar y revisar ese tipo de texto estructurado.
Ya has visto el panorama completo: sesiones fuera, handles dentro, cualquier instancia puede responder cualquier solicitud. La forma más rápida de entender el patrón es usarlo. Abre PicassoIA, elige un modelo de texto a imagen y escribe un prompt para la escena que te gustaría que tuviera el diagrama de tu propia arquitectura. Prueba con una cafetería acogedora, una caseta de peaje concurrida o una fila tranquila de servidores, y después cambia un detalle cada vez y observa cómo varía el resultado.
Cuando quieras más, explora todos los modelos en la página de todos los modelos, convierte una imagen favorita en un clip corto con un modelo de video y sigue experimentando. Cada prompt que escribes es una pequeña solicitud que lleva todo lo que necesita, que es justo la idea de esta especificación.
Elige tu idioma
