MCP 2026-07-28: el protocolo pasa a ser sin estado

Por qué importa esta versión

La especificación 2026-07-28 de MCP es el mayor cambio del Model Context Protocol desde su publicación. MCP es el protocolo con el que una aplicación de IA, el cliente, se conecta a un servidor que le ofrece herramientas y datos. Desde esta versión, cada petición lleva consigo todo lo que el servidor necesita para procesarla, así que cualquier copia del servidor puede atender cualquier petición.

Hasta ahora, cada conexión empezaba con un saludo (initialize) en el que cliente y servidor acordaban versión y capacidades. El servidor recordaba ese acuerdo durante toda la sesión. Por eso había que fijar cada cliente a una instancia del servidor o compartir el estado de sesión entre todas.

Con el cambio puedes desplegar servidores MCP sin trucos detrás de un balanceador, que reparte las peticiones entre varias copias del servidor. También en plataformas serverless, que arrancan tu código bajo demanda, o en el edge, que lo ejecuta en servidores repartidos por el mundo.

Verás qué desaparece del protocolo, cómo es ahora una petición, qué hacer con un servidor existente y qué SDK, clientes y servidores soportan ya la versión. Para seguirlo te basta con saber qué es una API HTTP y leer JSON. Si MCP es nuevo para ti, empieza por qué es MCP o consulta el glosario.

Resumimos los cambios a partir del changelog oficial. El curso está reescrito entero sobre esta versión.

Lo actualizamos el 15 de octubre de 2026 con una sección nueva: el estado de la migración, es decir, qué SDK, clientes y servidores hablan ya esta versión, con la fuente de cada dato.

Lo que desaparece

Desaparecen el saludo inicial, las sesiones y los métodos que dependían de ellas. La tabla compara cada pieza de 2025-11-25 con lo que la sustituye. Un resource es un dato que el servidor ofrece para que el cliente lo lea. Una tool es una función que el modelo puede pedir que se ejecute.

Antes (2025-11-25)	Ahora (2026-07-28)
Handshake `initialize` / `notifications/initialized`	No existe. Versión y capacidades viajan en el `_meta` de cada petición
Sesiones y cabecera `Mcp-Session-Id`	No existen. El estado entre llamadas usa identificadores que emite el servidor y que el cliente pasa como argumento
`ping`	Eliminado
`logging/setLevel`	Eliminado. El nivel de log se pide por petición en `_meta`
`resources/subscribe` y el `GET` del transporte HTTP	Sustituidos por `subscriptions/listen`
Reanudar un stream cortado con `Last-Event-ID`	Eliminado. La petición se pierde y el cliente la reemite con un identificador nuevo
Peticiones iniciadas por el servidor (`elicitation/create`, `sampling/createMessage`, `roots/list`)	Sustituidas por el patrón de peticiones de varias rondas

Cómo es ahora una petición

Cada petición lleva en params._meta la versión del protocolo y las capacidades del cliente, y conviene que lleve también su identidad. Las peticiones son mensajes JSON-RPC, un formato sencillo de llamadas remotas en JSON. Este ejemplo ejecuta con tools/call la tool buscar_pedido de Nortia Logística, la empresa ficticia de nuestro curso:

