Evitar el tool sprawl, de 530 a 30 MCP tools por sesión

Si usas Claude Code, Codex o Cursor durante un tiempo, acumulas MCP servers como pestañas en un navegador. GitHub MCP, Memory MCP, Filesystem MCP, Slack, Notion, Stripe, Brave Search, más dos o tres propios. De repente tienes más de 200 tools en el contexto, tu agente elige la equivocada, alucina nombres de tools, o abandona el plan porque se pierde. Eso se llama tool sprawl, y Anthropic publicó las MCP Client Best Practices oficiales en abril de 2026 justo para esto.

Este playbook te trae 10 pasos hacia un tool routing limpio. Aprendes cómo asignar tools por agente, cómo mantener el contexto ligero incluso con 30 servers instalados, y cómo te das cuenta siquiera de que estás en el sprawl. Funciona con Claude Code, Cursor, Codex y cualquier MCP host que soporte tool filtering.

Antes de empezar: échale un vistazo a la lección L4-06 "Descubrimiento de MCP y marketplaces" y L6-07 "Orquestación multi-agente". Ahí está el concepto del porqué, aquí está la práctica del cómo.

Paso 1, hacer inventario

Cuenta qué tienes conectado. En Claude Code corres claude mcp list, en Cursor miras en ~/.cursor/mcp.json, en Codex lo mismo bajo ~/.codex/config.toml. Apunta todos los servers, luego el número de tools por server. GitHub MCP por sí solo trae 19 tools, Memory trae 50+, una suite completa llega rápido a 200.

Mi propio setup: 38 MCP servers, 530 tools si cargaran todos a la vez. Pero no lo hacen, porque los filtro por tarea. Sin filtrado eso sería el 80 por ciento de mi presupuesto de tokens solo para descripciones de tools.

Paso 2, entender el problema del tool sprawl

Tres síntomas te muestran que estás en el sprawl. Primero, el agente escribe nombres de tools completamente alucinados ("llamo a github_create_issue_with_assignees" aunque la tool se llame create_issue). Segundo, el agente elige la tool correcta pero con argumentos equivocados ("paso repo_name" aunque el parámetro se llame repository). Tercero, el agente pierde el plan ("Un momento, primero compruebo con la tool A, luego con la tool B, luego con la tool C..." y se diluye en meta-pasos).

Los tres síntomas tienen la misma causa: demasiadas descripciones de tools en el contexto, el mecanismo de atención se reparte. Anthropic habla de "token drift" y recomienda usar tool filtering de forma activa.

Paso 3, el patrón pickMcp como modelo mental

En vez de cargar todos los servers en el contexto a la vez, le das a cada agente o cada tarea solo los 3-5 servers que realmente necesita. Conmigo la función se llama pickMcp(role) y devuelve una lista tipada por rol.

Ejemplo: mi agente de research recibe solo mcp-research (web search), mcp-nex (memoria) y mcp-notion (output). Mi agente de code review recibe solo mcp-github, mcp-nex (memoria para revisiones anteriores), mcp-filesystem. Ningún agente recibe todo.

El patrón funciona también sin programación. Puedes simplemente crear perfiles y cambiar entre ellos a mano.

Paso 4, configurar perfiles en Claude Code

Claude Code 2.1.119 introdujo /config persistente, con eso puedes tener una config de MCP distinta por workspace. Crea tres o cuatro perfiles: research, code, ops, writing. Cada perfil tiene su propio ~/.claude/profiles/<name>/mcp.json.

En cada perfil defines solo los servers que pertenecen ahí. Research recibe tools de búsqueda y memoria, Code recibe GitHub más filesystem más memoria, Ops recibe conexiones a servidores más memoria, Writing recibe solo memoria más Notion.

Cambia con claude --profile=research. Claude carga solo los servers del perfil, el resto se queda en el armario.

Paso 5, filtrar tools dentro de un server

