Servidores MCP en Claude Code: medir el coste antes de podar

Cuando algo salía caro en tokens al conectar servidores MCP, la respuesta técnica solía ser "desconecta lo que no usas". Desde que Tool Search quedó activado por defecto en Claude Code, la pregunta cambió de sitio: el coste depende menos de cuántos servidores tienes conectados que de si algo está forzando la carga completa de sus esquemas por delante.

Mide: qué te cuesta de verdad cada servidor MCP conectado

Para ver cuánto gastan tus servidores MCP en Claude Code hoy, corre /context en una sesión activa: el desglose separa system prompt, herramientas del sistema, herramientas MCP cargadas, herramientas MCP diferidas, archivos de memoria (CLAUDE.md y auto memory) y mensajes, con tokens y porcentaje por categoría, y permite ver el coste de una herramienta individual (por ejemplo, una acción de Gmail o de un navegador puede rondar unos cientos de tokens ella sola). El comando /mcp complementa esto mostrando el estado de cada servidor —conectado, pendiente de aprobación, pendiente de autenticación o fallido— y cuántas herramientas expone cada uno; no muestra coste en tokens, que es terreno exclusivo de /context, pero sirve para desconectar un servidor en una sesión concreta sin tocar la configuración global.

Una advertencia puntual, no una regla general: a comienzos de 2026 se documentó un caso concreto —un servidor de más de 60 herramientas— donde /context llegó a reportar ~45.000 tokens frente a un gasto real medido de ~15.000, porque el cálculo sumaba instrucciones compartidas por herramienta en vez de una vez por servidor. Anthropic corrigió ese cálculo en una versión posterior, así que trátalo como un motivo para verificar la cifra en tu versión actual, no como una advertencia vigente sobre /context en general.

Para llevar ese coste a euros por sesión en tiempo real, en vez de tokens sueltos en /context, ese es terreno de la statusline: cómo configurarla se cubre en el control de tokens y coste desde la statusline de Claude Code; aquí el foco es diagnosticar y podar el origen MCP del gasto, no monitorizarlo en dinero.

Diagnostica: de dónde sale el sobrecoste

En Claude Code, Tool Search viene activado por defecto: al arrancar la sesión solo se cargan los nombres de las herramientas de cada servidor MCP y las instrucciones que declara el servidor, mientras los esquemas completos —parámetros, descripciones largas— quedan diferidos hasta que Claude necesita una herramienta concreta y la busca. La documentación oficial lo resume así: solo las herramientas que Claude realmente usa entran al contexto, y desde la perspectiva del usuario los servidores MCP funcionan igual que siempre. El coste por turno ya no crece de forma lineal con cada servidor conectado, salvo que algo rompa ese diferimiento.

El escenario caro —esquemas completos cargados por delante, se usen o no— aparece cuando algo desactiva ese diferimiento: ENABLE_TOOL_SEARCH=false explícito, un proxy de ANTHROPIC_BASE_URL que no reenvía los bloques tool_reference, un despliegue en Microsoft Foundry sobre Azure que rechaza tool search del lado del servidor, un modelo anterior a la generación 4.5 en algunas plataformas cloud, o un servidor marcado con alwaysLoad: true para que sus herramientas estén siempre visibles sin paso de búsqueda. Ese último caso conviene usarlo con cuidado: cada herramienta marcada así vuelve a pagar el coste completo en cada arranque de sesión, exactamente lo que el resto del mecanismo evita.

Ese escenario sin diferir es justo el que ilustra la propia documentación de Tool Search de Anthropic con un stack de referencia de GitHub, Slack, Sentry, Grafana y Splunk: cerca de 55.000 tokens en definiciones antes de que Claude haga ningún trabajo. Por separado, con otro stack y otra metodología —Playwright, Gmail y dos servidores más pequeños—, una medición independiente registró unos 7.077 tokens en total, y la misma fuente documenta casos de stacks más pesados por encima de 66.000 tokens: una fracción notable en Claude Haiku 4.5, que mantiene una ventana de 200k, pero comparativamente menor en Claude Opus 5 o Sonnet 5, que hoy manejan hasta 1M de tokens de contexto. Son dos puntos medidos en contextos distintos, no el antes y el después de un mismo stack: al proceder de stacks y metodologías distintos, esas cifras no aíslan una causa única: pesan tanto si el diferimiento de Tool Search está realmente activo para tu configuración como cuántos esquemas expone cada servidor y cuánto ocupan.

Poda: qué servidor sobrevive

Tener Tool Search activo resuelve la parte mecánica del coste, pero no decide qué servidor merece seguir conectado: eso sigue siendo una decisión de criterio, no de configuración. En equipos que auditan esto en serio, el número converge hacia algo pequeño: es habitual pasar de ocho, doce o quince servidores activados "por si acaso" a un puñado que de verdad se usa cada semana. Cuatro criterios separan lo que sobrevive de lo que se desconecta:

• Uso semanal sin necesidad de recordarlo: si tienes que pensar activamente en que existe para usarlo, probablemente no gana su sitio en el contexto de cada turno.
• No lo resuelve ya Claude Code de forma nativa: Bash, Read, Grep y Edit cubren una parte grande de lo que un MCP genérico promete antes de necesitar una integración dedicada.
• El coste en tokens medido con /context se justifica frente a la frecuencia real de uso, no frente a la frecuencia que crees que tiene.
• Sigue mantenido y sin vulnerabilidades conocidas sin parchear. No es un criterio teórico: el servidor de referencia de PostgreSQL de Anthropic está archivado desde mayo de 2025 y tiene una inyección SQL documentada y sin parchear que permite saltarse su propio modo de solo lectura apilando sentencias tras un COMMIT; sigue recibiendo miles de descargas semanales pese a eso.

Con esos criterios aplicados hoy, tres de los cuatro servidores que solían recomendarse para un stack mínimo de desarrollo siguen vigentes sin cambios: el MCP oficial de GitHub para PRs, issues y búsquedas en el repositorio; Context7 para documentación de librerías actualizada sin necesidad de clave de API; y Playwright MCP de Microsoft para automatización de navegador y pruebas E2E. El cuarto cambia: en vez del servidor oficial de PostgreSQL archivado, la alternativa mantenida es Postgres MCP Pro, que fuerza un modo restringido con parseo de SQL para impedir exactamente el tipo de bypass documentado en el servidor oficial, además de análisis de índices y planes de ejecución.

Optimiza lo que queda: Tool Search, Code Mode, perfiles y gateways

Con esos cuatro servidores ya decididos, todavía queda margen para bajar el coste sin tocar la lista. David Soria Parra, co-creador del protocolo MCP en Anthropic, describe el mismo mecanismo desde el lado del modelo: "en algunos casos, solo listar las herramientas disponibles puede consumir más del 20% de la ventana de contexto", y lo resuelve con progressive discovery —no volcar de golpe las 20, 50 o 100 herramientas de un servidor, sino buscarlas y cargarlas solo cuando hacen falta—, la misma idea detrás de Tool Search, que en el caso de referencia de 55.000 tokens de Anthropic reduce el consumo en más de un 85% cargando solo las 3-5 herramientas relevantes por petición. Con eso activo por defecto, lo que queda bajo tu control es no desactivarlo sin darte cuenta y usar alwaysLoad con criterio: resérvalo para las pocas herramientas que de verdad necesitas en cada turno, porque cada una marcada así vuelve a pagar el coste completo que el resto del mecanismo evita.

Code Mode ataca el mismo problema desde otro ángulo: en vez de inyectar el esquema de cada herramienta, el modelo escribe código que llama a las herramientas como funciones de un SDK tipado. Cloudflare, que acuñó el nombre, reporta el caso extremo de su propia API de más de 2.500 endpoints: de 1,17 millones de tokens a unos 1.000, un footprint que no crece con el número de endpoints disponibles. En catálogos MCP más típicos el ahorro escala con el tamaño del stack en vez de ser un número fijo: un benchmark de Bifrost sobre tres configuraciones reales muestra una reducción del 58% con 96 herramientas en 6 servidores, del 84,5% con 251 herramientas en 11 servidores, y del 92,8% con 508 herramientas en 16 servidores —la cifra más alta solo aparece a esa escala, no es garantía en un stack de cuatro servidores.

Para quien alterna entre tipos de trabajo muy distintos, tiene sentido no cargar siempre el mismo catálogo: un perfil dev con GitHub y Context7, uno de review centrado en Playwright y GitHub, y uno de infra con Postgres MCP Pro, cada uno en su propia configuración, evita pagar el coste de herramientas irrelevantes para la tarea del día. Y cuando el problema es agregar varios servidores para todo un equipo, un gateway MCP con filtrado hace ese trabajo de forma centralizada: Bifrost filtra herramientas por cliente, request o clave virtual además de ofrecer su propio Code Mode, mientras que MintMCP se orienta más a gobernanza empresarial (SSO, RBAC, auditoría) que a la reducción de tokens en sí misma —conviene no confundir ambos objetivos al elegir gateway.

Ninguna de estas técnicas compensa si el stack ya es pequeño: la propia documentación de Tool Search recomienda quedarse con la llamada estándar de herramientas cuando hay menos de 10 disponibles, se usan todas en cada request, o sus definiciones ya son ligeras. La auditoría empieza por medir, sigue por podar, y solo entonces vale la pena invertir esfuerzo en las capas de optimización que quedan.