{
  "jsonrpc": "2.0",
  "id": 41,
  "method": "tools/call",
  "params": {
    "name": "buscar_pedido",
    "arguments": { "pedido_id": "PED-2026-004812" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "nortia-agente-soporte", "version": "2.1.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

La petición pide buscar el pedido PED-2026-004812 y declara en _meta qué versión habla el cliente. Hay un detalle fácil de pasar por alto: varios ejemplos de la propia especificación omiten _meta “por brevedad”, pero en la red es obligatorio. El servidor rechaza una petición sin versión o sin capacidades.

Todo resultado lleva además un campo resultType. Vale "complete" para un resultado normal o "input_required" cuando el servidor necesita algo más.

`server/discover`

server/discover es el método con el que el cliente pregunta a un servidor qué ofrece. Sin handshake, el cliente necesita esa otra vía, así que los servidores deben implementarlo. Devuelve las versiones soportadas, las capacidades y la identidad del servidor. El cliente puede llamarlo antes de nada. También puede enviar su petición sin más y reaccionar si el servidor rechaza la versión.

Cuando el servidor necesita preguntar

Antes, el servidor podía iniciar una petición hacia el cliente para pedir, por ejemplo, que el usuario confirmara cancelar un pedido. Ya no puede iniciar peticiones, así que ahora funciona en tres pasos:

El servidor responde con un resultado input_required que describe lo que necesita.
El cliente recoge la respuesta del usuario.
El cliente vuelve a enviar la petición original con esas respuestas y con un requestState opaco, un valor que el servidor le entregó y que el cliente no interpreta, solo devuelve.

Esto tiene dos consecuencias prácticas:

El servidor debe tratar requestState como entrada no fiable. Lo emitió él, pero vuelve desde el cliente. Si influye en permisos o en lógica, tu servidor tiene que firmarlo.
La notificación notifications/elicitation/complete y el campo elicitationId desaparecen.

Tasks pasa a ser una extensión

Las tasks son operaciones largas que el servidor sigue ejecutando mientras el cliente consulta su estado. Eran experimentales en el núcleo y pasan a una extensión oficial, io.modelcontextprotocol/tasks. El cliente consulta el estado con tasks/get y envía datos con tasks/update. Los métodos tasks/result y tasks/list desaparecen.

Con ella llega un marco general de extensiones. Cliente y servidor declaran qué extensiones soportan, y todas están desactivadas por defecto.

Lo que queda deprecado

Cuatro features quedan deprecadas. Deprecado significa que sigue funcionando, pero no debes adoptarlo en implementaciones nuevas. Tienen una ventana mínima de doce meses antes de poder retirarse:

Roots, con las que el cliente dice al servidor qué directorios puede usar. Pasa los directorios o archivos como parámetros de tool, URIs de resources o configuración del servidor.
Sampling, con el que el servidor pide al cliente que use su modelo. Integra directamente con la API del proveedor del modelo.
Logging, los mensajes de registro que envía el servidor. Escribe en stderr (stdio, el modo en que el cliente arranca tu servidor como proceso local) o usa OpenTelemetry.
Registro dinámico de clientes OAuth, la forma de dar de alta un cliente en el estándar de autorización OAuth. Lo sustituyen los Client ID Metadata Documents.

El transporte HTTP+SSE, la forma antigua de enviar mensajes por HTTP, no entra en esa ventana. Está deprecado desde la versión 2025-03-26 y puede retirarse tres meses después de que SEP-2596 llegue a Final. Una SEP es una propuesta de mejora de la especificación. Si aún lo usas, migra a Streamable HTTP, el transporte actual por HTTP.

La especificación adopta además una política formal de ciclo de vida. Cada feature está activa, deprecada o retirada, y hay un registro público de lo deprecado.

Otros cambios que afectan al código

Seis cambios más tocan el código de tu cliente o de tu servidor.

Cabecera Mcp-Method obligatoria en las peticiones POST de Streamable HTTP, y Mcp-Name en las de tools/call, resources/read y prompts/get.
Los listados y lecturas (tools/list, resources/read…) devuelven ttlMs y cacheScope, que indican cuánto tiempo y dónde se puede cachear la respuesta.
tools/list debería devolver las tools en un orden determinista, para aprovechar la caché del cliente y del modelo.
El error de resource no encontrado pasa de -32002 a -32602.
En OAuth, el estándar con el que un servidor decide quién puede entrar, el cliente debe validar el parámetro iss antes de canjear el código de autorización.
inputSchema y outputSchema, que describen los argumentos y el resultado de una tool, admiten cualquier JSON Schema 2020-12, y structuredContent cualquier valor JSON.

Qué hacer con un servidor existente

Son cinco pasos, en este orden. Un SDK es la biblioteca oficial con la que programas tu servidor MCP.

Actualiza el SDK. Los SDK oficiales de TypeScript y Python tienen versión 2 estable. En TypeScript el paquete se ha dividido (@modelcontextprotocol/server, /client…) y server.tool() pasa a ser registerTool().
Cambia el punto de entrada. Actualizar el paquete no basta. En el SDK de TypeScript, conectar con StdioServerTransport, el transporte stdio, sigue negociando 2025-11-25. Para hablar 2026-07-28 tienes que servir con serveStdio() o createMcpHandler().
Saca el estado de la sesión. Lo que guardabas por sesión (un carrito, un cursor, el inquilino elegido) pasa a un identificador explícito que el servidor emite y el cliente devuelve como argumento.
Revisa lo que dependía de peticiones del servidor al cliente: elicitation, sampling y roots.
No abandones a los clientes antiguos todavía. Un mismo servidor puede atender las dos versiones desde el mismo endpoint (la misma URL), y no todos los clientes han publicado qué versión hablan. Lo ves cliente a cliente en la sección siguiente.

El curso desarrolla cada uno de estos pasos con código ejecutado. La lección 3 explica el protocolo sin estado, la 7 las peticiones de varias rondas, y las lecciones 9 y 10 construyen un servidor con los SDK nuevos. Si prefieres una guía paso a paso en el blog, la tienes en cómo migrar un servidor a 2026-07-28.

Estado de la migración a 15 de octubre de 2026

A 15 de octubre de 2026, los seis SDK oficiales del nivel principal (Tier 1) tienen ya una versión estable que habla MCP 2026-07-28, aunque en TypeScript hay que activarla. Entre los clientes, solo Claude Code y GitHub Copilot CLI documentan que la usan por defecto. En servidores populares la hemos confirmado en GitHub, Vercel, Context7 y el servidor de documentación de Cloudflare. En el resto de los que revisamos no hay confirmación o no la soportan.

Antes de las tablas, tres términos. Un SDK es la biblioteca oficial con la que programas un cliente o un servidor MCP en tu lenguaje. El cliente es la parte de una aplicación, como Claude Code o VS Code, que habla con un servidor MCP. El servidor es el programa que expone herramientas y datos. Lo explicamos con calma en la lección de arquitectura.

En las tablas, «soporta» significa que una release o la documentación oficial dice que el producto habla 2026-07-28. Una release es una versión publicada del paquete o del programa. «Por defecto» significa que la usa sin que cambies nada.

Escribimos «Sin confirmar» cuando no hemos encontrado una fuente primaria que lo diga. Todas las fechas son de 2026 y las de las releases son de publicación en UTC, según GitHub.

SDK oficiales

El proyecto MCP clasifica sus SDK en niveles (Tier 1, 2 y 3) según unos criterios publicados. Su página de SDK, consultada el 15 de octubre, pone seis en Tier 1. El anuncio oficial del 28 de julio hablaba de cuatro Tier 1 con la versión nueva ese día y de Rust en beta. Desde entonces Rust y Ruby se han sumado al Tier 1.

SDK (nivel)	¿Soporta 2026-07-28?	Desde qué versión	Fuente primaria (fecha)
TypeScript (Tier 1)	Sí, pero hay que activarlo	2.0.0, del 27 de julio	Guía del SDK (consultada el 15 de octubre) y releases
Python `mcp` (Tier 1)	Sí, por defecto	2.0.0, del 28 de julio	Release v2.0.0 (28 de julio)
C# (Tier 1)	Sí, por defecto	2.0.0, del 28 de julio	Release v2.0.0 (28 de julio)
Go (Tier 1)	Sí. En HTTP, solo con el servidor sin estado	1.7.0, del 28 de julio	Release v1.7.0 (28 de julio)
Rust `rmcp` (Tier 1)	Sí	3.0.0, del 28 de julio	Release rmcp-v3.0.0 (28 de julio)
Ruby (Tier 1)	Sí	1.1.0, del 1 de agosto	Release v1.1.0 (1 de agosto) y v1.2.0 (15 de agosto)
Java (Tier 2)	No en la 2.x. La 3.x está planeada	Ninguna todavía	ROADMAP.md (consultado el 15 de octubre) y release v2.0.0 (11 de junio)
Kotlin (Tier 3)	Sin confirmar	Ninguna release lo declara	Release 0.15.0 (28 de julio)
Swift (Tier 3)	No, según su README	Ninguna	Repositorio (consultado el 15 de octubre)
PHP (Tier 3)	Sí	0.8.0, del 25 de agosto	Release v0.8.0 (25 de agosto)

Figura 1. Estado de la migración a MCP 2026-07-28 el 15 de octubre de 2026, por componente. El estilo del recuadro indica el estado y el texto entre paréntesis, el matiz.

Cada fila tiene un matiz que cabe mal en una celda:

TypeScript. La guía oficial del SDK lo dice sin rodeos: «Nothing in v2 puts a 2026-07-28 byte on the wire by default». Para servir la versión nueva usas createMcpHandler(factory) en HTTP, que también atiende 2025 por defecto, o serveStdio. En un cliente, activas versionNegotiation: { mode: 'auto' }. Las tasks sobre 2026-07-28 llegaron en la 2.3.0, del 2 de octubre. El SDK v1 (@modelcontextprotocol/sdk) sigue publicándose, y su última versión es la 1.32.1, del 5 de octubre.
Python. El servidor atiende las dos revisiones sin configurar nada. El Client pregunta primero con server/discover y, si falla, abre con initialize. La rama 1.x queda en mantenimiento, solo con parches de seguridad. La documentación del SDK en español explica los modos del cliente.
C#. El transporte HTTP funciona sin estado por defecto (Stateless = true). La 2.2.0, del 13 de agosto, añade HttpServerSessionMode para servir 2025-11-25 y 2026-07-28 en el mismo endpoint, es decir, en la misma URL.
Go. Los clientes nuevos negocian 2026-07-28 por defecto. En HTTP, el servidor solo la acepta con StreamableHTTPOptions.Stateless = true. Si mantienes sesiones, los clientes bajan a 2025-11-25.
Rust. La 3.0.1, del 29 de julio, corrigió la negociación de versiones en initialize.
Ruby. La 1.2.0, del 15 de agosto, completa el nuevo ciclo de vida sin estado.
Java. Su v2.0.0 dice que sigue la especificación 2025-11-25. Su hoja de ruta planea una 3.x con 2026-07-28 y unos hitos «planned for September 2026». El 15 de octubre no había ninguna etiqueta 3.x publicada.
Kotlin. Hay referencias a 2026-07-28 en el código de la rama principal, así que hay trabajo en curso. Ninguna release lo declara todavía.
Swift. El README dice que cumple 2025-11-25 «(latest)». El último commit es del 29 de abril.

Fuera de la lista oficial está FastMCP, un paquete de Python independiente. Su versión 4.0.0, del 31 de agosto, negocia 2026-07-28 sobre el SDK oficial mcp 2.x.

Clientes

Los clientes son las aplicaciones que usas para hablar con servidores MCP. Aquí el estado es más irregular que en los SDK.

Cliente	¿Soporta 2026-07-28?	Desde qué versión	Fuente primaria (fecha)
Claude Code	Sí, por defecto, según el tipo de conexión	Por partes, de la 2.1.274 (17 de septiembre) a la 2.1.299 (14 de octubre)	Release v2.1.299 (14 de octubre) y documentación (consultada el 15 de octubre)
Claude (web, Desktop y móvil)	Anthropic lo afirma en general, sin versión por producto	Sin versión publicada	Blog de Claude (25 de septiembre) y anuncio (28 de julio)
ChatGPT	Parcial: lo exige para MCP Events	Sin fecha publicada	Documentación de MCP Events (consultada el 15 de octubre)
Codex (OpenAI)	No por defecto: está tras un flag experimental desactivado	Ninguna	Código de las funciones (consultado el 15 de octubre) e issue #33952 (18 de julio)
GitHub Copilot CLI	Sí	1.0.81, del 27 de agosto	Release v1.0.81 (27 de agosto)
VS Code (Copilot Chat)	Sin confirmar. Hay una petición abierta	Ninguna	Issue #329848 (9 de agosto, último comentario del 21 de septiembre)
Cursor	Sin confirmar	Ninguna	Documentación de MCP (consultada el 15 de octubre)
Gemini CLI	Sin confirmar	Ninguna	Registro de cambios (consultado el 15 de octubre)

Lo que hay detrás de cada fila:

Claude Code. El predeterminado llegó por partes:
- Primero, la 2.1.274 lo trajo a las conexiones HTTP directas con el runtime v2 en Bedrock, Vertex, Foundry y las instalaciones sin telemetría.
- Después, la 2.1.292, del 6 de octubre, a los servidores stdio, que son los que Claude Code arranca en tu máquina.
- Más tarde, la 2.1.295, del 8 de octubre, a los conectores de claude.ai.
- Por último, la 2.1.299 a las sesiones cloud y a Remote Control.
Las dos últimas llegan solo a instalaciones que no reciben flags, que son ajustes que Anthropic activa a distancia sin publicar otra versión. Si necesitas volver atrás, MCP_PROTOCOL_NEGOTIATION=legacy recupera el comportamiento anterior. El detalle está en “MCP 2.0” en producción.
Claude web, Desktop y móvil. El 28 de julio, Anthropic escribió «Support is rolling out across Claude products soon». El 25 de septiembre escribió «Claude supports the latest MCP spec, commonly referred to as MCP 2.0, which includes a stateless core». No hay notas de versión por producto, así que no podemos decir desde cuándo lo habla cada uno.
ChatGPT. Su documentación dice «MCP Events in ChatGPT requires MCP 2.0 (protocol version 2026-07-28)». Para los conectores normales no declara ninguna revisión.
Codex. En su código, la función mcp_2026_07_28 está marcada como en desarrollo y desactivada por defecto. El issue #33952 pide soporte para servidores stdio.
GitHub Copilot CLI. La nota de la 1.0.81 dice «Ship MCP 2026-07-28 support to CLI, SDK, IDE, and in-memory clients». Esa palabra «IDE» no es una release de VS Code. Hay dos fallos reportados por usuarios. En el #4888, del 17 de septiembre, la CLI envía initialize después de un server/discover correcto por stdio. En el #5079, la CLI enviaba ping, que ya no existe en 2026-07-28, y está resuelto desde la 1.0.93 estable.
VS Code. En el issue, VS Code 1.132.0 abre con initialize. Un servidor que solo habla la versión nueva responde 400 y VS Code cae al transporte antiguo HTTP+SSE, que también falla con un 405. Las notas de VS Code 1.140, del 30 de septiembre, no nombran ninguna revisión.
Cursor. Su documentación enumera las piezas que soporta (Tools, Prompts, Resources, Roots, Elicitation y Apps), pero no nombra ninguna revisión.
Gemini. Ninguna release ni documento de Gemini CLI menciona 2026-07-28 como soportada. Para la app Gemini y la API Gemini no hemos encontrado ninguna fuente primaria, así que también quedan sin confirmar.

Servidores populares

Aquí mezclamos dos tipos de prueba. Una son las notas de versión y los repositorios de cada servidor. La otra es una medición nuestra, que explicamos en la sección siguiente y que puedes repetir.

Servidor	¿Soporta 2026-07-28?	Desde qué versión	Fuente primaria (fecha)
GitHub MCP Server	Sí	1.7.0, del 23 de julio	Changelog de GitHub (23 de julio) y release v2.0.0 (6 de octubre)
Cloudflare (`docs.mcp.cloudflare.com`)	Sí, según nuestra medición	Sin versión pública	Medición propia (15 de octubre) y blog de Cloudflare (6 de agosto)
Context7 (Upstash)	Sí	4.0.0, del 7 de agosto	Releases (consultadas el 15 de octubre) y medición propia (15 de octubre)
Vercel MCP	Sí	31 de julio, según su changelog	Changelog de Vercel (31 de julio)
Supabase	Sin confirmar	Ninguna release lo declara	Releases (consultadas el 15 de octubre)
Sentry y Linear	Sin confirmar. Solo lo dice Cloudflare	Ninguna	Anuncio de MCP, con la cita de Cloudflare (28 de julio)
Stripe	Sin confirmar	Ninguna	Documentación de Stripe (consultada el 15 de octubre)
Notion y Atlassian	Sin confirmar	Ninguna	Documentación de Notion (consultada el 15 de octubre)
Playwright MCP y Chrome DevTools MCP	Sin confirmar	Ninguna	Releases de Chrome DevTools MCP (consultadas el 15 de octubre)
Microsoft Learn	Sin confirmar: los datos se contradicen	Ninguna	Medición propia (15 de octubre) e issue #5079 de Copilot CLI (9 de octubre)
Servidores de referencia (Everything, Filesystem, Memory, Fetch, Git…)	No	1.0.0, del 11 de octubre, sigue en el SDK v1	Release v1.0.0 (11 de octubre)
DeepWiki	No, según nuestra medición	Ninguna	Medición propia (15 de octubre)

Lo que matiza cada fila:

GitHub. La 1.7.0 subió el SDK de Go a una versión previa (1.7.0-pre.3). Según el anuncio, quitaron las sesiones guardadas en Redis, leen cabeceras HTTP en lugar de inspeccionar el cuerpo de cada petición y usan el SDK de Go. La 2.0.0, del 6 de octubre, añade esquemas de salida solo para los clientes que declaran 2026-07-28.
Cloudflare. Su blog describe el paso de McpAgent a createMcpHandler. Importante: la nota de release del repositorio cloudflare/mcp-server-cloudflare del 28 de julio habla de «default stateless 2025 compatibility». No la tomes como prueba de soporte de 2026-07-28.
Context7. La 4.0.0 migró al SDK v2 y a 2026-07-28, con HTTP sin estado para clientes nuevos y antiguos. La última versión el 15 de octubre era la 4.4.1, del 13 de octubre.
Vercel. Su changelog dice «Both protocol versions are served from the same endpoint».
Supabase. La 0.11.0, del 20 de agosto, migró sus paquetes al SDK v2 de TypeScript, que no habla 2026-07-28 si no lo activas. Su repositorio tiene pruebas con 2026-07-28, pero ninguna nota de release declara el soporte.
Sentry y Linear. El anuncio oficial recoge una cita de Cloudflare que los pone entre quienes lo adoptaron el primer día. Es una afirmación de Cloudflare. No la hemos encontrado ni en Sentry ni en Linear.
Stripe. Su documentación enlaza la especificación de autorización de 2026-07-28, que es solo la parte de OAuth. No dice que el servidor hable la revisión.
Chrome DevTools MCP. Su 1.10.0, del 23 de septiembre, dice «prepare for SDK v2». Ni ella ni las de Playwright MCP declaran la revisión.
Microsoft Learn. A nuestra sonda respondió que server/discover no está disponible. Pero un usuario de Copilot CLI escribió el 9 de octubre que su sesión con ese servidor corría en 2026-07-28. No sabemos cuál de las dos cosas describe el estado actual.
Servidores de referencia. Son los ejemplos que mantiene el propio proyecto MCP. Su 1.0.0 depende de @modelcontextprotocol/sdk ^1.31.0, que es el SDK v1.

Cómo comprobar tú un servidor con curl

Puedes repetir nuestra medición con un solo comando de curl, el programa de terminal que envía peticiones HTTP. Le pides al servidor su server/discover y miras si 2026-07-28 aparece en supportedVersions, la lista de versiones que dice atender.

Este es el comando literal de nuestra nota de investigación, con Context7 como destino:

curl -s -X POST https://mcp.context7.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Method: server/discover' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientInfo":{"name":"probe","version":"1"},"io.modelcontextprotocol/clientCapabilities":{}}}}'

El comando no lleva credenciales. Envía la cabecera Mcp-Method, obligatoria en HTTP desde 2026-07-28, y el _meta con la versión, la identidad y las capacidades del cliente. Para probar otro servidor, cambia la URL.

Lo lanzamos el 15 de octubre de 2026. Esta es la respuesta de docs.mcp.cloudflare.com/mcp, recortada en la nota:

{"result":{"supportedVersions":["2026-07-28"],"capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true}},"resultType":"complete","ttlMs":0,"cacheScope":"private",…},"jsonrpc":"2.0","id":1}

Context7 respondió HTTP 200 con supportedVersions: ["2026-07-28"]. DeepWiki respondió HTTP 400 con este mensaje:

Bad Request: Unsupported protocol version: 2026-07-28. Supported versions: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25

Microsoft Learn respondió -32601 Method 'server/discover' is not available.

Importante: un 401 sin credenciales no dice nada sobre la versión. El 401 significa «no autorizado». El servidor pide un token antes de leer la petición, así que nunca llega a contestar qué versiones atiende. Eso nos pasó con GitHub, Vercel, Stripe, Notion, Sentry, Linear, Supabase y Atlassian. En GitHub y Vercel el «Sí» de la tabla sale de sus notas oficiales, no de la sonda.

La medición tiene otro límite. Ve un instante y un endpoint. Un servidor que responde 2026-07-28 puede atender también 2025-11-25 en la misma URL.

Cómo leer la tabla y qué hacer hoy

Que un producto soporte 2026-07-28 no quiere decir que lo use por defecto en cada conexión. Lo que importa es la pareja: qué habla tu servidor y qué habla cada cliente que se conecta a él.

Pongamos un caso hipotético con Nortia Logística, la empresa ficticia de nuestro curso. Su servidor nortia-pedidos atiende ya 2026-07-28 y 2025-11-25 en el mismo endpoint. El equipo mira qué clientes usa su plantilla. Claude Code y Copilot CLI negociarán la versión nueva. VS Code y Codex, por lo que sabemos hoy, seguirán abriendo con initialize. Mientras alguno de ellos lo haga, Nortia no puede retirar el camino antiguo. Es un ejemplo basado en la matriz de compatibilidad de la especificación, no un resultado medido.

Lo mismo vale para ti. Según dónde esté tu caso en la tabla, esto es lo que te recomendamos hacer hoy:

Tu SDK lo trae de serie (Python, C#, Rust). Actualiza y atiende las dos versiones mientras haya clientes antiguos. En Python lo hace el servidor sin configurar nada. En C#, servir las dos en el mismo endpoint pide la 2.2.0. En Rust, usa al menos la 3.0.1, que corrigió la negociación con initialize.
Usas TypeScript. Actualizar a la v2 no basta. Sirve con createMcpHandler o serveStdio, como contamos en la guía de migración y en la lección de TypeScript.
Usas Go con HTTP. Activa StreamableHTTPOptions.Stateless = true en el servidor. Con sesiones, tus clientes seguirán en 2025-11-25.
Tu SDK aún no tiene release con 2026-07-28 (Java, Kotlin, Swift). Tu servidor sigue en 2025-11-25, la versión con la que abren los clientes que no usan la nueva por defecto. Vigila las releases de tu SDK. En Java, la 3.x está planeada, pero los hitos que su hoja de ruta situaba en septiembre no tenían release el 15 de octubre.
Tu cliente lo usa por defecto (Claude Code, Copilot CLI). Con un servidor que atiende las dos versiones, negociará la nueva. Si algo falla, en Claude Code tienes MCP_PROTOCOL_NEGOTIATION=legacy. En Copilot CLI, usa al menos la 1.0.93 por el fallo de ping.
Tu cliente no documenta que la use por defecto (VS Code, Cursor, Gemini CLI, Codex, Claude web y Desktop, ChatGPT fuera de MCP Events). No retires initialize de tu servidor. El caso de VS Code muestra lo que pasa si lo haces: el servidor responde 400 y la conexión falla.
Usas un servidor de terceros sin confirmar. No tienes que hacer nada. Un cliente que habla la versión nueva puede seguir usando el saludo antiguo con un servidor que no la admite.

Si lees esto bastante después del 15 de octubre, repite la comprobación. Mira las releases de tu SDK y lanza el curl contra tu servidor. Para comprobarlo desde tu propio servidor, registra el valor de io.modelcontextprotocol/protocolVersion que llega en cada petición. Así ves qué versión usa de verdad cada cliente.

Si quieres seguir lo que vino después, tienes tres artículos:

Qué anunció cada empresa y con qué extensiones: “MCP 2.0” en producción.
Hacia dónde quiere ir el protocolo: el nuevo roadmap de MCP.
Cuándo se propone publicar la siguiente versión: la próxima versión de MCP.