"MCP 2.0" en producción: qué es y quién lo soporta

“MCP 2.0” es el nombre informal con el que parte del ecosistema llama a la especificación 2026-07-28 del Model Context Protocol (MCP), la que hizo el protocolo sin estado. MCP es el protocolo con el que un asistente de IA llama a herramientas y datos de otros programas. Sin estado significa que cada petición lleva todo lo que el servidor necesita, sin una sesión abierta de antemano.

No existe una versión oficial llamada MCP 2.0. El nombre oficial es la fecha, y desde el 28 de julio no ha salido ninguna versión nueva.

El apodo importa porque Anthropic y OpenAI ya lo usan en sus textos oficiales. Aquí separamos el nombre de la versión real y repasamos quién soporta de verdad 2026-07-28 y con qué extensiones, con la fecha y la fuente de cada anuncio.

El 14 de octubre de 2026 actualizamos la parte de Claude Code. Dos versiones de octubre cambiaron qué revisión del protocolo intenta usar por defecto, y cada una afecta a un tipo de conexión distinto.

Al terminar sabrás distinguir el protocolo de las versiones de cada cliente y qué comprobar en tu servidor. Solo necesitas saber qué es una API. Si aún no conoces MCP, empieza por qué es MCP y consulta el glosario de MCP cuando un término no te suene.

Qué es “MCP 2.0” (y qué no es)

Anthropic escribió el 25 de septiembre de 2026 que “Claude supports the latest MCP spec, commonly referred to as MCP 2.0, which includes a stateless core” (blog de Claude). OpenAI usa la misma etiqueta en su documentación de MCP Events: “MCP 2.0 (protocol version 2026-07-28)” (OpenAI). En los dos casos la etiqueta es sinónimo de 2026-07-28, y así hay que leerla.

Tres cosas que no es:

