La nueva hoja de ruta de MCP: qué significa para quienes construyen sobre él

El 22 de agosto los mantenedores de Model Context Protocol publicaron una hoja de ruta actualizada que cubre los próximos seis a doce meses de trabajo del protocolo. Nombra cinco áreas prioritarias, los Core Maintainers responsables de cada una y una regla silenciosa pero importante sobre qué propuestas se revisan primero. La hoja de ruta anterior, de marzo, prometió cuatro cosas y entregó la mayoría en la release de especificación de julio, así que esta se ha ganado el derecho a ser tomada en serio. Mi lectura: MCP está convirtiéndose deliberadamente en infraestructura web normal, y la pregunta útil para quien construye es qué parte de tu stack cambia primero.

Conclusiones clave - La hoja de ruta fija cinco prioridades: agentic messaging, un único transporte HTTP-native, agent identity y enterprise security, primitives de tools más limpias y SDKs generados desde la especificación. - Las Spec Enhancement Proposals, SEPs, dentro de estas áreas reciben revisión acelerada. Fuera de ellas, espera una cola más larga y una barra más alta. - Las promesas de la hoja de ruta de marzo aterrizaron en gran medida en la spec 2026-07-28: un core stateless, resultados de listas cacheables y Multi Round-Trip Requests. - Los dos cambios con más probabilidad de tocar tu código son agent identity, DPoP y Workload Identity Federation, y progressive tool discovery para catálogos grandes. - Trata la hoja de ruta como dirección, no como compromiso. Los mantenedores lo dicen ellos mismos. No pauses tu build por ella.

¿Qué anunciaron realmente los mantenedores de MCP?

Primero los hechos. La hoja de ruta MCP actualizada, fechada el 22 de agosto de 2026, organiza el siguiente ciclo de especificación alrededor de cinco áreas prioritarias, cada una con Core Maintainers identificados y uno o más Working Groups detrás:

1. Agentic messaging primitives: eventos iniciados por el servidor, channels, subscriptions y webhooks, para que los clientes dejen de hacer polling, más una revisión de composición para que Tasks, triggers y progress notifications compartan un mismo lifecycle.

2. HTTP-native transport unification and hardening: Streamable HTTP como único binding, eventualmente hablado sobre stdio para servidores locales, y caching ampliado con ETags.

3. Agent identity and enterprise-ready security: finalizar DPoP, Demonstrating Proof of Possession, y definir un camino opinionated para agent identity y delegation construido sobre estándares IETF existentes.

4. Improved primitives: rediseño de la forma de resultado de tools/call y un nuevo esfuerzo de progressive discovery para que los clientes conozcan el catálogo de un servidor según lo necesiten.

5. Improved SDK developer experience: un extension contract y un experimento para generar un SDK Tier 1 y sus quickstarts directamente desde la especificación.

Junto a las cinco áreas hay una regla que dará forma a todo lo demás: las SEPs dentro de las áreas prioritarias obtienen revisión acelerada, y las propuestas con un Working Group detrás avanzan más rápido. En palabras de los propios mantenedores: "maintainer review time is scarce. We spend it here first." La hoja de ruta también deja claro que refleja el pensamiento actual y no compromisos firmes, por lo que algunos elementos pueden retrasarse o llegar con otra forma.

La hoja de ruta MCP publicada el 22 de agosto de 2026 establece cinco áreas prioritarias para los próximos seis a doce meses: agentic messaging, transporte HTTP-native, agent identity, primitives de tools mejoradas y SDKs generados desde la spec. Las propuestas dentro de estas áreas reciben revisión acelerada; fuera de ellas esperan una cola más larga.

¿Por qué importa esta hoja de ruta?

Importa porque la anterior cumplió. Las roadmaps de proyectos open source jóvenes suelen ser documentos aspiracionales que envejecen en silencio. Esta tiene track record. La roadmap de marzo de 2026 fijó cuatro prioridades y la mayor parte salió cinco meses después en la release de especificación 2026-07-28:

La adopción da peso a la roadmap. Para julio de 2026 los SDK Tier 1 del protocolo veían cerca de medio billón de descargas al mes, con los SDK TypeScript y Python superando cada uno los mil millones de descargas totales. Cuando un protocolo de esa escala te dice hacia dónde va, merece la pena leer el mapa.

Fuente: hoja de ruta MCP de marzo y agosto de 2026 y anuncio de la especificación 2026-07-28.

