Dieta de MCPscuando tus herramientas pesan más que tu trabajo

01 el mecanismo

Por qué una herramienta que no usas te cobra igual

Cuando Claude Code arranca, se conecta a cada servidor MCP y le manda una petición tools/list. El servidor responde con la definición de cada herramienta: nombre, descripción y un inputSchema en JSON Schema que describe los parámetros. Esa definición es lo que el modelo lee para decidir si la herramienta sirve y cómo llamarla. Es texto, y el texto que el modelo lee es contexto, y el contexto se cobra en cada petición.

git clone https://github.com/davidiriza-lab/dieta-de-mcps.git

{
  "name": "search_contacts",
  "description": "Busca contactos por nombre, correo o teléfono. Soporta paginación con startAfterId.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Texto a buscar" },
      "limit": { "type": "number", "description": "Máximo de resultados (1-100)" },
      "startAfterId": { "type": "string", "description": "Cursor para la siguiente página" }
    },
    "required": ["query"]
  }
}

Multiplica eso por 200 herramientas de un CRM y te salen 130 KB. Hay dos modos en que ese texto llega al modelo, y conviene saber en cuál estás:

02 lo que medí

El inventario que justificó la poda

Antes de tocar nada medí lo que había. El diagnóstico de dos semanas de transcripts (23,804 peticiones, 63 conversaciones) dejó dos cifras sobre los MCPs: la lista de nombres pesaba ~19k tokens por arranque, y la distribución de llamadas era absurda. Esto había en scope user, es decir, cargado en todos los proyectos:

El patrón se repite en cualquier stack: los servidores más pesados son los que envuelven una API grande (CRM, hosting, generación de media) y son justo los que menos se usan desde el chat, porque para operaciones masivas terminas escribiendo un script. Las tres instancias del CRM que quité duplicaban cuentas que el servidor multicuenta ya cubría con un selector de cuenta: cero pérdida de acceso, 759 herramientas menos, ~9.5k tokens menos en cada arranque.

03 hazlo tú

Cómo medir cuánto pesan los tuyos

Claude Code trae dos vistas útiles: /context muestra qué ocupa la ventana (incluida la parte de MCP) y /usage atribuye el consumo reciente por servidor, contando solo las peticiones que consumieron un resultado de ese servidor. Sirven para ver el efecto. Para ver la causa, lo que yo quería era el número por servidor antes de arrancar nada: cuántas herramientas expone y cuántos bytes de esquema devuelve. Este script lee tu configuración, levanta cada servidor stdio, le pide tools/list y te lo tabula.

mkdir -p ~/mcp-medidor && cd ~/mcp-medidor && npm init -y >/dev/null && npm i @modelcontextprotocol/sdk

import { readFileSync } from "node:fs";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

// Lee los servidores de scope user y los de scope local de cada proyecto
const cfg = JSON.parse(readFileSync(process.env.HOME + "/.claude.json", "utf8"));
const servers = { ...(cfg.mcpServers ?? {}) };
for (const p of Object.values(cfg.projects ?? {})) Object.assign(servers, p.mcpServers ?? {});

const rows = [];
for (const [name, s] of Object.entries(servers)) {
  if (s.type && s.type !== "stdio") { rows.push([name, "(remoto)", "-", "-"]); continue; }
  const transport = new StdioClientTransport({
    command: s.command,
    args: s.args ?? [],
    env: { ...process.env, ...(s.env ?? {}) },
    stderr: "ignore",
  });
  const client = new Client({ name: "medidor", version: "0" });
  try {
    await Promise.race([
      client.connect(transport),
      new Promise((_, reject) => setTimeout(() => reject(new Error("timeout")), 45000)),
    ]);
    const tools = [];
    let cursor;
    do {
      const r = await client.listTools({ cursor });
      tools.push(...r.tools);
      cursor = r.nextCursor;
    } while (cursor);
    const bytes = JSON.stringify(tools).length;
    rows.push([name, tools.length, bytes, Math.round(bytes / 4)]);
  } catch (e) {
    rows.push([name, "ERR " + e.message.slice(0, 40), "-", "-"]);
  }
  try { await client.close(); } catch {}
}
console.log("servidor\ttools\tbytes\t~tokens");
for (const r of rows) console.log(r.join("\t"));

