La próxima versión de MCP: marzo de 2027 y un calendario fijo

La próxima versión de MCP se propone para el 30 de marzo de 2027, no para diciembre de 2026 como estaba previsto. Lo plantea SEP-3398, un borrador abierto el 28 de septiembre de 2026. Si sale adelante, además fijaría dos versiones al año: el último martes de marzo y el último martes de septiembre.

Todavía no hay nada decidido. A 3 de octubre de 2026 no hay ninguna fecha oficial aprobada, la versión vigente sigue siendo 2026-07-28 y entre el 1 de agosto y el 3 de octubre no se publicó ninguna nueva.

Lo que sí hay es una propuesta formal con plazos concretos. Alrededor de ella han llegado también varios cambios en cómo se decide qué entra en la especificación. Si mantienes un servidor o un SDK, te conviene conocer las dos cosas.

Respuesta corta

• Fecha propuesta: 30 de marzo de 2027, según SEP-3398. La propuesta dice textualmente “moving the release previously targeted for December 2026 to March 30, 2027”.
• Estado: borrador. Puede cambiar o no aprobarse.
• Después: versiones cada seis meses, en marzo y septiembre, con congelaciones y betas de los SDK en fechas conocidas de antemano.
• Mientras tanto: 2026-07-28 es la especificación que tienes que implementar.

Qué propone SEP-3398

SEP-3398 (Release Cycle Updates) cambia el calendario de la especificación en tres puntos:

1. Dos fechas fijas al año. Las versiones saldrían el último martes de marzo y el último martes de septiembre. El 30 de marzo de 2027 es precisamente el último martes de ese mes.
2. Ciclos de ocho meses que se solapan. Si sale una versión cada seis meses y cada ciclo dura ocho, durante un tiempo conviven dos: el trabajo de la versión siguiente empieza antes de que se publique la actual.
3. Release managers rotatorios. La responsabilidad de llevar cada versión hasta la publicación no recae siempre en las mismas personas.

La propuesta nació en el Core Maintainer Day de AGNTCon + MCPCon Europe, que se celebró en Ámsterdam el 17 y el 18 de septiembre. Diez días después se abrió el PR.

En el día a día, lo que cambia es el modelo. Hoy te enteras de que habrá una versión nueva cuando se anuncia. Con este calendario sabrías con meses de antelación cuándo se cierra el contenido y cuándo puedes probarlo.

El calendario de congelaciones y betas

SEP-3398 fija tres hitos antes de cada publicación:

Si aplicas esos plazos a la fecha propuesta del 30 de marzo de 2027, el calendario queda así. Las fechas intermedias las hemos calculado nosotros a partir de esos plazos; la SEP no las publica.

flowchart LR
  A["28 sep 2026<br/>Se abre SEP-3398<br/>(borrador)"] --> B["Hacia mediados de enero 2027<br/>Congelación parcial<br/>(−2,5 meses)"]
  B --> C["Hacia mediados de febrero 2027<br/>Betas de los SDK Tier 1<br/>(−1,5 meses)"]
  C --> D["Hacia finales de febrero 2027<br/>Congelación total<br/>(−1 mes)"]
  D --> E["30 mar 2027<br/>Publicación propuesta"]

El hito que más te afecta es el de las betas. Mes y medio antes de la publicación tendrías SDK con la versión nueva en los lenguajes Tier 1. Con ellos puedes probar tu servidor contra lo que viene antes de que tus clientes lo pidan.

Un filtro nuevo: cada SEP se discute antes en un grupo de trabajo

Una SEP (Specification Enhancement Proposal) es el documento con el que se propone un cambio a la especificación. En septiembre, el proyecto pasó de recibir propuestas sueltas a exigir propuestas respaldadas por un grupo. Lo hizo en dos pasos.

Los cierres del 22 y el 23 de septiembre. En dos días, los mantenedores cerraron más de quince SEPs abiertas. Entre ellas:

• SEP-2998: resultados parciales en streaming
• SEP-3004: registros de auditoría a prueba de manipulación
• SEP-3140: declaraciones de capacidades firmadas
• SEP-2787: atestación de llamadas a herramientas.

Den Delimarsky lo explicó en los comentarios de cierre: “every new SEP should be developed with the help of a Working Group”.

Las ideas no quedaron rechazadas. Los mantenedores devolvieron las propuestas al circuito de los Working Groups (WG) para que vuelvan, si vuelven, con un grupo detrás.

La regla escrita del 28 de septiembre. El mismo día que se abrió SEP-3398 se fusionó el PR #3336, que convierte esa petición en obligación dentro de las guías de SEP. Antes de abrir una SEP, ahora tienes que discutir la idea en un WG o en un Interest Group (IG).

La regla encaja con el roadmap del 22 de agosto. Ese roadmap reparte el trabajo en cinco áreas con responsables y da revisión preferente a las SEPs que caen dentro de ellas. Lo contamos en detalle en el nuevo roadmap de MCP.

