El Arreglo de MCP para los Catálogos de Herramientas Inflados Tiene una Factura — Y Está en los Docs, No en el Roadmap
El roadmap actual de los mantenedores de MCP nombra un problema que la mayoría de quienes construyen agentes ha sentido sin medirlo: el catálogo de herramientas de un servidor se le cobra al modelo antes de que alguien pregunte nada. Bajo Improved primitives, el artículo es directo al respecto — "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows."
Lo que hace que esto valga la pena no es el roadmap. Es que el arreglo ya está escrito, en la documentación de clientes, junto a una advertencia de que puede costar más que el problema que resuelve — y esa advertencia recibe mucha menos atención que el arreglo al que pone condiciones.
El número que los docs le ponen
La página de buenas prácticas para clientes
que salió con la especificación 2026-07-28 describe el descubrimiento progresivo:
el host sigue llamando a tools/list como siempre, pero posterga inyectar esas
definiciones en el contexto del modelo. En su lugar le entrega al modelo una sola
meta-herramienta liviana, search_tools, y carga los esquemas completos solo de lo
que vuelva.
El propio diagrama de la página pone cifras a la diferencia — unos 150.000 tokens consumidos solo por las definiciones cuando se carga todo por adelantado, contra unos 2.000 con descubrimiento progresivo. Esa es la ilustración de la documentación, no un benchmark publicado, así que trátala como el orden de magnitud que afirman los mantenedores y no como una medición que puedas reproducir. Aun así la forma sirve: dos órdenes de magnitud, pagados antes de que empiece la conversación.
Los docs también dan un umbral en lugar de dejarlo al gusto:
Implement a threshold as a percentage of the context window. For example, 1%-5%.
Por debajo de eso, cargar todo está bien. Por encima, cambia de estrategia.
La trampa
Aquí está la frase que cambia cómo construirías esto. En la misma página, bajo Interaction with Prompt Caching:
Adding or removing tool definitions mid-conversation invalidates that cache, and the resulting miss can cost more tokens than the definitions you removed.
La mayoría de los proveedores cachea el prefijo del prompt, y el arreglo tools vive
cerca del principio de ese prefijo. Así que el mecanismo que te ahorra 148.000 tokens
de definiciones por adelantado funciona mutando el prefijo — que es exactamente lo
que una caché de prompt no tolera. Una caché de prefijo solo vale hasta lo primero que
cambió: edita el arreglo en el turno seis y se va todo lo cacheado a partir de ahí, que
en una conversación larga es casi todo.
Las mitigaciones que dan los propios docs conviene leerlas como restricciones de
diseño más que como consejos: añadir las definiciones nuevas estrictamente después
del punto de corte de la caché en vez de reordenar el arreglo tools, o enrutar cada
llamada por una única meta-herramienta estable call_tool({name, args}) para que el
arreglo no cambie nunca. Y tratar la desconexión de un servidor como una frontera de
conversación, no como una operación por turno.
Tres cachés, y solo una es del protocolo
Aquí es donde se vuelve genuinamente confuso, y vale la pena separar las capas porque es fácil colapsarlas en una.
La caché de transporte. Los resultados de tools/list llevan pistas ttlMs y
cacheScope, definidas en la utilidad de caché de la especificación. Un cliente que
las respete se salta el viaje HTTP. Esta sí es de MCP, en el sentido de que el
protocolo la especifica.
El memo del lado del host. Consejo, no protocolo — una línea en las guías de implementación de la documentación de clientes, que recomienda memoizar una definición ya obtenida para que reinyectarla después no requiera otra llamada. Describe qué debe hacer un host con su propio estado; nada cruza el cable. La página es explícita sobre lo que no hace: "This is separate from what's currently in the model's context."
La caché de prompt del proveedor. No es de MCP en absoluto. Es de quien sirve tu modelo, se indexa por el prefijo, y la invalida exactamente aquello que el descubrimiento progresivo hace para vivir.
Con la primera nos topamos por la vía difícil al escribir la
Parte 3 de la serie de LangGraph —
un cache=True del lado del cliente no hace nada si el servidor no anuncia un TTL, y
nada te avisa. Habiendo leído ahora esta página con calma, la lección más útil es que
incluso acertando con eso lo que compras es un viaje de ida y vuelta y nada más. Los
esquemas siguen aterrizando en el contexto. Son problemas distintos con arreglos
distintos, y confundirlos es el error por defecto.
Qué significa si acotas herramientas a mano
La Parte 4 partió un servidor MCP entre un agente de agenda y uno de facturación filtrando el catálogo por rol — una lista de permitidos estática, decidida antes de la corrida y fija durante toda ella.
Leído contra estos docs, eso resulta tener una propiedad que vale nombrar: como la
lista no cambia a mitad de conversación, no toca el prefijo del prompt, así que
esquiva por completo el problema de invalidación de caché. Es un instrumento más tosco
que search_tools — decides por adelantado en lugar de dejar que el modelo busque —
pero para un catálogo pequeño repartido entre roles conocidos, "tosco y estable
respecto a la caché" puede ser simplemente el intercambio correcto. Los docs dicen
algo equivalente en la otra dirección: por debajo del umbral del 1–5%, cargar todo
está bien.
No generalizaría más allá de eso. No hemos medido el costo de un fallo de caché contra el costo de las definiciones en la WEC Inference API, y la posición honesta es que el punto de cruce depende del tamaño de tu catálogo, del largo de tus conversaciones y del comportamiento de caché de tu proveedor. Lo que los docs establecen es que ese punto de cruce existe.
Sobre que el roadmap no tenga fechas
El roadmap nombra cinco áreas prioritarias y no se compromete a ninguna fecha de lanzamiento ni número de versión en ninguna parte. Es justo preguntar por qué, y la respuesta más justa viene de los propios mantenedores. Soria Parra, en el roadmap de marzo:
A release-oriented roadmap implies a level of predictability that open-standards work rarely has.
Es una postura razonable para una especificación que se desarrolla en grupos de trabajo, y el propio historial de marzo la respalda. "Transport Evolution and Scalability" era una de sus cuatro áreas prioritarias, y nombró el problema con precisión — llevar MCP a escala había dejado al descubierto "a consistent set of gaps: stateful sessions fight with load balancers, horizontal scaling requires workarounds" — sin comprometerse a ninguna fecha para arreglarlo. La especificación de julio entregó ese núcleo sin estado, cinco meses después.
El caché es otra historia. No aparece en ninguna parte del roadmap de marzo, y el descubrimiento progresivo llegó como documentación para clientes sin haber estado en ningún roadmap — algo que conviene tener en cuenta antes de tratar cualquiera de los dos roadmaps como un índice fiable de lo que viene.
La recepción no ha sido uniformemente cálida. El
hilo de Hacker News sobre el roadmap
llegó a 270 puntos y 161 comentarios, y la crítica va en tres direcciones, no en una. El
costo del vaivén pasado, de colingauvin:
It's unreal how bad the initial rollout was between HTTP/streaming and stdio, bearer auth and OAuth. Virtually every client/MCP server pair had a different portion of that matrix implemented.
El diseño en sí, de nprateem:
The real disaster was making it stateful. Need to get some adults in the room.
Y si el protocolo justifica su complejidad, de zackify: "I think the spec
overcomplicates everything honestly."
La primera es la que atañe a este post. Es un reclamo legítimo sobre la deriva entre implementaciones, y es el riesgo a vigilar también con el descubrimiento progresivo: hoy es un patrón del lado del cliente, con estrategias recomendadas en lugar de especificadas, lo que significa que dos hosts pueden ser ambos razonables y comportarse distinto.
La versión corta
El roadmap te dice que el inflado del catálogo de herramientas está en la lista de los mantenedores. La documentación te dice qué hacer al respecto ahora y — hay que reconocérselo — te dice en la misma frase que el arreglo tiene una factura. Si estás cargando un catálogo grande en cada conversación, lee esa página antes de construir una capa de descubrimiento, y averigua dónde está el punto de corte de caché de tu proveedor antes de decidir que las cuentas de tokens te favorecen.
📖 Fuentes: Blog del Model Context Protocol — The New MCP Roadmap · Docs de MCP — Client Best Practices · Blog del Model Context Protocol — The 2026 MCP Roadmap · Hacker News — New MCP Roadmap