cd ~/mcp-medidor && node medir.mjs 2>/dev/null | column -t -s $'\t'

La columna ~tokens es bytes entre cuatro: una aproximación gruesa pero suficiente para ordenar. Esto fue lo que salió en mi máquina el día que escribí la guía, ya después de la primera poda:

servidor           tools  bytes    ~tokens
crm-comunitario    253    132088   33022
crm-propio         211    78524    19631
analisis-estatico  7      53855    13464
automatizacion-a   25     40358    10090
automatizacion-b   25     40358    10090
navegador-devtools 29     25160    6290
base-datos-a       29     21104    5276
base-datos-b       29     21104    5276
navegador-e2e      24     18502    4626
imagen-a           6      17893    4473
diseno-decks       5      5512     1378
docs-librerias     2      4860     1215
imagen-b           6      2576     644
video-gen          (remoto)
anuncios           (remoto)

• El número de herramientas engaña. El servidor de análisis estático tiene 7 y pesa 53 KB: casi 2 mil tokens por herramienta, porque cada una lleva el esquema completo de reglas en la descripción. Mide bytes, no cuenta.
• Dos instancias del mismo paquete devuelven exactamente los mismos bytes (40,358 y 40,358). Es esquema duplicado: la segunda instancia no aporta capacidad nueva, solo otra credencial.
• Los dos CRM suman 464 herramientas y 210 KB. Son la mitad del inventario. Si un día dejo de trabajar desde el chat con ese CRM, con quitar dos líneas de config bajo el peso a la mitad.
• El mismo servidor puede pesar distinto según cómo lo configures. El de automatización (n8n-mcp) expone 7 herramientas y 12 KB si lo arrancas sin credenciales de instancia (solo documentación de nodos y plantillas), y 25 herramientas y 40 KB en cuanto le das N8N_API_URL y N8N_API_KEY, porque agrega las de administrar workflows. Lo medí con el script: si en un proyecto solo consultas cómo se configura un nodo, no le des la llave ahí.

04 qué se queda y qué no

Cuatro criterios para podar

La regla que resume las cuatro: un MCP se justifica si Claude lo llama varias veces por semana desde el chat y no hay un CLI que haga lo mismo. Todo lo demás es peso.

Vas a encontrar cifras redondas por ahí: que no pases de tantos servidores prendidos, que más de tantas herramientas activas confunden al modelo. No salen de la documentación, que dice explícitamente que no hay tope por servidor y que el límite práctico es tu ventana de contexto. Yo no uso un número: uso bytes (el medidor), llamadas (/usage) y la pregunta del CLI. Con eso, trece servidores pueden estar bien y cuatro pueden ser demasiados.

05 dónde vive cada uno

Local, project y user: elegir bien el scope es media dieta

Claude Code guarda los servidores en tres lugares, y de dónde los guardes depende en qué conversaciones se cargan. El default de claude mcp add es local, que es el más conservador. El error común es agregar todo con --scope user porque 'así lo tengo en todos lados', y así es como terminas con 15 servidores en una carpeta de contenido que no necesita ninguno.

Si un nombre existe en dos scopes, gana el más específico: local sobre project sobre user. Eso te deja un truco: el mismo nombre en scope local con otra credencial anula al de user solo en ese proyecto, sin duplicar la instancia global. Y los servidores de .mcp.json piden aprobación la primera vez que abres el proyecto; si en un repo ajeno rechazaste uno y quieres volver a decidir, claude mcp reset-project-choices.

