MCP 2026-07-28: servidores MCP stateless, sin sesión

El 28 de julio de 2026 el Model Context Protocol publica la revisión más grande desde su lanzamiento, y el titular es contundente: los servidores MCP dejan de tener estado a nivel de protocolo. Se van el header Mcp-Session-Id y el handshake initialize, y con ellos la razón por la que hasta ahora tu infra de agentes necesitaba sticky sessions y un store de sesión compartido. Si venís escalando servidores MCP detrás de un balanceador, esto te cambia el diseño.

El spec 2026-07-28 de MCP es la revisión que convierte al Model Context Protocol en un protocolo stateless: elimina la sesión del transporte Streamable HTTP para que cualquier request pueda caer en cualquier instancia del servidor. Lo mantiene el equipo de Model Context Protocol (originado en Anthropic, hoy con gobernanza abierta). Está en Release Candidate desde el 21 de mayo de 2026 y se publica en firme el 28 de julio de 2026.

¿Qué significa que un servidor MCP sea "stateless"?

MCP 2026-07-28: el spec stateless que jubila las sticky sessions

Significa que el protocolo ya no guarda estado entre requests: no hay una sesión que el servidor tenga que recordar de una llamada a la otra. Según el blog oficial de Model Context Protocol, con el spec 2026-07-28 "cualquier request de MCP puede caer en cualquier instancia del servidor, y el ruteo pegajoso y los stores de sesión compartidos que antes necesitaban los despliegues horizontales ya no hacen falta". En criollo: un pool de servidores MCP idénticos detrás de un balanceador round-robin común, sin afinidad de sesión.

Hasta esta revisión, el transporte Streamable HTTP (que reemplazó al viejo SSE y se consolidó como transporte de producción en la revisión 2025-06-18) emitía un Mcp-Session-Id opaco en el initialize y el cliente lo reenviaba en cada request. Eso obligaba a que todas las llamadas de una misma conversación aterrizaran en la misma instancia. Escalar horizontalmente exigía session affinity en el balanceador o un backend de estado compartido. Eso es exactamente lo que la 2026-07-28 elimina.

¿Qué se rompe para el que escribe servidores MCP?

Se rompe todo lo que dependía de la sesión y del handshake: si tu servidor leía capacidades del cliente en el initialize o guardaba estado atado al Mcp-Session-Id, ese código deja de funcionar. Estos son los cambios concretos que documentan las fuentes técnicas sobre el spec:

Se elimina el handshake initialize/initialized. En su lugar hay un método nuevo server/discover que el cliente llama on-demand para traer las capacidades y la identidad del servidor.
Los metadatos de protocolo viajan en _meta en cada request. La versión de protocolo y las capacidades del cliente ahora se leen de claves como io.modelcontextprotocol/protocolVersion, /clientInfo y /clientCapabilities en cada llamada, no una sola vez al inicio.
Aparecen headers obligatorios para rutear sin abrir el body. Cada POST de Streamable HTTP lleva MCP-Protocol-Version: 2026-07-28 más Mcp-Method y Mcp-Name, de modo que la infra pueda rutear y limitar tasa por operación sin inspeccionar el cuerpo del request.
Las listas dejan de variar por conexión. tools/list, resources/list y prompts/list ya no dependen de la sesión, y las respuestas de list/read suman ttlMs (pista de frescura) y cacheScope (public o private) para que se puedan cachear.
El mismatch de versión ahora es un error explícito. Si cliente y servidor no coinciden, la respuesta es un UnsupportedProtocolVersionError en vez de una negociación en el handshake.

¿Cómo mantengo estado si ya no hay sesión?

Con handles explícitos: el servidor genera un identificador desde una tool y el modelo lo pasa como un argumento común en las llamadas siguientes. En vez de esconder el estado en metadata del transporte, ahora es un dato de primera clase que el modelo ve y compone. El blog oficial lo plantea como una ventaja de diseño: "el modelo puede componer handles entre tools, razonar sobre ellos y pasarlos entre pasos de formas que el estado de sesión gestionado externamente, escondido en la metadata del transporte, nunca permitió realmente".

El patrón se ve claro en la extensión Tasks, que en esta revisión dejó de ser experimental y se rediseñó alrededor del stateless: una tools/call para trabajo largo responde con un task handle, y el cliente maneja el progreso con tasks/get, tasks/update y tasks/cancel. El estado del trabajo vive en el handle, no en una sesión pegada a una instancia.

¿Qué features quedan deprecadas en el spec 2026-07-28?