• No es un número de versión del protocolo. MCP identifica sus versiones por fecha, y la que viaja en cada petición es "2026-07-28". La especificación no define ninguna versión “2.0” que se pueda negociar.
• No es una versión posterior a 2026-07-28. La especificación vigente sigue siendo esa (blog oficial de MCP). La SEP-3398, una propuesta de cambio del protocolo, plantea trasladar la siguiente publicación al 30 de marzo de 2027. Falta confirmarlo en el calendario de transición. Su PR sigue abierto, aunque los mantenedores ya votaron a favor (PR #3398).
• No es la versión de un SDK. Un SDK es el paquete de código con el que programas un servidor o un cliente MCP. El “2.0” también aparece en cosas que no son el protocolo. Los SDK 2.0 de TypeScript y Python salieron a finales de julio. La librería de MCP Apps, ext-apps, publicó su v2.0.0 el 8 de septiembre sin cambiar el protocolo de Apps (release de ext-apps). Si alguien te dice “usamos 2.0”, pregunta a cuál de ellos se refiere.

Lo que cambió en 2026-07-28, en cinco líneas

El detalle está en el artículo MCP 2026-07-28: el protocolo pasa a ser sin estado. Este es el resumen, sacado del blog oficial. Las versiones anteriores abrían cada conexión con un saludo llamado handshake, y eso ha cambiado.

1. Núcleo sin estado. No hay handshake initialize ni sesiones. Cada petición lleva en _meta, un campo de metadatos, la versión del protocolo y las capacidades del cliente.
2. server/discover. Un método para preguntar al servidor qué versiones y capacidades tiene, con resultado cacheable.
3. Multi Round-Trip Requests. El servidor ya no inicia peticiones. Cuando necesita algo del usuario (lo que el glosario llama elicitation), responde con un resultado input_required, y el cliente reintenta la petición original con la respuesta.
4. Cabeceras Mcp-Method y Mcp-Name en Streamable HTTP, la forma de llevar MCP sobre peticiones HTTP normales. Repiten fuera del cuerpo JSON el método y el nombre de la herramienta, el recurso o el prompt.
5. Listas cacheables y CIMD. Los resultados de listas llevan pistas de caché, y CIMD (Client ID Metadata Documents) pasa a ser la vía preferida para registrar clientes OAuth. OAuth es el estándar con el que un usuario autoriza a una aplicación a actuar en su nombre, y con CIMD el cliente se identifica con un documento publicado en una URL suya.

En el curso, la lección Cómo viaja una petición recorre mensaje a mensaje lo que lleva cada petición y qué vuelve.

Quién lo soporta: tabla por plataforma

La tabla recoge lo que cada empresa ha anunciado con fuente primaria. La columna de la versión distingue entre quien dice expresamente que habla 2026-07-28 y quien anuncia productos MCP sin decir qué revisión. Un servidor stdio es un programa local que el cliente arranca y con el que intercambia mensajes por la entrada y salida estándar.

En la tabla, «GA» significa disponibilidad general y «Public Preview» indica una vista previa pública. Un webhook es una notificación que un servicio envía a una URL cuando ocurre un evento. «UI» es la interfaz de usuario. RFC 9207 es el documento que define cómo identificar al emisor en un flujo OAuth.

Hay tres matices que la tabla no cuenta por sí sola:

• AWS y Vercel anunciaron el soporte en julio, el mismo día de la especificación o tres días después. No son novedades de agosto a octubre, pero sí son soporte confirmado.
• Cloudflare cita clientes en producción. Según su artículo, Sentry y Linear ya usan 2026-07-28 (Cloudflare). Es una afirmación de Cloudflare, no de Sentry ni de Linear.
• Enterprise Managed Auth en Claude tiene una discrepancia. Anthropic anunció su disponibilidad general el 24 de agosto, con Datadog, Notion y Slack entre los nuevos conectores (claude.com). Sin embargo, la matriz de clientes de modelcontextprotocol.io, que mantiene la comunidad, no lo marca (matriz). Si dependes de esa extensión, prueba con el cliente concreto antes de fiarte de cualquiera de las dos fuentes.

Claude Code y la versión que negocia cada conexión

Empecemos por un caso inventado. Nortia Logística, la empresa ficticia de nuestro curso, tiene un servidor nortia-pedidos que atiende las dos versiones en el mismo endpoint, es decir, en la misma URL.

Si un cliente le manda peticiones con la versión 2026-07-28 en _meta, el servidor las atiende sin estado. Si otro cliente abre con initialize, el handshake de las versiones anteriores, el servidor sigue las reglas de 2025-11-25. Así lo describe la matriz de compatibilidad de la especificación.

Importante: este ejemplo es hipotético. No lo hemos medido con Claude Code ni hemos inspeccionado su tráfico. Lo que contamos de Claude Code sale de sus notas de versión y de su documentación.

flowchart LR
  CC["Una conexión de Claude Code"]
  M["Petición con _meta<br/>versión 2026-07-28"]
  I["Handshake initialize<br/>versión 2025-11-25"]
  subgraph S["nortia-pedidos: atiende las dos versiones"]
    SN["Atiende cada petición<br/>sin estado"]
    SL["Sigue las reglas<br/>de 2025-11-25"]
  end
  CC -.->|"runtime v2: pregunta y<br/>el servidor la admite"| M
  CC -.->|"runtime v1, legacy o<br/>flag que fija la anterior"| I
  M --> SN
  I --> SL

El diagrama resume las dos vías del ejemplo. Con ese caso en mente, estos son los tres cambios de Claude Code que tocan la versión 2026-07-28, cada uno con su fila en la tabla:

• 2.1.281, 23 de septiembre. Añadió la elicitation en modo URL en conexiones 2026-07-28. La elicitation es la forma que tiene un servidor de pedir un dato al usuario a mitad de una llamada.
• 2.1.292, 6 de octubre. Las conexiones a servidores locales por stdio pasaron a negociar 2026-07-28 por defecto en todas las instalaciones, incluidas Bedrock, Vertex y Foundry (release).
• 2.1.299, 14 de octubre. El mismo predeterminado llegó a los conectores MCP de las sesiones cloud y de Remote Control, pero solo en las instalaciones que no reciben flags. La nota literal dice “on installs that fetch no flags” (release).

Los flags de los que habla la nota son los feature flags que Claude Code descarga de Anthropic al arrancar. Son ajustes con los que Anthropic activa o desactiva funciones sin publicar otra versión. “Sin flags” describe una condición de esa instalación, no una instalación sin soporte de MCP. En las dos versiones, MCP_PROTOCOL_NEGOTIATION=legacy devuelve el comportamiento anterior. legacy es un valor de configuración de Claude Code y no el nombre de ninguna versión del protocolo.

Lo que distingue la documentación

La documentación de Claude Code, consultada el 14 de octubre, separa cuatro cosas que conviene no mezclar. El runtime es el motor MCP que Claude Code lleva dentro.

• El runtime. Claude Code elige al arrancar entre el runtime v1, construido sobre el SDK de TypeScript 1.x, y el v2, sobre el SDK 2.0, que añade la revisión 2026-07-28. En las sesiones que descargan flags usa v2 desde la versión 2.1.232. Sin flags lo usa por defecto desde la 2.1.274 en los casos que la página enumera.
• Los flags. Anthropic puede mantener un servidor concreto en el protocolo anterior con un flag que Claude Code descarga.
• Lo que admite el servidor. En v2, Claude Code pregunta a los servidores HTTP, stdio y conectores de claude.ai si admiten la revisión nueva. La usa con los que sí, y con los demás conecta como v1.
• La versión negociada. Es lo que de verdad pasa en cada conexión, y resulta de las tres anteriores. MCP_SDK_GENERATION=v1|v2 elige el runtime y MCP_PROTOCOL_NEGOTIATION=auto|legacy decide si Claude Code pregunta.

Por eso un predeterminado no te dice qué versión usó una conexión concreta, y esa sección de la documentación tampoco explica cómo verlo desde Claude Code. Desde tu servidor sí puedes mirar el valor de io.modelcontextprotocol/protocolVersion en cada petición, como contamos en la guía de migración a 2026-07-28.

La misma versión 2.1.299 trae otros arreglos de MCP. Corrige conexiones HTTP que se quedaban esperando 30 segundos cuando el servidor no cerraba la respuesta a una notificación. También envía las cabeceras configuradas en el inicio de sesión, el refresco y el cierre de OAuth de MCP. Ambas son correcciones de conectividad y no anuncian ninguna versión nueva del protocolo. Si buscas cómo dar de alta un servidor en Claude Code, lo explicamos en conectar un servidor MCP a Claude.

Las cifras de adopción y quién las da

Ninguna de estas cifras es una medición independiente. Cada una la publica alguien con interés en el resultado, así que hay que citarlas con su fuente y su fecha:

La Linux Foundation repitió el 14 de septiembre que las descargas mensuales de los SDK Tier 1, los SDK principales del proyecto, están “approaching 500 million” (nota de prensa). Esa cifra ya aparecía en el anuncio de 2026-07-28, así que es un dato repetido y no refleja crecimiento en el periodo.

Tampoco hay una cifra oficial del número de servidores en el MCP Registry, el directorio de servidores del proyecto, que sigue en preview (repositorio del Registry). Si ves una, comprueba de dónde sale.

Agent Plugins 1.0: un formato común de empaquetado

El 6 de agosto Vercel publicó Agent Plugins 1.0.0. Es un estándar abierto para empaquetar en un mismo plugin un plugin.json, una carpeta skills/ con instrucciones para el asistente (lo explicamos en qué son las Agent Skills) y un mcp.json con los servidores MCP (Vercel). Lo acordaron AWS, Anysphere, GitHub, Microsoft y OpenAI. Desde el lanzamiento lo soportan ChatGPT, Codex, Cursor, GitHub Copilot, Kiro y VS Code (Vercel). Microsoft lo confirma para VS Code en sus notas de VS Code 1.133.

Agent Plugins no es parte de MCP ni cambia el protocolo. Resuelve otro problema: cómo distribuir un servidor MCP junto con las skills que enseñan a usarlo, sin un formato distinto por cliente.

Anthropic no figura entre los firmantes. Claude distribuye plugins y conectores por su propio Marketplace y su portal de envío (claude.com), y ninguna de las fuentes de este artículo dice que acepte el formato de Agent Plugins. Si publicas también para Claude, cuenta con su canal propio.

Qué significa para tu servidor

No tienes que elegir entre versiones. La especificación permite que un mismo servidor atienda a la vez clientes 2026-07-28 y clientes con handshake (2025-11-25) en el mismo endpoint. El servidor decide según cómo abre el cliente cada conexión. El SDK de C# lo empaquetó el 13 de agosto con HttpServerSessionMode (release v2.2.0).

Es la forma razonable de migrar mientras haya clientes que no hablan la versión nueva. Claude Code lo ilustra, porque según el runtime, los flags y el ajuste legacy puede llegar por cualquiera de las dos vías. Un servidor que solo atiende 2026-07-28 no funciona con un cliente que abre con initialize (matriz de compatibilidad). Los pasos para atender a los dos están en la guía de migración.

Pide la versión, no el apodo. Cuando un cliente o una plataforma diga que soporta “MCP 2.0”, lo que puedes comprobar es el valor de io.modelcontextprotocol/protocolVersion en sus peticiones. Las fuentes de la tabla que dicen “2026-07-28” con todas las letras son las únicas que puedes dar por buenas.

Las extensiones pesan tanto como el núcleo. Anthropic destaca el núcleo sin estado, pero también MCP Apps y Enterprise Managed Auth. ChatGPT, para su flujo OAuth, pide CIMD y la identificación del emisor de RFC 9207. Si tu servidor apunta a esos clientes, esas piezas deciden si funciona. Para MCP Apps tienes el artículo MCP Apps.

Actualiza el SDK aunque ya hables 2026-07-28. Las versiones 2.2.0 y 2.3.0 de TypeScript y Python corrigieron avisos de seguridad coordinados y cambiaron comportamientos por defecto, como seguir redirecciones solo al mismo origen (TypeScript, Python). TypeScript publicó también la 2.3.1 después de la 2.3.0 del 2 de octubre. Una configuración laxa que funcionaba en 2.0 puede dejar de hacerlo.

Mira lo que viene. El roadmap del 22 de agosto fija cinco áreas de trabajo con un horizonte de seis a doce meses. Van desde eventos iniciados por el servidor hasta identidad de agentes. Lo explicamos en el nuevo roadmap de MCP.

En el curso, la lección Estado actual y evolución cubre la versión 2026-07-28, sus deprecaciones y cómo seguir los cambios. MCP sin programar repasa las plataformas que generan o alojan servidores sin escribirlos.