Hay una cuarta palanca que no es scope pero se le parece: el apagado desde /mcp también es por proyecto. Un CRM en scope user puede estar prendido en la carpeta donde vendes y apagado en la carpeta donde escribes, sin moverlo de scope ni duplicarlo. Muchos configurados, pocos prendidos en cada carpeta: eso es lo que de verdad baja el arranque.

06 paso a paso

La poda, comando por comando

1. Inventario: claude mcp list te da cada servidor con su estado de conexión. Corre además el medidor de arriba para tener herramientas y bytes por servidor.
2. Uso real: abre Claude Code y escribe /usage; la sección de atribución muestra el porcentaje reciente por servidor MCP (últimas 24 h o 7 días). Un servidor pesado con 0% es candidato inmediato.
3. Respalda la configuración antes de tocar: cp ~/.claude.json ~/.claude.json.bak-$(date +%Y%m%d). El remove no pregunta y las variables de entorno (tokens) se van con él.
4. Quita lo que tiene CLI o está duplicado con claude mcp remove <nombre> -s user. Si el nombre existe en varios scopes, el flag -s te obliga a decir cuál.
5. Mueve a scope project lo que solo usa un repo: claude mcp get <nombre> para ver su comando y variables, remove del scope user, y add con --scope project desde la carpeta del repo. Las credenciales no van en .mcp.json si el repo se comparte: usa variables de entorno referenciadas.
6. Desactiva sin borrar lo pesado y ocasional: abre Claude Code en la carpeta del proyecto, escribe /mcp y apaga el servidor con el toggle. Claude Code lo anota en disabledMcpServers de ese proyecto dentro de ~/.claude.json; en otra carpeta sigue prendido. Si prefieres hacerlo desde la terminal para varios proyectos, el repo trae ejemplos/desactivar-sin-borrar.mjs, que escribe la misma lista.
7. Vuelve a medir: claude mcp list, medidor y /context en una conversación nueva. Anota los números; la próxima poda se compara contra estos.

claude mcp list

cp ~/.claude.json ~/.claude.json.bak-$(date +%Y%m%d)

claude mcp remove hosting -s user && claude mcp remove crm-cuenta-b -s user && claude mcp remove crm-cuenta-c -s user

# Ver cómo está configurado hoy (comando, args, variables)
claude mcp get base-datos-app

# Quitarlo del scope global
claude mcp remove base-datos-app -s user

# Volver a agregarlo solo en el repo que lo usa
cd ~/proyectos/mi-app
claude mcp add base-datos-app --scope project \
  -e SUPABASE_ACCESS_TOKEN=${SUPABASE_ACCESS_TOKEN} \
  -- npx -y @supabase/mcp-server-supabase@latest --project-ref=<ref-del-proyecto>

# Verificar que quedó en .mcp.json y no en ~/.claude.json
cat .mcp.json

{
  "projects": {
    "/Users/tu-usuario/proyectos/contenido": {
      "disabledMcpServers": ["analisis-estatico", "diseno-decks", "video-gen"]
    }
  }
}

cd ~/proyectos/contenido && node ~/dieta-de-mcps/ejemplos/desactivar-sin-borrar.mjs analisis-estatico diseno-decks video-gen

Cuando llegue el día de la auditoría, lo prendes en /mcp, trabajas, y lo vuelves a apagar. La configuración, el OAuth y las variables siguen ahí. Tres cosas que confunden: disabledMcpServers no es una clave de settings.json (ahí no hace nada); tiene una hermana, enabledMcpServers, que solo sirve para prender servidores integrados que vienen apagados de fábrica; y enabledMcpjsonServers / disabledMcpjsonServers son otra cosa: controlan la aprobación de servidores definidos en el .mcp.json de un proyecto, no el encendido de los tuyos.

07 lo que no dice la tabla

Trampas que me costaron una tarde

