El estándar ya ganó. Ahora viene lo difícil
En abril escribimos que MCP era el USB de la IA empresarial: el estándar que separa el "qué puede hacer el agente" del "quién es el agente". Tres meses después esa batalla está decidida. MCP ganó la adopción: los clientes lo soportan, los proveedores publican servidores oficiales y la pregunta en las empresas ya no es "¿MCP o integración custom?" sino "¿cuándo?".
El roadmap oficial de 2026 — publicado en marzo por David Soria Parra, lead maintainer del protocolo — va de la fase siguiente: convertir un estándar que funciona en demos y despliegues pequeños en un protocolo que aguante la empresa. Cuatro frentes: transporte escalable, descubrimiento de servidores, semántica de tareas y enterprise readiness.
Leído con ojos de arquitectura, el roadmap dice dos cosas a la vez: dónde va el protocolo, y — igual de importante — qué huecos reconoce tener hoy. Los dos importan si estás decidiendo cuánto invertir en MCP este año.
Sesiones sin estado: MCP contra el load balancer
El problema más citado del transporte HTTP de MCP es de manual: las sesiones con estado pelean con los load balancers. Si tu servidor MCP mantiene estado de sesión, escalarlo horizontalmente exige sticky sessions, capas de sesión compartida o workarounds que ningún equipo de plataforma quiere mantener. Es el mismo problema que el backend web resolvió hace quince años, reapareciendo en la capa de agentes.
El roadmap lo ataca de frente: un modelo de sesión sin estado para que un servidor MCP escale como cualquier API HTTP. Sin transportes nuevos este ciclo — decisión explícita — sino haciendo bien el que existe.
La lectura práctica: si estás construyendo un servidor MCP hoy, diseña los handlers sin estado desde el principio. No es solo alinearse con el roadmap; es que todo lo que el protocolo va a añadir asume esa disciplina. El estado de negocio vive en tus sistemas; la sesión MCP es transporte, no memoria.
Descubrimiento sin conexión: el .well-known que faltaba
Hoy, para saber qué expone un servidor MCP hay que conectarse y pedir la lista de tools. Parece un detalle. En producción es un problema con coste medible.
Un dato de nuestra propia operación: el servidor MCP oficial de Plane — el gestor de proyectos — expone 139 tools, unos 453 KB de definiciones. Del orden de 113.000 tokens de catálogo antes de la primera llamada. En nuestro caso eso significó que un cliente con un presupuesto de contexto finito descartase el servidor entero al conectar: no cabía. Sin aviso y sin degradación parcial. El servidor aparecía como "conectado" y ninguna de sus tools existía para el agente. Lo diagnosticamos midiendo el handshake a mano; ninguna de las dos partes te lo cuenta.
Los clientes ya lo están tapando por su cuenta. Claude Code hoy carga solo los nombres de las tools y difiere los esquemas hasta que el agente pide una en concreto, así que el mismo servidor que antes desaparecía ahora funciona. El catálogo no ha adelgazado — lo hemos vuelto a medir: 452.817 bytes, las mismas 139 tools. Lo que ha cambiado es quién paga el contexto y cuándo.
Que cada cliente tenga que inventarse su propia estrategia para eso es la definición de un hueco del protocolo.
El roadmap propone un formato de metadatos vía endpoint .well-known: el cliente podrá saber qué expone un servidor — y cuánto pesa — antes de establecer conexión. Para catálogos internos de servidores, gateways corporativos y clientes con presupuesto de contexto, es la pieza que falta.
Mientras llega, la lección de diseño ya es válida: un catálogo de tools tiene coste, y el coste lo paga el contexto del agente. Un servidor MCP enterprise no es el que expone más operaciones; es el que expone las justas, bien descritas. Nuestro criterio desde el primer servidor que construimos: pocas tools de grano grueso alineadas con casos de uso, antes que un espejo 1:1 del API interno.
Tasks: reintentos y caducidad, o los sistemas distribuidos llegan al protocolo
La primitiva Tasks — trabajo de larga duración que un agente encarga y consulta después — llegó al protocolo como experimental, y el roadmap la refina con experiencia de despliegues reales: semántica de reintentos para fallos transitorios y políticas de expiración para la retención de resultados tras completarse.
Si esto te suena, es porque es la conversación de siempre en sistemas distribuidos: reintentos, idempotencia, retención. La capa de agentes no inventa problemas nuevos; hereda los de toda la vida con nombres nuevos. Que el protocolo empiece a estandarizarlos es buena señal — significa que hay suficiente MCP en producción como para que duelan.
La implicación para quien construye hoy: no esperes al protocolo. Tu servidor necesita su propia semántica de reintentos e idempotencia ya, porque los agentes que lo consumen fallan, reintentan y duplican llamadas hoy. Cuando el estándar formalice la suya, adaptar una implementación disciplinada será trivial; rescatar una que asumió que cada llamada llega exactamente una vez, no.
Enterprise readiness: lo que el protocolo admite que le falta
El cuarto frente es el más revelador, precisamente por lo que reconoce: audit trails, SSO, comportamiento de gateways y portabilidad de configuración son hoy huecos del ecosistema. El roadmap busca formar un Working Group y anticipa que la mayor parte se resolverá vía extensiones, no en el núcleo del protocolo.
Traducción para un CTO: la adopción empresarial de MCP va por delante de sus garantías empresariales. Quién llamó a qué tool con qué argumentos, con qué identidad y con qué resultado — la pregunta que compliance hará tarde o temprano — hoy se responde en tu capa, no en el protocolo. Gateway propio, logging estructurado por tool, permisos por operación y por identidad. Así lo construimos nosotros, y así seguirá siendo una responsabilidad del integrador durante un tiempo, con o sin Working Group.
Esto no es un argumento contra MCP. Es el estado normal de un estándar joven que ha crecido más rápido que su periferia. Pero conviene entrar con los ojos abiertos: adoptar MCP no te da auditoría ni control de acceso gratis. Te da el contrato de integración; la gobernanza sigue siendo tuya.
Gobernanza: la señal que un decisor debería leer
El frente menos técnico del roadmap es el que más dice sobre la longevidad del protocolo: un contributor ladder documentado y un modelo de delegación para que los Working Groups aprueben cambios en su dominio sin pasar cada propuesta por los core maintainers.
Los estándares mueren de dos maneras: por abandono o por cuello de botella. MCP está institucionalizando su gobernanza exactamente en la fase en la que los protocolos serios lo hacen. Para una empresa evaluando si construir sobre MCP es apostar por algo que existirá en cinco años, esta es la señal — más que cualquier feature.
¿Invertir ahora o esperar?
La pregunta que motiva leer un roadmap. Nuestra respuesta, después de construir los dos lados del protocolo — servidores que exponen sistemas de negocio y clientes que los consumen:
Invierte ahora en lo que el roadmap no va a cambiar. El diseño de tus tools — pocas, de grano grueso, bien descritas —, la validación de entradas y salidas, los permisos por operación, tu auditoría y tu semántica de reintentos. Todo eso es tuyo, sobrevive a cualquier versión del protocolo, y es el 80% del trabajo de un servidor MCP serio.
No te acoples a lo que sí va a cambiar. El detalle del manejo de sesión, los mecanismos de descubrimiento, la implementación concreta de Tasks. Trátalos como lo que son: superficie del protocolo en evolución. Una capa fina de adaptación entre tu lógica y el transporte MCP te deja absorber el roadmap entero sin reescribir nada.
El roadmap de 2026 confirma la tesis de abril: MCP va en serio y va hacia la empresa. Los equipos que lleguen con servidores disciplinados — sin estado, auditados, con catálogos de tools diseñados y no volcados — van a absorber cada mejora del protocolo gratis. Los que llegaron con un espejo del API interno y 139 tools van a descubrir que el estándar madura más rápido que sus atajos.
Si estás evaluando MCP para conectar agentes a tus sistemas — o ya tienes servidores desplegados y quieres saber si aguantan lo que viene — auditamos tu arquitectura de integración contra este roadmap y te entregamos el plan concreto: qué exponer, cómo asegurar y auditar cada tool, y dónde poner la capa de adaptación para que el protocolo evolucione sin arrastrarte.
