El roadmap de MCP no es una versión ni una promesa de compatibilidad
MCP avanza a distintas velocidades en su especificación, extensiones, SDK y transportes. Una prioridad del roadmap no hace interoperables dos productos.
El roadmap del Model Context Protocol (MCP) nombra cinco áreas que sus mantenedores quieren impulsar, desde la mensajería entre agentes y los cambios de transporte hasta la identidad de cargas de trabajo y la coherencia de los SDK. No convierte esas capacidades en una sola versión.
La diferencia es operativa. La especificación 2026-07-28 de MCP ya está disponible, pero varios elementos del roadmap del 22 de agosto son diseños propuestos, extensiones que todavía están madurando o trabajos que aún no han entrado en el protocolo central. Incluso un comportamiento ya publicado puede requerir una configuración explícita del SDK, en lugar de llegar cuando cambia la versión de un paquete.
La regla segura para el despliegue es: aprueba una capacidad de MCP solo cuando coincidan el estado del protocolo, el comportamiento exacto del SDK, el cliente y servidor objetivo, el fallback, la evidencia de conformidad y la ruta de rollback. Pon el comportamiento publicado pero desigual detrás de un feature flag. Mantén la intención del roadmap fuera de las dependencias de producción.
Una función de MCP puede tener cuatro etiquetas de madurez distintas
El roadmap oficial dice que recoge el pensamiento actual de los mantenedores para los próximos seis a doce meses, no compromisos firmes. Las prioridades pueden moverse, los diseños pueden cambiar y el trabajo puede aplazarse. Sus cinco áreas son útiles porque revelan dónde se concentrarán la revisión de la especificación y el trabajo de los grupos de trabajo. No indican a un operador que un cliente y servidor determinados puedan interoperar hoy.
La versión de la especificación 2026-07-28 es un tipo distinto de artefacto. Sustituyó el handshake de sesión e inicialización a nivel de protocolo por solicitudes auto-descriptivas, introdujo server/discover, añadió cabeceras estándar de enrutamiento HTTP e indicaciones de caché, formalizó extensiones y reforzó la autorización. Esas son decisiones del protocolo que ya se han publicado.
Un SDK aún puede exponer un valor predeterminado más limitado. La guía de migración actual de TypeScript dice que un cliente usa el handshake heredado de 2025 salvo que se seleccione la negociación de versiones. mode: 'auto' sondea con server/discover y puede hacer fallback; fijar 2026-07-28 rechaza un servidor que no ofrezca esa revisión. Por tanto, instalar el SDK moderno no demuestra que una conexión desplegada use el comportamiento moderno de cable.
Las cuatro etiquetas deben mantenerse separadas:
| Etiqueta | Lo que establece | Lo que no establece |
|---|---|---|
| Prioridad del roadmap | Los mantenedores pretenden dedicar aquí esfuerzo de revisión y diseño | Un diseño final, una fecha de lanzamiento o una implementación interoperable |
| Estado de la especificación o extensión | El proyecto ha definido un contrato versionado en una etapa del ciclo de vida declarada | Soporte en el lenguaje, versión, host, gateway y peer que despliega un equipo |
| Soporte del SDK | Una línea de biblioteca expone alguna implementación del contrato | Su configuración predeterminada, el comportamiento de otro SDK o la compatibilidad de extremo a extremo |
| Evidencia del despliegue | Un par de cliente y servidor fijado superó los fixtures del equipo y la prueba de rollback | Compatibilidad después de cambios en cualquiera de los endpoints, extensiones, gateways o políticas |
Una insignia del paquete aplana esas etiquetas. El registro de despliegue debe conservarlas por separado.
Las funciones de MCP publicadas y planificadas están en etapas distintas
La siguiente matriz traduce el roadmap actual y la especificación publicada en decisiones predeterminadas conservadoras. «Publicar» no significa que sea universalmente seguro. Significa que el comportamiento subyacente está publicado y puede entrar en producción después de superar las barreras de implementación e interoperabilidad indicadas.
| Capacidad y evidencia actual | Lo que respalda la evidencia |
|---|---|
2026-07-28 core sin estado, solicitudes auto-descriptivas y server/discover. Publicado en la especificación central fechada; compatible con las líneas actuales de los SDK oficiales, con comportamiento de migración específico de cada lenguaje. | Publicar, para un par fijado. Registra las versiones del SDK del cliente y del servidor, habilita el modo de protocolo previsto, verifica el descubrimiento o los errores de versión directa, prueba las cabeceras de enrutamiento y conserva un fallback heredado o una política de rechazo deliberada. |
Negociación entre dos eras durante la migración. Implementada en el cliente TypeScript v2 mediante modos explícitos legacy, auto o de fijación moderna; los demás SDK necesitan sus propias evidencias. | Usar un feature flag. Prueba moderno con moderno, moderno con heredado, fallos de autorización, timeouts y rutas de rollback; registra la revisión negociada en lugar de inferirla de las versiones del paquete. |
| Extensión Tasks. Una extensión publicada; el roadmap dice que los mantenedores quieren madurarla para su eventual incorporación al core. | Usar un feature flag. Fija la versión de la extensión, verifica que ambos peers la declaren y la implementen, prueba la semántica de polling y cancelación, y rechaza su uso cuando falle la negociación de capacidades. |
| Enterprise-Managed Authorization. Una extensión estable citada por el proyecto, pero no una capa de identidad universal para todos los despliegues de MCP. | Usar un feature flag. Verifica el servidor de autorización, cliente, servidor, grant, audiencia del token, límites de delegación y comportamiento de revocación como una sola ruta probada. |
| Eventos iniciados por el servidor mediante webhooks o canales. Un entregable del roadmap destinado a reducir el polling; la composición final con Tasks y otros trabajos de eventos sigue en desarrollo. | Observar. Espera un contrato versionado y soporte en el SDK objetivo; después prueba la entrega, autenticación, replay, orden, cancelación, reintento y fallback. |
| Unificación del transporte HTTP sobre stdio. Una dirección del roadmap para transportar la semántica de Streamable HTTP sobre la E/S de procesos locales. | Observar. Exige una especificación o extensión aceptada, soporte publicado en ambos endpoints, pruebas de framing y apagado, y un fallback al transporte compatible actual. |
| Adopción de DPoP, identidad de cargas de trabajo y delegación de agentes. Trabajo del roadmap que se apoya en estándares de identidad existentes; la vía específica de MCP todavía no es una función turnkey publicada. | Observar. Exige contratos de MCP versionados junto con pruebas de emisor, audiencia, clave de prueba, intercambio de tokens, delegación, caducidad, revocación y funcionamiento entre tenants. |
| Resultados de herramientas rediseñados y descubrimiento progresivo. Trabajo del roadmap destinado a aclarar la fidelidad de los resultados y evitar cargar de entrada un catálogo grande de herramientas. | Observar. Espera un esquema estable y una implementación del SDK; prueba la fidelidad visible para el modelo, el comportamiento de la caché, la completitud del descubrimiento, el filtrado de autorización y un fallback al catálogo completo. |
| Artefactos de SDK generados y una automatización de conformidad más amplia. Un experimento del roadmap para probar qué capas de SDK y quickstart pueden generarse y volver a validarse. | Observar. Trata los resultados de conformidad publicados como evidencia solo para el conjunto de pruebas, revisión, commit del SDK y rol exactos que se probaron; no despliegues una salida generada únicamente porque proceda del experimento. |
La matriz es intencionadamente asimétrica. Una extensión publicada puede obtener un feature flag antes de pertenecer al core. Una función del roadmap no puede obtener el estado de «publicada» porque un proveedor exponga algo con un nombre parecido. El comportamiento específico de un producto puede ser útil, pero debe registrarse como la extensión de ese proveedor, no como soporte general de MCP.
El comportamiento publicado aún puede diferir en tiempo de ejecución
Una conexión concreta incluye un cliente, un servidor, dos implementaciones de SDK, un transporte, una ruta de autorización, una revisión del protocolo y cualquier extensión. «Compatible con MCP» comprime todos esos elementos móviles en una sola etiqueta.
La revisión negociada puede diferir de la sugerida por la versión de una dependencia. Los peers antiguos pueden activar un fallback o un rechazo deliberado, las reglas del gateway pueden alterar el comportamiento de cable y una extensión anunciada puede estar ausente o implementada solo parcialmente. La guía de migración independiente de Arcade espera un periodo de doble pila para los servicios públicos precisamente porque los clientes no se actualizan a la vez.
TypeScript hace especialmente visible la diferencia entre paquete y tiempo de ejecución. Su guía v2 documenta tres políticas de conexión: heredada por defecto, descubrimiento automático con fallback y fijación exclusiva de la versión moderna. Un equipo de plataforma podría elegir razonablemente la negociación automática para un servicio público y la fijación exclusiva moderna dentro de una flota controlada. Son decisiones de riesgo distintas aunque ambos despliegues usen la misma versión del SDK.
Cada capa cambiante puede invalidar la compatibilidad
La compatibilidad caduca cuando cambian materialmente el protocolo, la extensión, el SDK del cliente, el SDK del servidor, el producto host, el gateway, el perfil de autorización, el feature flag o el conjunto de pruebas de conformidad. También puede caducar cuando una propuesta del roadmap se convierte en una extensión publicada: es una razón para abrir una revisión nueva, no para promocionar automáticamente el antiguo elemento observado.
Pon fecha a cada fila y conserva la URL de la fuente junto a ella. El changelog de la especificación es la referencia base del comportamiento central publicado; el roadmap explica la dirección prevista; la documentación del SDK explica cómo una implementación expone el contrato. Cada uno responde a una pregunta diferente.
Por tanto, la lección de producción más valiosa del roadmap no es una función concreta. Es la advertencia de que MCP se mueve en varias capas a la vez. Los equipos que registran esas capas por separado pueden adoptar mejoras publicadas sin confundir el impulso del proyecto con la interoperabilidad.