Algunos servers traen 50+ tools aunque solo necesites 5 de ellas. GitHub MCP por ejemplo: yo uso create_issue, search_issues, get_pull_request, create_pull_request, merge_pull_request. Las otras 14 (workflows, releases, gestión de org) las necesito raras veces.

Los MCP servers más modernos soportan "toolsets" o "filter flags" al arrancar. GitHub MCP por ejemplo --toolsets=issues,pull_requests. Mira en la documentación de tu server por --enabled-tools o --disabled-tools. Si el server no puede, es un deseo para el maintainer.

Paso 6, progressive disclosure como freno de emergencia

Si de verdad necesitas muchas tools pero no a la vez, ayuda progressive disclosure. Concepto: arrancas con una meta-lista ("¿qué categorías tienes ahí?") y el agente pide las tools de una categoría solo on-demand.

Solo.io publicó un patrón sobre esto en abril de 2026. En la práctica: construyes un pequeño MCP wrapper que primero devuelve una lista de nombres de servers. El agente elige un server, luego entregas la lista de tools de ese server. Cuesta un round trip, ahorra el 80 por ciento de tokens en el caso por defecto.

No todo el mundo lo necesita. Quien se apaña con 30 tools puede saltarse este paso.

Paso 7, la memoria como reductor de sprawl

La memoria es tu mejor amiga contra el tool sprawl. En vez de tres tools que pueden todas "escribir notas" (Notion, Apple Notes, Markdown), tienes un único Memory MCP que lo cubre todo. En vez de cuatro tools que hacen "search" (Google, Bing, Brave, Perplexity), tienes mcp-research con una interfaz unificada.

Esa es la palanca de centralización. Comprueba en tu lista del paso 1 dónde tienes tools redundantes y consolida.

Paso 8, rastrear conflictos de nombres

Si dos servers tienen ambos una tool llamada search, el agente alucina seguro. Ese es el asesino subestimado. GitHub MCP tiene search_issues, Brave Search tiene search, algunos memory servers tienen search_memories. El agente pierde la visión de quién puede hacer qué.

Solución: pon un prefijo de tool claro por MCP server si el server lo soporta (github_search_issues en vez de search_issues). Si no, entonces al menos ten cuidado al armar los perfiles de que no caigan dos tools de search en el mismo perfil.

Paso 9, medir tu propio setup

Constrúyete un pequeño script de medición. Conmigo funciona así: después de cada sesión vuelco el número de tool calls más los nombres de las tools más si la llamada tuvo éxito (sin error de alucinación). De eso veo mensualmente qué tools no se usan nunca, cuáles se alucinan a menudo, cuáles se usan siempre en combinación con cuáles otras.

Tools que se usaron cero veces en 30 días: fuera del perfil. Tools que se alucinaron más de 3 veces en 30 días: revisar el naming o mejorar la documentación.

Algunos MCP hosts tienen telemetría incorporada, otros no. Si no, tu propio logging en el wrapper del server.

Paso 10, perfil por defecto como autodisciplina

Mi perfil por defecto tiene exactamente tres servers. mcp-nex (memoria), mcp-filesystem (leer/escribir local), mcp-research (web). 30 tools en total. Si necesito más, cambio activamente con claude --profile=....

Esta decisión "el default es pequeño, más solo bajo petición" es la disciplina más importante. Los principiantes quieren tenerlo todo siempre a mano por si acaso. Los profesionales saben que menos contexto = mejores resultados, y el cambio entre perfiles es cosa de 5 segundos.

Qué viene después

Si todavía no has montado la memoria, ve por el playbook "Memory portabel nutzen". Si quieres construir tus propios MCP servers, las lecciones L6-01 a L6-08 más el playbook "Erster MCP-Server in 90 Minuten". Si quieres profundizar en sub-agents (cada uno con su propio perfil), el playbook "Erster Sub-Agent in 30 Minuten".

Fuentes: Anthropic MCP Client Best Practices, modelcontextprotocol.io/docs/develop/clients/client-best-practices. Artículo de progressive disclosure de Solo.io de abril de 2026. Patrón pickMcp propio documentado en agents/lib/mcp-config.ts.