Conectas GitHub, Slack, Linear y un CRM. El cliente MCP hace tools/list. El modelo recibe ciento y tantas definiciones con schema, descripción y parámetros. Todavía no pidió nada. Ya gastó contexto, ya se confundió de tool, y ya le mostraste el mapa de lo que puede tocar.
Eso es el anti-patrón. Progressive disclosure de tools es lo contrario: el agente no ve el catálogo. Ve dos puertas. Busca. Recién entonces carga el schema de lo que va a usar.
Por eso lo implementamos en oneNorma Gateway. No es un extra de DX. Es cómo un Virtual MCP escala sin inflar el prompt ni filtrar el inventario.
Qué es progressive disclosure (sin la jerga de la API)
La idea es vieja en producto: no muestres todo el menú, muestra el siguiente paso. En MCP se traduce así:
tools/listno dumpa GitHub, Slack ni el CRM.- El modelo llama search con una intención (“listar PRs”, “slack”, “crear issue”).
- Recibe un puñado de tools con nombre namespaced, descripción y
inputSchema. - Llama execute con ese nombre exacto y los argumentos.
Anthropic lo empaquetó como Tool Search / defer_loading. Cloudflare y buena parte del ecosistema MCP usan el par search / execute. Es el mismo patrón. La diferencia es dónde vive.
Si lo dejas en el cliente (Claude, Cursor, un SDK), cada agente lo implementa distinto o no lo implementa. Si lo pones en el gateway, cualquier cliente MCP que hable JSON-RPC se encuentra con dos tools. El catálogo nunca cruzó el cable.
Por qué es bueno (y no solo “ahorra tokens”)
Contexto. Cada tool MCP no es una línea. Es un JSON schema. Diez conectores por quince tools y el system prompt ya come lo que deberías gastar en la tarea. Progressive disclosure recorta eso de raíz: el modelo carga schemas on demand. En las cifras que publica Anthropic, el recorte de tokens de tools anda cerca del 85%. Nosotros no prometemos ese número. Prometemos que tools/list no es un dump.
El modelo elige peor cuando ve demasiado. Con 80 tools el agente inventa nombres, mezcla conectores o dispara la tool “parecida”. Search por intención + execute con el nombre namespaced (github__list_pull_requests) baja esa alucinación. Menos menú, menos error.
Security: enumerar tools es un leak. Un tools/list completo es un mapa de privilegios. Sirve al copiloto. También sirve a un prompt injection o a un usuario que no debería saber que existe create_pull_request. En el gateway, una policy de deny (incluso wildcard) no deja enumerar. Lo que está bloqueado no aparece en search. Lo que no está en el allowlist del conector, tampoco.
Eso es gobierno de MCP aplicado al discovery, no solo a la ejecución.
Cómo lo hacemos en oneNorma Gateway
Un Virtual MCP agrega varios servidores MCP reales (upstream) detrás de una URL, con identidad de organización, allowlist y trazas. Sin progressive disclosure, ese agregado sería un catálogo gigante en cada handshake.
El contrato que ve el agente es deliberadamente chico:
tools/list → search, execute
(+ authenticate si un conector todavía no tiene credencial)
search(query, limit) → matches permitidos, namespaced
execute(name, arguments) → la tool de verdad, con policy y audit
Tres detalles que no son cosmética:
- El catálogo se filtra antes de rankear. Search no es un full-text sobre todo lo que existe en GitHub. Es sobre lo que ese usuario, en ese Virtual MCP, puede ver. Allowlist del conector + policy de acceso.
- Los nombres van namespaced.
github__list_pull_requests, nolist_pull_requests. El execute no adivina el conector. El audit tampoco. - Search y execute son eventos distintos. Puedes reconstruir “buscó PRs” y “ejecutó list_pull_requests” por separado. Si las trazas viven solo en el proveedor del modelo, no tienes gobierno. Tienes un chat.
El cliente (Cursor, Claude, un agente interno) no tiene que saber de defer_loading. Habla MCP. El gateway ya hizo el recorte.
Qué no resuelve
Progressive disclosure no sustituye un allowlist. Tampoco sustituye un humano en escrituras de alto impacto. Un agente que encuentra delete_repo porque alguien lo dejó en el allowlist sigue siendo un incidente. Solo que ahora el incidente no empezó con un dump de 140 tools en el primer tools/list.
Si el producto ya ejecuta tools en producción, el control se prueba ofensivamente: pentesting de IA. El directorio de MCP servers sirve para no reinventar conectores; el gateway sirve para no entregárselos todos de una.
Qué significa para tu cumplimiento (Chile)
Un agente con tools trata datos. La Ley 21.663 y la ANCI empujan a demostrar gestión de riesgo con inventario y evidencia, no con una política en un drive. Si no puedes decir qué tools estaban visibles, para quién, y cuáles se ejecutaron, no tienes inventario. Tienes un chat.
La Ley 21.719 pide medidas de seguridad acordes al tratamiento. Recortar el catálogo que ve el modelo es una medida concreta: menos PII y secretos en el contexto, menos superficie enumerable, logs de search y execute que puedes mostrar en un due diligence.
ISO/IEC 42001 y NIST AI RMF ayudan a ordenar el gobierno de IA. El progressive disclosure es el control de mínimo privilegio en discovery. El mínimo privilegio en ejecución sigue siendo allowlist, tenant y aprobación humana.
Si quieres ver cómo queda un Virtual MCP con search/execute sobre tu stack, agenda una demo. Si el problema es el abuso de tools y no el catálogo, empieza por el LLM pentest.
Más en IA
Qué es Shadow AI, por qué el ChatGPT no autorizado es un problema de security y AI governance en empresas de Chile, y cómo empezar a gobernarlo sin un comité eterno.
Siete patrones de prompt injection en chatbots y agentes (directo, RAG, tools/MCP) y controles que sí bajan el riesgo en producción.
Un pentest web no cubre tu asistente de IA. Qué es un LLM pentest, qué se prueba en chatbots y agentes en Chile y Latam, y cuándo encargarlo.