Voy a ser directo: el titular de “97 millones” es el número fácil para arrancar, y lo voy a usar, pero no es la historia. La historia es el documento que está debajo.
El roadmap 2026 del Model Context Protocol fue publicado el 9 de marzo por David Soria Parra, el Lead Maintainer del proyecto. Se lee en seis minutos — y es la pieza de comunicación estratégica más honesta que vi de un proyecto de infraestructura de IA en mucho tiempo. Lo que el documento efectivamente dice es esto: MCP ya superó su fase de hobby, los deployments en producción están exponiendo un set predecible de problemas, y los maintainers están reestructurando el proyecto alrededor de esos problemas en vez de alrededor de fechas de release.
Eso es un tipo de roadmap distinto al que estamos acostumbrados a ver en el tooling de IA.
Primero el Número, Después la Realidad
La cifra de descargas de SDK — alrededor de 97 millones de descargas mensuales entre los SDKs de Python y TypeScript combinados — es real, y es significativa. Pone a MCP en la misma categoría de adopción que protocolos que hoy tratamos como infraestructura: OAuth, gRPC, HTTP en su madurez temprana. Más de 10.000 servidores activos. Soporte de cliente de primera clase en Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot y VS Code. En diciembre de 2025, Anthropic donó el protocolo a la Agentic AI Foundation bajo la Linux Foundation, eliminando la última duda de gobernanza vendor-lock.
Ese es el contexto. Ahora la parte interesante.
De Release Milestones a Priority Areas
Lo primero que cambió es cómo está organizado el roadmap. Las versiones anteriores estaban estructuradas alrededor de fechas de release — qué sale después, qué sale más adelante. Ese framing tenía sentido cuando el proyecto era más chico. Ya no funciona. Los Working Groups e Interest Groups son ahora el vehículo principal para el desarrollo del protocolo, y el nuevo documento está organizado alrededor de priority areas en vez de timelines.
Los maintainers son explícitos sobre el porqué: un roadmap orientado a releases implica un nivel de predictibilidad que el trabajo de estándares abiertos rara vez tiene. Traducción — se niegan a sobre-prometer. Eso no es una señal de debilidad. Es una señal de madurez.
Los Core Maintainers rankearon las áreas candidatas y llegaron a un top cuatro claro. Estas son las áreas donde las SEPs — Spec Enhancement Proposals — reciben revisión expedita y donde se concentra la mayor parte de la capacidad de los maintainers.
Prioridad Uno: Transport a Escala
Streamable HTTP es el transport que permite a los servidores MCP correr como servicios remotos en vez de procesos locales. Desbloqueó una ola de deployments en producción — y también es donde pegó el primer dolor real.
Los problemas específicos, planteados directamente en el roadmap: las sesiones con estado pelean contra los load balancers. El escalado horizontal requiere workarounds. No hay una manera estándar de que un registry o un crawler aprenda qué hace un servidor sin conectarse efectivamente a él.
La solución viene en dos partes. Primero, evolucionar el transport y el modelo de sesión para que los servidores puedan escalar horizontalmente sin tener que mantener estado — más mecanismos explícitos para manejar sesiones de forma clara. Segundo, un formato de metadata estándar servido vía URLs .well-known para que las capacidades del servidor sean descubribles sin una conexión viva.
Un no-movimiento deliberado: los maintainers no van a agregar más transports oficiales en este ciclo. Van a evolucionar el que ya tienen. Mantener chico el set de transports es una decisión de principios de diseño, no un descuido.
Prioridad Dos: Cerrar los Gaps del Lifecycle de Tasks
El primitive de Tasks — introducido en la SEP-1686 — salió como feature experimental y funciona para lo que fue diseñado. Pero el uso temprano en producción expuso una lista concreta de gaps de lifecycle: semántica de retry cuando una task falla de forma transitoria, y políticas de expiry sobre cuánto tiempo se retienen los resultados después de completarse.
Este es el tipo de iteración que solo podés hacer una vez que algo está deployado y testeado en el mundo real. Los maintainers dicen explícitamente que planean tomar el mismo enfoque con otras partes de MCP: shipear experimental, juntar feedback de producción, iterar. Eso es una disciplina conservadora de diseño de protocolos y vale la pena notarla.
Prioridad Tres: Arreglar el Cuello de Botella de SEPs
Esta es plomería interna pero tiene consecuencias reales para cualquiera que quiera contribuir a MCP. Hoy, cada SEP requiere una revisión completa del Core Maintainer sin importar el dominio. Eso es un cuello de botella. Frena a los Working Groups que ya tienen la expertise para evaluar propuestas en su propia área.
La solución propuesta: una contributor ladder documentada con un camino claro de participante de la comunidad a maintainer, y un modelo de delegación que permita a Working Groups de confianza aceptar SEPs en su dominio sin esperar una revisión completa del core. Los Core Maintainers retienen la supervisión estratégica. Los Working Groups ganan espacio para moverse.
Si estás siguiendo a MCP como una dependencia estratégica — y con 97M de descargas mensuales, probablemente deberías — la velocidad a la cual el protocolo puede absorber nuevas propuestas está directamente ligada a qué tan rápido puede responder al dolor de producción. Esta prioridad es realmente sobre escalar la capacidad operativa del propio proyecto.
Prioridad Cuatro: Enterprise Readiness — Acá Se Pone Interesante
Esta es la prioridad que más le importa a cualquiera que esté evaluando MCP desde un rol de CIO o platform engineering. El roadmap lo plantea sin suavizarlo: las empresas están deployando MCP y chocándose con un set predecible de problemas: audit trails, auth integrada con SSO, comportamiento de gateway y portabilidad de configuración.
Ese es el primer reconocimiento formal del proyecto de que los deployments de MCP en producción están chocando con fricción organizacional real — no solo con gaps técnicos.
Dos cosas resaltan en cómo está framing esta prioridad:
Primero, es la menos definida de las cuatro. Eso es intencional. Los maintainers quieren que las personas que están experimentando estos problemas ayuden a definir el trabajo. Un Enterprise Working Group dedicado todavía no existe. Si estás en infraestructura enterprise y esto le importa a tu roadmap, la invitación a participar es explícita.
Segundo — y este es el detalle que le subrayaría a cualquier CIO o arquitecto leyendo esto — los maintainers esperan que la mayor parte del trabajo de enterprise readiness aterrice como extensiones en vez de cambios al core spec. Su razonamiento: las necesidades enterprise son reales, pero no deberían hacer el protocolo base más pesado para todos los demás.
Esa es una decisión de gobernanza que vale la pena entender. Significa que el core spec de MCP va a mantenerse liviano. Audit trails, flujos de SSO, patrones de gateway, configuración portable — todo eso va a capar por encima como extensiones opcionales, no como requerimientos de baseline. Para los equipos evaluando MCP, significa que vas a tener que pensar en la capa de extensiones como parte de tu decisión de adopción, no como un nice-to-have.
Qué Significa Esto para Equipos en LATAM
Si estás en una empresa evaluando si exponer herramientas internas, bases de datos o APIs a agentes de IA vía MCP, el roadmap 2026 te dice tres cosas:
Uno — el riesgo de adopción ya es bajo. Gobernanza de Linux Foundation, 97M de descargas mensuales, cada provider grande de IA shipeando soporte. El protocolo no se va a ningún lado.
Dos — auth enterprise-grade y auditoría están en progreso. OAuth 2.1 ya está en el spec. Los flujos integrados con SSO, audit trails completos, comportamiento de gateway — esos son items del roadmap, aterrizando como extensiones. Si tu equipo de compliance o seguridad necesita esas respuestas por escrito hoy, vas a estar armándolas desde propuestas de extensión en vez de apuntar a un spec terminado.
Tres — la ventana en la que podés evaluar MCP antes de que tu CISO tenga opiniones fuertes al respecto se está cerrando. Una vez que la auth integrada con SSO aterrice y el Enterprise WG produzca guía oficial, MCP va a pasar por procurement enterprise como cualquier otro protocolo de infraestructura. Eso no es malo — es exactamente lo que debería pasarle a la infraestructura crítica. Pero los equipos que empiezan la conversación interna ahora van a ser los que moldean cómo su organización lo adopta, en vez de reaccionar a eso.
Mi lectura personal: la línea más importante de todo el roadmap no es ninguna de las cuatro prioridades. Es el framing del principio — “un roadmap orientado a releases implica un nivel de predictibilidad que el trabajo de estándares abiertos rara vez tiene.” Ese es el proyecto MCP diciéndote cómo pensarlo. Es infraestructura ahora. Tratalo como tal.
¿Estás evaluando MCP para tu organización, o ya lo tenés en producción? ¿Qué priorización harías de estos cuatro ejes? Contanos en los comentarios. 
Fuentes: MCP Blog (The 2026 MCP Roadmap) · WorkOS (Everything your team needs to know about MCP in 2026)