MCP pasa a la Linux Foundation y estrena núcleo stateless para resolver el bloat de herramientas
La nueva especificación introduce rutas basadas en cabeceras y peticiones multi-round-trip para evitar el colapso de atención en agentes con cientos de APIs.
El Model Context Protocol (MCP) acaba de dar un salto arquitectónico. Tras salir de la sombra de Anthropic, la gobernanza del estándar ha pasado a la Linux Foundation, y con ello llega una revisión de la especificación centrada en la escalabilidad empresarial. El cambio clave es el abandono del estado persistente: el nuevo núcleo stateless permite que cada petición JSON-RPC viaje con su propio contexto criptográfico en cabeceras HTTP, eliminando la dependencia de conexiones SSE largas o procesos stdio locales que impedían el balanceo de carga horizontal.
Del caos de tokens al enrutado semántico
El problema que ha motivado este rediseño es el "tool bloat". En las primeras implementaciones, los equipos inyectaban los esquemas JSON de decenas de herramientas (GitHub, Jira, Kubernetes, etc.) en el prompt de sistema en cada llamada. Con más de 80 herramientas activas, esto consumía entre 20.000 y 40.000 tokens por petición, disparaba la latencia del primer token y degradaba severamente la atención del modelo. Los datos disponibles indican que la precisión en la selección de herramientas cae de un 94% con cinco opciones a menos de un 61% cuando el catálogo supera las 50 herramientas en el mismo contexto.
Para mitigarlo, los equipos de vanguardia están adoptando enrutado semántico just-in-time: en lugar de inyectar todo el catálogo, el sistema selecciona solo las 3 o 5 herramientas relevantes para el paso actual del agente. La nueva especificación de MCP facilita esto mediante el soporte para Multi Round-Trip Requests, que permite al servidor negociar iteraciones de transporte, solicitar autenticación MFA o validar presupuestos antes de ejecutar la herramienta, en lugar de forzar un ciclo síncrono aislado.
Esta arquitectura desacopla la sesión del hardware, permitiendo que las llamadas aterrizcen en funciones serverless o contenedores sin estado compartido. Es un movimiento lógico para quienes despliegan agentes en producción: elimina el punto único de fallo si un nodo cae en mitad de una tarea larga y reduce drásticamente los costes de inferencia al aligerar el prompt. Ahora toca ver cómo las librerías clientes y los servidores comunitarios implementan estas cabeceras nuevas sin romper la compatibilidad con las versiones anteriores.
