El nuevo roadmap de MCP: las cinco prioridades hasta 2027

El roadmap de MCP es el documento en el que los mantenedores del Model Context Protocol fijan qué áreas tienen prioridad para las próximas versiones de la especificación. El vigente se publicó el 22 de agosto de 2026 y tiene cinco áreas. No es normativo: marca hacia dónde se quiere ir, no lo que ya forma parte del protocolo.

Si mantienes un servidor, la lista de temas te sirve de poco. Te interesa saber qué propuesta concreta hay detrás de cada área, en qué estado está y qué parte de tu código toca. Este artículo recorre las cinco con el estado de cada SEP a 3 de octubre de 2026. La versión vigente de la especificación sigue siendo la 2026-07-28. Si aún no la conoces, empieza por el artículo sobre MCP 2026-07-28.

Qué es el roadmap y quién lo firma

El roadmap se anunció en el blog oficial de MCP, firmado por David Soria Parra y Den Delimarsky, y tiene su página fija en la documentación. Esa página indica “Last updated: 2026-08-22” y un horizonte de “six to twelve months”. Contado desde agosto, ese horizonte llega a 2027, pero el documento no pone fecha de entrega a ninguna área.

Cada área tiene responsables con nombre, y eso tiene un efecto práctico: las SEP que caen dentro de estas áreas tienen revisión preferente. Una SEP (Specification Enhancement Proposal) es el mecanismo formal para proponer un cambio en la especificación. Se trabaja como un pull request en el repositorio del protocolo.

El mismo anuncio cuenta tres avances de gobernanza que ya están hechos:

• una Contributor Ladder
• el triaje de SEP por parte de cada Working Group (WG)
• una política de ciclo de vida y deprecación de funcionalidades.