• Dos MCPs de navegador se pisan. Tenía tres (Playwright, DevTools y Puppeteer). Claude alternaba entre ellos según el nombre de la herramienta que le sonaba, y cada uno abría su propio navegador. Quedaron dos con reparto explícito: uno para pruebas y capturas headless, otro cuando necesito la sesión real con cookies. Puppeteer se fue: solo Chromium y selectores CSS en vez de árbol de accesibilidad.
• Quitar una instancia también quita sus variables. Guarda los tokens en otro lado (un gestor de contraseñas o una memoria privada) antes del remove, y deja escrito el comando exacto de reinstalación. El mío para reinstalar una cuenta del CRM cabe en dos líneas y está en una nota, no en la cabeza.
• Un servidor lento pesa aunque no pese. Si un MCP tarda en arrancar o en responder, cada conversación lo espera. MCP_TIMEOUT controla el arranque, MCP_TOOL_TIMEOUT cada llamada, y hay un idle timeout por default (30 minutos para stdio, 5 para HTTP). Si lo desconectas 'por velocidad', anótalo como decisión para no reinstalarlo por reflejo.
• El resultado de una herramienta también es contexto. Por default se corta a 25,000 tokens (MAX_MCP_OUTPUT_TOKENS). Un MCP que devuelve listas enormes (contactos, logs) mete todo eso en la conversación. Pide siempre paginado o filtra en la propia llamada.
• Los conectores de claude.ai cuentan igual. Aparecen en /mcp junto con los tuyos y están al final de la precedencia. Si tienes un conector de diseño con 32 herramientas y cero llamadas, se apaga desde la configuración de conectores, no desde claude mcp.
• La atribución en /usage antes contaba mal: hasta la versión 2.1.222, tras una llamada a un servidor, todas las peticiones siguientes se le atribuían. Si tus números de atribución son de antes, no los uses para podar; vuelve a medir.
• Ni /compact ni cambiar de modelo adelgazan los MCPs. Compactar resume la conversación; la lista de herramientas se vuelve a inyectar completa en la siguiente petición. Cambiar a un modelo más barato cobra menos por el mismo peso, no lo quita. La única forma de que un servidor deje de costar es que no se conecte.

08 el otro lente

La misma lista, vista como riesgo

Cuando terminé el inventario me di cuenta de que era también un inventario de procesos que arrancan en mi máquina con mis credenciales cada vez que abro una conversación. Un MCP no es una extensión que lee: es un comando que se ejecuta, y que Claude puede invocar. Eso convierte la lista de la dieta en la lista de una auditoría, y conviene pasarla dos veces: una por peso y otra por riesgo.

• Un .mcp.json en un repo clonado es código que corre. Claude Code por eso pide aprobación servidor por servidor la primera vez, y en carpetas que no has marcado como confiables ignora cualquier auto-aprobación que venga en el repo. No te saltes eso: enableAllProjectMcpServers en true en tu configuración global convierte cualquier clon en un vector.
• Tokens en claro dentro de ~/.claude.json o .mcp.json. Es cómodo y es el hallazgo más común. Referencia una variable de entorno y que cada máquina la tenga en su shell.
• MCPs de shell o de sistema de archivos sin allowlist: le dan a Claude lo mismo que Bash pero sin pasar por tus permisos de Claude Code. Si ya tienes Bash con reglas, no necesitas otro camino sin reglas.
• En equipo, allowedMcpServers y deniedMcpServers en settings.json (o en configuración administrada) fijan qué servidores puede usar cada quien, por nombre, comando o URL. Es la dieta impuesta, y para un equipo es la única que se cumple.

npx ecc-agentshield scan

Para probar qué detecta, le armé una configuración con los tres errores de arriba: un servidor con token pegado en env, un MCP de shell y enableAllProjectMcpServers en true. Salió con calificación C, categoría de servidores MCP en 35 de 100, y las tres cosas marcadas como críticas con archivo, evidencia y corrección sugerida. Existe también un escáner de Snyk (agent-scan) que descubre agentes y MCPs de varias herramientas a la vez y busca inyección de prompts; no lo probé porque pide cuenta y token de Snyk, y aviso que, igual que mi medidor, conecta con los servidores y por lo tanto los ejecuta.