Con un calendario fijo, el filtro tiene sentido. Si hay fecha de congelación, a los mantenedores les conviene recibir propuestas ya trabajadas, no ideas sueltas a dos semanas del cierre.

Así que, si tienes una propuesta, busca el WG o el IG del área, discútela allí y abre la SEP después. Abrirla directamente en el repositorio de la especificación ya no es la vía.

SEP-3392: Experimental, Beta y Stable para las extensiones

Las extensiones son adiciones opcionales al protocolo que viven fuera del núcleo. Evolucionan a su ritmo y solo se activan si el cliente y el servidor las negocian. Las oficiales usan el prefijo io.modelcontextprotocol y viven en repositorios ext-*. Las experimentales viven en repositorios experimental-ext-* asociados a un WG o un IG.

SEP-3392 propone una forma común de indicar lo madura que está cada una.

SEP-3392 (Extension Lifecycle), abierta el 25 de septiembre, propone tres fases (Experimental, Beta y Stable) y una salida alternativa: la promoción al núcleo. Incluye una clasificación inicial:

Para ti, la fase sería una señal de riesgo explícita, porque construir sobre una extensión Stable no es lo mismo que hacerlo sobre una Beta. Skills, por ejemplo, llegó a Final como SEP el 13 de septiembre y aun así quedaría en Beta. Lo explicamos en Skills sobre MCP. SEP-3392 también es un borrador, así que la tabla puede cambiar.

SEP-3405: los tiers de SDK, por conformidad

El calendario de SEP-3398 da un papel concreto a los SDK Tier 1, porque son los que publican betas mes y medio antes. Por eso importa más saber qué SDK es Tier 1 y por qué.

SEP-3405 (Conformance-Driven SDK Tiers), abierta el 30 de septiembre y todavía en progreso, propone que el tier de un SDK lo decidan solo las pruebas de conformidad que pasa. Sustituiría a SEP-1730.

Va en la misma línea que el área de experiencia de los SDK del roadmap. Esa área quiere probar a generar un SDK Tier 1 candidato a partir de la especificación y la suite de conformidad.

Si eliges un SDK para un servidor que va a vivir años, el tier pasaría a ser un dato medible y no una etiqueta.

Qué hacer si mantienes un servidor o un SDK

Si mantienes un servidor:

• No esperes a marzo para nada. 2026-07-28 es la versión vigente y lo seguirá siendo hasta que salga otra. Si aún no has migrado, el calendario no cambia la urgencia.
• Comprueba la negociación de versión. En 2026-07-28 no hay handshake: cada petición declara su versión. Si recibe una que no implementa, tu servidor tiene que responder con el error -32022 (UnsupportedProtocolVersionError) y la lista de versiones que sí soporta, para que el cliente elija una común. Un servidor que hace esto bien no debería romperse el día que aparezca un cliente con la versión de 2027.
• Apunta las betas en el calendario. Si SEP-3398 se aprueba, hacia mediados de febrero de 2027 tendrás betas de los SDK Tier 1. Es el momento de levantar tu servidor con ellas en un entorno de pruebas.
• No cuentes con que marzo retire Roots, Sampling, Logging o el registro dinámico de clientes. Las cuatro quedaron deprecadas en 2026-07-28 y su retirada más temprana es la primera revisión publicada en o después del 28 de julio de 2027. Con el calendario propuesto, la de marzo de 2027 llegaría antes de esa fecha, así que la primera elegible sería la de septiembre de 2027. Que sea elegible no significa que las retire: según la política de ciclo de vida, lo deciden los Core Maintainers y puede ser después. Aun así, las implementaciones nuevas no deberían adoptarlas y las existentes deberían migrar ya.
• Mira la fase de cada extensión que uses. Si SEP-3392 sale adelante, revisa si dependes de algo en Beta.

Si mantienes un SDK:

• Sigue SEP-3405 de cerca. Si se aprueba, tu tier dependería de la suite de conformidad. Y el tier decide si te toca publicar beta mes y medio antes de cada versión.
• Planifica con dos ciclos a la vez. Con ciclos de ocho meses que se solapan, habrá semanas en las que estabilizas una versión mientras empieza a definirse la siguiente.

Si quieres proponer algo: entra en el WG o el IG del área. Desde el 28 de septiembre es requisito, no recomendación.

Lo que falta por saber

SEP-3398, SEP-3392 y SEP-3405 son borradores a 3 de octubre de 2026. Todavía no se sabe qué contenido llevará la versión de marzo ni si la fecha se mantendrá. El roadmap marca las prioridades con un horizonte de seis a doce meses, pero no da fechas de entrega por área.

Si quieres entender cómo funcionan hoy las versiones, las deprecaciones y la forma de seguir los cambios, la lección “Estado actual y evolución” del curso lo trata con la especificación 2026-07-28. La lección “Interacción con el usuario y extensiones” explica el marco de extensiones sobre el que se apoyaría SEP-3392. Para el resto del panorama, qué es “MCP 2.0” y quién lo soporta cuenta dónde está la versión vigente en producción.