Después llegaron más cambios en el proceso. El 22 de septiembre se cerraron más de 15 SEP abiertas con la indicación de que “every new SEP should be developed with the help of a Working Group” (comentario de cierre en el PR #2998). El 28 de septiembre se fusionó el PR #3336, que obliga a discutir la idea en un WG o IG antes de abrir una SEP. El calendario de versiones y estos cambios de proceso tienen su propio artículo: la próxima versión de MCP.

flowchart LR
  R["Roadmap MCP<br/>22-ago-2026"]
  A1["1. Mensajería agéntica"]
  A2["2. Transporte sobre HTTP"]
  A3["3. Identidad y seguridad"]
  A4["4. Mejores primitivas"]
  A5["5. Experiencia de los SDK"]
  T["SEP-2663 Tasks<br/>extensión oficial"]
  SC["SEP-2127 Server Cards<br/>Final (6-oct)"]
  D["SEP-1932 DPoP<br/>borrador"]
  W["SEP-1933 WIF<br/>borrador"]
  F["SEP-2145 errores de tools/call<br/>en revisión"]
  X["SEP-3371 extensiones en SDK<br/>borrador"]
  C["SEP-3405 tiers por conformidad<br/>borrador"]
  R --> A1
  R --> A2
  R --> A3
  R --> A4
  R --> A5
  A1 --> T
  A2 --> SC
  A3 --> D
  A3 --> W
  A4 --> F
  A5 --> X
  A5 --> C

Ten en cuenta una cosa al leer la figura: el roadmap describe áreas, no listas cerradas de SEP. Las de Tasks, DPoP y Workload Identity Federation las nombra el propio roadmap. Las demás son propuestas abiertas que encajan con cada área por tema o por etiqueta.

Mensajería agéntica: eventos, Tasks y Triggers

Responsables: Caitie McCaffrey, Clare Liguori y Peter Alexander. El área incluye tres cosas:

• eventos iniciados por el servidor (canales, suscripciones y webhooks), a cargo del WG Triggers & Events
• una revisión de cómo encajan Tasks y Triggers entre sí
• madurar Tasks (SEP-2663) hasta incluirla en el núcleo.

Para situarte, en 2026-07-28 un servidor ya puede avisar al cliente, pero solo por un stream abierto con subscriptions/listen. Los webhooks permitirían avisar sin ese stream abierto.

Tasks permite la ejecución asíncrona con un identificador duradero que el cliente consulta después. Hoy es una extensión oficial, io.modelcontextprotocol/tasks, y no forma parte del núcleo. Madurarla significa sacarla de las extensiones y llevarla al núcleo.

Estado a 3 de octubre:

• Eventos. El design sketch de MCP Events se fusionó el 8 de septiembre en el repositorio del WG. Define tres modos de entrega: poll, push y webhook según Standard Webhooks. Es un experimento, no una SEP, pero ya tiene un implementador comercial. OpenAI documenta que “ChatGPT supports webhook delivery and callback verification from the draft MCP Events specification” (documentación de MCP Events). Lo cuenta con detalle el artículo sobre MCP Events y webhooks.
• Tasks. El repositorio ext-tasks publicó sus primeras releases en el periodo: v0.2.0 el 23 de septiembre y v0.2.1 y v0.2.2 el 30 de septiembre (releases). SEP-3392, en borrador, propone clasificar esta extensión como Beta. El 2 de octubre, además, el SDK de TypeScript publicó un aviso alto porque “Experimental tasks were not tied to the session that created them” (GHSA-22jm-h49p-29qw).

Transporte: HTTP como único binding

Responsables: Kurtis Van Gent y Nick Cooper. La propuesta se resume en “HTTP over stdio”: Streamable HTTP como único binding, HTTP/2 sobre stdio para los servidores locales y caché con ETags.

Hoy la especificación define dos transportes: stdio para procesos locales y Streamable HTTP para servidores remotos. Cada uno tiene sus propias reglas para cancelar una petición, demultiplexar las suscripciones o sondear la compatibilidad. Si esta área sale adelante, el servidor local dejaría de ser un caso aparte. Hablaría el mismo HTTP que el remoto, solo que sobre la entrada y la salida estándar del proceso.

Si mantienes un servidor solo en stdio, es el área con más impacto potencial para ti. A 3 de octubre no hemos encontrado ninguna SEP abierta que concrete este cambio de transporte. La que lleva la etiqueta roadmap/transport es SEP-2127, las Server Cards para descubrir un servidor HTTP sin conectarse a él. Se fusionó el 6 de octubre con estado Final, como extensión.

Identidad de agentes y seguridad empresarial

Responsables: Paul Carleton y Den Delimarsky. El área quiere cerrar cuatro piezas: DPoP (SEP-1932), Workload Identity Federation (SEP-1933), ID-JAG y el intercambio de tokens de RFC 8693. Quiere hacerlo en coordinación con los grupos OAuth y WIMSE del IETF. El Agent Identity WG se formó entre agosto y octubre de 2026.

DPoP liga un token a una clave del cliente, de modo que un token robado no sirve por sí solo. Workload Identity Federation permite que una carga de trabajo se autentique con la identidad que ya le da su plataforma, en lugar de usar un secreto estático. ID-JAG es el grant en el que se basa Enterprise-Managed Authorization.

El estado es desigual:

• SEP-1932 y SEP-1933 son borradores, con la etiqueta roadmap/security. No están aprobadas y no forman parte de la especificación.
• Enterprise-Managed Authorization ya es estable como extensión oficial. Además, pasó a disponibilidad general en los conectores MCP de Claude el 24 de agosto, con Okta como proveedor de identidad.
• En los SDK, las notas de la v2.2.0 del SDK de TypeScript mencionan una API DPoP (releases) sin más detalle. Nada en esas notas la relaciona con SEP-1932, así que no la tomes como implementación de la propuesta.

Mejores primitivas: resultado de tools/call y descubrimiento progresivo

Responsables: Van Gent, Alexander y Delimarsky. Tres frentes:

• rediseñar la forma del resultado de tools/call
• “progressive discovery”, para no cargar catálogos enteros en el contexto
• revisar las anotaciones de contenido.

El primero es el que más toca tu código. En 2026-07-28 el resultado de una tool lleva content, una lista de bloques obligatoria. Opcionalmente lleva también structuredContent, que puede ser cualquier valor JSON conforme al outputSchema. Así conviven dos formas de devolver lo mismo, y el roadmap quiere un contrato único.

El segundo frente busca, según el roadmap, no cargar catálogos enteros en el contexto del modelo. Lo notas en cuanto un cliente conecta varios servidores con muchas tools.

A 3 de octubre, la propuesta abierta más cercana es SEP-2145, “Standardize tools/call failure reporting”, en revisión (PRs con la etiqueta SEP). No hemos encontrado una SEP abierta que rediseñe el resultado completo ni que defina el descubrimiento progresivo.

Experiencia de los SDK

Responsables: Delimarsky y Soria Parra. Dos objetivos: definir el contrato de las extensiones en los SDK y probar a generar un SDK Tier 1 candidato a partir de la especificación y de la suite de conformidad.

Dos borradores recientes van en esa dirección. SEP-3371 (repositorio de la especificación, 18 de septiembre) propone puntos de extensión coherentes en los SDK: registro de extensiones, métodos propios y middleware. SEP-3405 (30 de septiembre) propone que el tier de un SDK lo decidan solo las pruebas de conformidad que pasa. Sustituye a SEP-1730 y está en progreso.

Hoy falta ese contrato, y se nota. El SDK oficial de TypeScript, por ejemplo, no implementa el lado servidor de la extensión Tasks: el paquete @modelcontextprotocol/ext-tasks es solo de cliente. Con un contrato común, cada extensión dejaría de depender de lo que cada SDK decida hacer por su cuenta.

Qué hacer hoy si mantienes un servidor

Nada de lo anterior te obliga a cambiar código hoy. El roadmap no es normativo y la especificación vigente es 2026-07-28. Lo que sí puedes hacer es prepararte para que el cambio, cuando llegue, sea pequeño.

1. Sigue las SEP de tus áreas, no el roadmap entero. Las etiquetas roadmap/security y roadmap/transport del repositorio del protocolo filtran bien. Si quieres influir, entra en el WG o IG correspondiente: desde el PR #3336, discutir allí la idea es el paso previo obligatorio para abrir una SEP.
2. Separa la lógica de tus tools de la forma del resultado. Si construyes content y structuredContent en una sola función a partir del mismo dato, un cambio de contrato en tools/call se queda en esa función.
3. No ates tu servidor local a detalles de stdio. Si tu código depende de cómo funciona el proceso (cancelación, demultiplexado, sondeo con server/discover), aíslalo detrás del transporte del SDK. Es lo que más se movería si el área de transporte prospera.
4. No implementes borradores de seguridad en producción. DPoP y Workload Identity Federation pueden cambiar antes de aprobarse. Lo estable hoy es la autorización de 2026-07-28 y Enterprise-Managed Authorization.
5. Si necesitas operaciones largas, usa Tasks sabiendo que es una extensión. Comprueba que el cliente la declara, revisa qué cubre tu SDK y actualiza. El aviso del 2 de octubre en TypeScript afecta a quien use las tareas experimentales de ese SDK.
6. Mira el calendario. SEP-3398, en borrador, propone que la próxima versión salga el 30 de marzo de 2027 en lugar de en diciembre de 2026. No está decidido. Si se aprueba, esa sería la siguiente versión de la especificación y la próxima ocasión para que algo de este roadmap pase a ser normativo.

Si quieres el contexto completo de la versión actual y de cómo seguir los cambios del protocolo, el curso lo trata en su lección de estado actual y evolución. Los niveles Avanzado y Experto cubren Tasks, suscripciones y gobierno de versiones en empresa: ver el temario. Para saber quién soporta ya 2026-07-28 y con qué extensiones, sigue con MCP 2.0 en producción.