La hoja de ruta MCP de marzo de 2026 prometió evolución de transporte, comunicación entre agentes, madurez de governance y enterprise readiness. Cinco meses después, la especificación 2026-07-28 entregó un core de protocolo stateless, la extension Tasks, Multi Round-Trip Requests y una policy formal de deprecation con un mínimo de doce meses.

¿Qué significa si construyes sobre MCP?

Para quienes construyen, el impacto inmediato es desigual. Dos de las cinco áreas cambiarán tu código dentro de un año. Las otras tres cambian más cómo el protocolo se gobierna y mantiene alrededor de ti. Aquí va cada área traducida.

Agentic messaging: el fin del polling

El trabajo real de agentes no encaja en request y response. Los jobs duran minutos, los servidores terminan mientras el cliente no mira y hoy la única respuesta del cliente suele ser hacer polling, caro y feo. La roadmap prioriza eventos iniciados por el servidor: channels, subscriptions y webhooks, para que el servidor pueda decirle al cliente cuándo terminó el trabajo. La revisión de composición importa igual. Tasks, subscriptions/listen y progress notifications corren el riesgo de convertirse en tres respuestas distintas a "el servidor todavía no terminó", y los mantenedores quieren que compartan lifecycle, modelo de cancelación y error surface. Si construyes herramientas de larga duración, esta es el área que debes seguir en Discord.

Un transporte, hablado en todas partes

La release 2026-07-28 convirtió un servidor MCP remoto en un workload HTTP normal. La roadmap ahora quiere borrar la división entre remote y local: Streamable HTTP como único binding, hablado sobre stdin y stdout para servidores locales, con HTTP/2 proporcionando multiplexing mientras el subprocess mantiene sus garantías de seguridad y lifecycle. Hoy cada feature HTTP-native necesita un segundo diseño específico para stdio o no funciona en local, y los SDK mantienen dos transport pipelines. Un modelo de transporte significa menos de eso. El caching también se amplía: ETags encima de los hints ttlMs y cacheScope que llegaron en julio, para que los resultados de tool calls puedan versionarse en vez de volver a obtenerse.

Agent identity: el que morderá antes

La autorización MCP supone una persona con browser en el momento del consentimiento. Cada vez más el caller es un agent: un cloud workload con identidad propia, actuando por un user ausente, o creando sub-agents que deberían recibir menos authority que su parent. Honeycomb, citado en el anuncio de la release de julio, ya atribuye casi el 20% de sus queries interactivas mensuales a agents. Mientras tanto, muchos servidores MCP de producción siguen dependiendo de API keys pegadas y refresh tokens de larga duración, exactamente la práctica que este trabajo pretende retirar. El plan es finalizar y adoptar DPoP, más un camino estándar de delegation mediante Workload Identity Federation, SEP-1933, el grant ID-JAG detrás de Enterprise-Managed Authorization y token exchange RFC 8693, coordinado con los Working Groups OAuth y WIMSE del IETF.

El modelo de autorización de MCP fue creado para una persona aprobando access en un browser, pero los agents se están convirtiendo en callers. La roadmap prioriza DPoP y un camino estándar de delegation construido sobre Workload Identity Federation y RFC 8693 token exchange, para que los servidores reconozcan identidades de agentes sin API keys pegadas ni tokens de larga duración.

Resultados de tools y progressive discovery

Aquí se corrigen dos confusiones. La primera es que tools/call devuelve content y structuredContent a la vez, generando implementaciones divergentes porque el autor del servidor no sabe qué forma mostrará el cliente al model. Ese contrato se rediseña. La segunda es escala: conéctate a un servidor con cien tools y el model paga por toda la surface antes de que el user haga una sola pregunta, y la selección empeora al crecer la lista. La factura de tokens no es teórica. En el test de Cloudflare de febrero de 2026, exponer una API de 2.500 endpoints como definiciones de tools MCP consumió aproximadamente 1,17 millones de tokens, frente a unos 1.000 mediante code-calling. Progressive discovery es la respuesta propuesta: un entry point pequeño que revela más catálogo a medida que la conversación se estrecha, ligado al trabajo de caching anterior. Ya he escrito sobre cuándo ese overhead hace que una API normal sea mejor opción; progressive discovery es el intento de MCP de reducir la diferencia.

SDKs generados desde la spec

