El protocolo de contexto modelo ha alcanzado un importante hito en materia de infraestructura: su revisión del 28 de julio de 2026 mueve el protocolo hacia un núcleo sin estado. Para los equipos que crean sistemas de agentes, servidores de herramientas, integraciones IDE o capas de orquestación multimodelo, esta no es una actualización cosmética de las especificaciones. Cambia las suposiciones sobre las sesiones, la inicialización, el escalado, la compatibilidad y la gobernanza.
La versión candidata de MCP describió la especificación del 28 de julio como la adición de un núcleo de protocolo sin estado, un marco de extensiones, tareas, aplicaciones MCP, refuerzo de autorización y una política formal de desaprobación. El blog oficial de MCP también advirtió que el lanzamiento contiene cambios importantes. GitHub, que opera una de las implementaciones de servidor MCP más visibles, dijo antes del lanzamiento final que su servidor MCP ya admitía la nueva especificación y describió el protocolo como "sin estado" el 28 de julio.
El significado práctico es sencillo: MCP se está formando menos como una capa de integración local con muchas sesiones y más como un protocolo a escala de Internet para acceso remoto a herramientas. Esto es importante porque los sistemas de agentes ya no se limitan a las herramientas de desarrollo de escritorio. Se ejecutan cada vez más dentro de servicios en la nube, sistemas de CI, flujos de trabajo de atención al cliente, rastreadores de problemas y plataformas de automatización empresarial.
Lo que cambió en MCP
El cambio principal es el paso a un núcleo de protocolo sin estado. El registro de cambios de GitHub dice que el nuevo núcleo elimina sesiones e inicializa, con el objetivo de hacer que las implementaciones remotas de MCP sean más fáciles de escalar. Se trata de un cambio arquitectónico significativo. Los protocolos con estado pueden funcionar bien para herramientas locales y entornos controlados, pero complican el escalado horizontal, la ejecución sin servidor, la conmutación por error, la implementación perimetral y el equilibrio de carga.
Un núcleo sin estado brinda a los implementadores más libertad para ejecutar servidores MCP detrás de una infraestructura web ordinaria. Las solicitudes se pueden distribuir entre instancias sin conservar una sesión de larga duración en un backend específico. Para organizaciones grandes, eso puede reducir la complejidad operativa. Para equipos más pequeños, puede hacer que los servidores MCP alojados sean más fáciles de implementar utilizando computación administrada en lugar de una infraestructura personalizada de larga duración.
La versión más amplia 2026-07-28 también presenta un marco de Extensiones y Tareas, según los materiales de la versión candidata. Esas adiciones sugieren que MCP se está volviendo más modular y más explícito en cuanto al trabajo de mayor duración. Las aplicaciones MCP y el refuerzo de autorizaciones apuntan en la misma dirección: el protocolo está madurando desde un pegamento temprano del ecosistema hasta una capa más formal para la interacción entre agente y herramienta.
El costo de esa maduración es el trabajo de compatibilidad. El blog de MCP caracterizó el lanzamiento como uno con cambios importantes, y los materiales de TypeScript y C# SDK publicados en torno a la revisión se centran en el soporte de migración y conceptos sin estado. Cualquier equipo que opere un servidor MCP, incorpore MCP en una extensión IDE o enrute llamadas de agentes a través de una infraestructura interna debe tratar la revisión como un evento de ingeniería en lugar de una actualización de estándares en segundo plano.
Por qué es importante el MCP sin estado para los desarrolladores y operadores
Las herramientas de los agentes tienen un problema de escalado que se ve diferente al escalado de API normal. Una sola solicitud de usuario puede desencadenar muchas llamadas a herramientas, giros de modelos, reintentos, lecturas de archivos, consultas de búsqueda y pasos de aprobación. Cuando el protocolo de la herramienta supone sesiones duraderas, los operadores de producción deben preservar el estado en esas interacciones o crear soluciones alternativas en torno al protocolo.
Al eliminar sesiones del núcleo, MCP se adapta mejor a entornos donde las cargas de trabajo de los agentes están distribuidas en ráfagas, y son asincrónicas. Las funciones sin servidor, los trabajadores perimetrales, las implementaciones de Kubernetes y los sistemas multirregionales se benefician cuando las solicitudes se pueden manejar de forma independiente. Eso no elimina el estado de las aplicaciones de los agentes; mueve el estado a bases de datos de aplicaciones, colas de tareas, sistemas de identidad o capas de flujo de trabajo explícito en lugar de incrustarlo en el núcleo del protocolo.
Para los desarrolladores, el cambio debería hacer que los servidores de herramientas remotas sean más fáciles de consumir. Para los equipos de plataforma, puede simplificar la observabilidad y la planificación de la capacidad. En lugar de depurar el comportamiento opaco de afinidad de sesión, los operadores pueden centrarse en los seguimientos a nivel de solicitud, la latencia de llamadas de herramientas, las decisiones de autorización y los patrones de error.
También hay un ángulo de gobernanza. A medida que MCP se vuelve más común en los asistentes de codificación y los agentes empresariales, las empresas necesitarán políticas sobre a qué herramientas pueden llamar los agentes, a qué datos pueden acceder y qué usuarios o servicios pueden invocarlos. Por lo tanto, el endurecimiento de la autorización en la nueva revisión no es incidental.Refleja la realidad de que el acceso a las herramientas es ahora un límite de seguridad, no solo una conveniencia para los desarrolladores.
Quién se ve afectado
Los grupos más directamente afectados son los mantenedores de servidores MCP, los usuarios de SDK, los equipos de plataformas de agentes y las organizaciones que exponen herramientas internas a agentes de IA. Si un servidor depende del comportamiento de la sesión o de flujos de inicialización anteriores, será necesario realizar pruebas con la nueva especificación. Si una aplicación admite varias versiones de MCP, es posible que necesite negociación de versiones, capas de compatibilidad o un plan de migración por fases.
Los proveedores de IDE y herramientas para desarrolladores también están dentro del alcance. MCP aparece cada vez más junto con agentes de codificación, agentes personalizados y funciones de gestión de modelos. Un núcleo de protocolo sin estado facilita que estos productos llamen a herramientas remotas de manera confiable, pero solo si sus integraciones siguen el ritmo de las especificaciones.
Las empresas que utilizan la automatización de agentes deben prestar atención incluso si nunca leyeron la especificación MCP. El cambio puede afectar la confiabilidad de los agentes que se conectan a repositorios, sistemas de emisión de tickets, bases de datos, bases de conocimiento internas o herramientas de implementación. Durante los períodos de migración, los modos de falla probables no son solo interrupciones obvias. Pueden incluir capacidades de herramientas faltantes, comportamiento de autenticación modificado o agentes que toman rutas diferentes porque un servidor de herramientas ya no se comporta como se esperaba.
Para una puerta de enlace API de IA como Model Gate, la conexión es práctica. Una API de IA unificada se sitúa cada vez más cerca del enrutamiento de modelos, la gestión de claves de API, el análisis de uso y la gobernanza de API en equipo. A medida que los sistemas de agentes agregan llamadas a herramientas MCP además de las llamadas a modelos normales, las capas de puerta de enlace y observabilidad deberán tener en cuenta ambos lados del flujo de trabajo: qué modelo se utilizó, qué herramientas se invocaron, cuánto cuestan, quién las autorizó y dónde ocurrieron las fallas.
Prioridades de migración y preguntas abiertas
La primera prioridad de migración son las pruebas de compatibilidad. Los equipos deben hacer un inventario de los clientes y servidores de MCP, identificar las dependencias en las sesiones o inicializar el comportamiento y realizar pruebas con los SDK del 28 de julio de 2026 o los materiales de conformidad cuando estén disponibles. Los sistemas de producción deben preparar la actualización, especialmente si los agentes realizan acciones con efectos secundarios, como crear solicitudes de extracción, modificar problemas, consultar datos de clientes o ejecutar flujos de trabajo de implementación.
La segunda prioridad es la observabilidad. La infraestructura sin estado puede ser más fácil de escalar, pero los sistemas de agentes distribuidos aún necesitan ID de correlación, captura de seguimiento, registros de solicitudes y eventos de políticas. Sin ellos, los equipos pueden cambiar la complejidad de la sesión por la complejidad de la depuración. El análisis de uso debe distinguir entre llamadas de modelo y llamadas de herramientas, especialmente cuando los flujos de trabajo de los agentes son facturados, tienen tarifas limitadas o son auditados por el equipo.
La tercera prioridad es la revisión de la autorización. Si la nueva especificación refuerza la semántica de autorización, los implementadores no deberían simplemente trasladar las antiguas suposiciones de acceso a la nueva versión. Deberían volver a verificar los alcances de los tokens, la delegación de usuarios, las cuentas de servicio, los registros de auditoría y el comportamiento de denegación. El acceso a las herramientas debe tener privilegios mínimos de forma predeterminada, especialmente para implementaciones MCP remotas.
Vale la pena verificar algunos detalles antes de que las organizaciones tomen decisiones de diseño irreversibles. La investigación disponible para este artículo incluyó la versión candidata, la página de especificaciones, los materiales de migración del SDK y la nota de implementación de GitHub. La redacción normativa final de la especificación 2026-07-28 debe revisarse directamente antes de citar los requisitos exactos del protocolo en los estándares internos o la documentación del cliente.
Incluso con esa advertencia, la dirección es clara. MCP se está convirtiendo en un protocolo más orientado a la producción para la infraestructura de agentes. El núcleo sin estado debería hacer que las implementaciones remotas sean más fáciles de escalar, pero también obliga al ecosistema a limpiar suposiciones de implementaciones anteriores. Para los equipos que se forman con agentes, este es el tipo de cambio de protocolo que merece un ticket de sprint, no sólo un marcador.