Tres features del core entran en deprecación —Roots, Sampling y Logging— con una política formal que garantiza un mínimo de 12 meses entre el aviso y la remoción. No desaparecen el 28 de julio; tenés al menos un año para migrar. Los reemplazos sugeridos:

Roots → parámetros de tool, URIs de recurso o configuración del servidor. El scope de archivos/carpetas se pasa explícito en vez de negociarse por fuera.
Sampling → integración directa con la API del proveedor de LLM. Si el servidor necesita un modelo, lo llama él mismo en vez de pedirle al cliente que muestree.
Logging → stderr u OpenTelemetry. El logging estructurado del protocolo se reemplaza por las herramientas de observabilidad que ya usás en tu stack.

¿Qué es MCP Apps, la otra novedad grande?

MCP Apps es una extensión oficial que permite a un servidor entregar interfaces HTML interactivas que el host renderiza en un iframe con sandbox. Las tools declaran su template de UI por adelantado, así el host lo puede prefetchear y cachear, y toda acción iniciada desde esa UI pasa por el mismo camino de auditoría y consentimiento que una llamada directa a la tool. Es la respuesta del protocolo a los servidores que quieren mostrar algo más rico que texto, sin abrir un agujero de seguridad.

¿Qué podés hacer con esto hoy?

Empezá por validar contra el Release Candidate antes del 28 de julio: la ventana de diez semanas hasta la publicación final existe justamente para que quienes mantienen SDKs y clientes prueben los cambios contra cargas reales. Pasos concretos si operás servidores MCP en tu cloud server:

Revisá tu balanceador. Si tenías session affinity o sticky routing para MCP, planificá sacarlo: con la 2026-07-28 un round-robin plano alcanza y simplifica el despliegue horizontal.
Auditá dónde leés capacidades del cliente. Si dependés del initialize, migrá esa lógica a leer _meta por request e implementá server/discover.
Buscá estado escondido en la sesión. Todo lo que colgaba del Mcp-Session-Id hay que rediseñarlo con handles explícitos pasados como argumentos.
Ponete la fecha de deprecación en el radar. Roots, Sampling y Logging siguen andando, pero conviene planificar la migración dentro de la ventana de 12 meses en vez de que te agarre el deadline.

Si estás armando infra de agentes con MCP self-hosted, esta revisión te saca de encima el problema de escalar sesiones, que era una de las fricciones más molestas. Como lectura complementaria sobre correr un servidor MCP en tu propia infra, en este mismo blog está la Review de Coolify v4: PaaS self-hosted con servidor MCP para IA.

Preguntas frecuentes

¿Cuándo se publica el spec 2026-07-28 de MCP?

El 28 de julio de 2026 se publica la especificación final. El Release Candidate quedó bloqueado el 21 de mayo de 2026, y las diez semanas intermedias son para que los mantenedores de SDKs y clientes validen los cambios contra cargas reales.

¿Los servidores MCP viejos dejan de andar de golpe?

No de golpe. La revisión introduce una negociación de versión explícita (con UnsupportedProtocolVersionError ante mismatch) y una política de deprecación con un mínimo de 12 meses de aviso para las features que salen (Roots, Sampling, Logging). Vas a necesitar actualizar servidor y cliente a la misma revisión, pero tenés margen para migrar.

¿Todavía necesito sticky sessions para escalar MCP?

Con el spec 2026-07-28, no. Al eliminarse el Mcp-Session-Id y la sesión de protocolo, cualquier request puede caer en cualquier instancia, así que un balanceador round-robin común reemplaza al ruteo con afinidad de sesión y a los stores de sesión compartidos.

¿En qué se diferencia del transporte Streamable HTTP anterior?

Streamable HTTP ya existía (reemplazó a SSE y se consolidó en la revisión 2025-06-18), pero seguía siendo con estado: emitía un Mcp-Session-Id que el cliente reenviaba en cada llamada. La 2026-07-28 mantiene Streamable HTTP como transporte pero le quita la sesión, que es lo que lo vuelve verdaderamente stateless.

¿Cómo mantengo contexto entre llamadas si no hay sesión?

Con handles explícitos emitidos por el servidor. Una tool devuelve un identificador y el modelo lo pasa como argumento normal en las llamadas siguientes; el estado deja de estar escondido en la metadata del transporte y pasa a ser un dato visible que el modelo puede componer y encadenar.

Fuentes: blog oficial de Model Context Protocol — Release Candidate 2026-07-28, Exploring the Future of MCP Transports, Stacktree — MCP 2026-07-28 spec: what changed, what breaks y WorkOS — The biggest MCP spec update ships July 28.