El elemento más silencioso puede ser el más revelador. Hoy los SDK, reference servers y quickstarts se mantienen a mano. La roadmap ejecuta un experimento: generar un candidato SDK Tier 1 y sus quickstarts directamente desde la especificación, validar ambos contra una conformance test suite y publicar los resultados, incluyendo qué layers deberían ser codegen determinista y cuáles model-assisted. Si funciona, los bugs de claridad de la spec salen a la luz como generation failures, y los SDK dejan de desviarse del documento que se supone que implementan.

¿Qué deberías hacer ahora?

Cuatro cosas, por orden de urgencia:

1. Esta semana: deja de construir trabajo nuevo sobre surfaces deprecated. Roots, Sampling, Logging y el transporte legacy HTTP+SSE fueron deprecated en la spec 2026-07-28 con una ventana mínima de doce meses. Siguen funcionando. Las nuevas implementaciones no deberían adoptarlos.

2. Este mes: haz tu servidor cache-friendly. Los list results ya incluyen ttlMs y cacheScope, y vienen ETags. Un servidor que emite hints de cache razonables hoy va una migración por delante.

3. Este trimestre: audita cómo autentican tus agents. Si algún servidor MCP que ejecutas confía en una API key pegada o refresh token de larga duración para un caller unattended, ese es exactamente el patrón que el Agent Identity Working Group existe para sustituir. Sigue al grupo en vez de inventar tu propio esquema de delegation. El ángulo de governance conecta con lo que cubrí en gobernanza de AI agents.

4. Si quieres dar forma al protocolo: escribe tu SEP dentro de un área prioritaria. Llévala primero al Working Group relevante y consigue su apoyo. Las propuestas alineadas con la roadmap tienen revisión acelerada; las de fuera hacen cola.

Dos cosas que no hacer. No pauses un build esperando la siguiente spec: la actual es la base estable, y la policy de deprecation ya garantiza aviso de doce meses sobre cualquier cosa que desaparezca. Y no trates la roadmap como una promesa. Su primera sección dice que las prioridades pueden cambiar y que trabajo no listado todavía puede salir. Si estás antes en el camino, mi walkthrough práctico para un primer servidor MCP y la lista de servidores que merece la pena conectar son los puntos de partida prácticos.

La especificación MCP 2026-07-28 deprecated Roots, Sampling, Logging y el transporte legacy HTTP+SSE con una ventana mínima de doce meses. El anuncio de la release confirma que siguen funcionando durante ese periodo, pero las nuevas implementaciones no deberían adoptarlos.

La visión más amplia

Aléjate un paso y aparece el patrón de un protocolo madurando en público. MCP fue donado a la Agentic AI Foundation neutral respecto a vendors bajo la Linux Foundation en diciembre de 2025, con OpenAI y Block como cofundadores. Desde entonces ha ganado contributor ladder, feature lifecycle, deprecation policy y ahora una declaración pública de dónde va el tiempo de los mantenedores. El extensions framework hace trabajo silencioso pero real: SEP-2133 permite a cualquier Working Group experimentar en un repository experimental-ext- antes de una propuesta formal, por lo que las ideas se prueban sin desestabilizar el core.

Lo que vigilaría los próximos dos trimestres es si llega HTTP over stdio. Si servidores locales y remotos convergen de verdad en un transporte, "MCP server" deja de ser una clase especial de software y se convierte en un web service con una cara estándar. Ese es el punto en que el protocolo desaparece en la fontanería, que es lo que se supone que hace la buena infraestructura.

Preguntas frecuentes

¿MCP es suficientemente estable para construir sobre él ahora?

Sí, con disciplina de migración. La spec 2026-07-28 introdujo una deprecation policy formal con una ventana mínima de doce meses, y los SDK salen con migration notes para breaking changes. El protocolo seguirá moviéndose, pero ahora te avisa con un año de antelación cuando algo de lo que dependes va a desaparecer.

¿Qué pasó con las sesiones MCP?

Se retiraron en la especificación 2026-07-28. El handshake initialize y el header Mcp-Session-Id desaparecieron, SEP-2575 y SEP-2567. Cada request ahora es self-describing, llevando su protocol version y client capabilities en _meta, y un call opcional server/discover sustituye el handshake para clientes que quieren capabilities upfront. Cualquier request puede caer en cualquier instance detrás de un load balancer round-robin.

¿Debería esperar a la próxima spec antes de construir?

No. La roadmap describe dirección para los próximos seis a doce meses, no features comprometidas, y los mantenedores lo dicen explícitamente. La spec actual es estable, cacheable y stateless. Construye sobre ella, evita surfaces deprecated y sigue los dos Working Groups cuyo output más te afectará.