Cuando conectas demasiados servidores MCP a Claude Code, el problema suele aparecer como lentitud, compaction prematura, mala elección de herramientas o una conversación que se vuelve pesada después de leer logs, issues o datos de una base. No es solo una cuestión de cuántos servidores tienes. El contexto se consume por definiciones de herramientas, resultados devueltos, residuos de una sesión larga y una superficie de decisión con demasiadas opciones parecidas.
Vigente al 8 de julio de 2026: Claude Code documenta Tool Search como activado por defecto en rutas soportadas. Al iniciar la sesión solo se cargan nombres de herramientas e instrucciones de servidores; las herramientas usadas entran en contexto después. La misma documentación mantiene el aviso cuando la salida MCP supera 10.000 tokens y documenta un máximo por defecto de 25.000 tokens. Google Cloud Agent Platform, otro ANTHROPIC_BASE_URL, proxies, modelos sin tool_reference o servidores con alwaysLoad deben verificarse en tu propio entorno.
Si el síntoma no es una sola llamada enorme, sino CPU alta, presión de memoria, bloqueos, fallos de búsqueda o lentitud general, empieza con /doctor. Luego usa /context para ver qué consume la ventana, /compact o /clear para recuperar el hilo de trabajo y claude --safe-mode para comprobar si el problema viene de un plugin, servidor MCP o hook.
Empieza con esta tabla de presupuesto, no con otro ranking de servidores:
| Coste | Cómo se ve | Primer arreglo |
|---|---|---|
| Definiciones | Antes de llamar nada, Claude ya ve muchos nombres, descripciones y schemas. | Verifica Tool Search y desactiva o aplaza servidores que no tienen dueño en la tarea actual. |
| Resultados | Después de una llamada a logs, tablas, issues o base de datos, la sesión se vuelve pesada. | Resume, filtra, pagina, limita, usa cursor o devuelve handles. |
| Residuo de sesión | Errores viejos, planes descartados y reintentos siguen dentro del hilo. | Resume la decisión actual o abre una sesión limpia. |
| Superficie de decisión | Varios servidores exponen search, read, list o fetch con funciones parecidas. | Deja un dueño por workflow; divide o rediseña servidores amplios. |
El primer paso es concreto: ejecuta /mcp, revisa los servidores activos para esta tarea y marca cada uno como keep, defer, disable, split o redesign. Si lo que falta es un método repetible, usa una skill. Si lo que falta es acceso externo o una superficie de acción, conserva solo el MCP que posee ese workflow y comprime lo que devuelve.
Empieza con un presupuesto de contexto
Un servidor MCP no es solo un nombre dentro de settings. Una herramienta MCP tiene nombre, descripción, input schema, a veces output schema y contenido devuelto. Según el cliente y el modo de carga, parte de esa definición puede volverse visible para el modelo antes de que se invoque la herramienta.
Ese es el primer coste, pero no el único. Un solo MCP de base de datos puede saturar una conversación si devuelve miles de filas, traces completas, ficheros enteros o documentos completos. En cambio, varios servidores pequeños, con dueños claros y respuestas compactas, pueden ser aceptables.
La pregunta de diagnóstico no es “cuántos servidores tengo”, sino “qué está entrando en la ventana de trabajo ahora”. Si Claude Code se vuelve lento antes de cualquier llamada, mira definiciones, nombres repetidos y descripciones largas. Si empeora después de una llamada, mira el tamaño de la salida. Si se confunde tras muchos intentos, puede que el residuo del hilo sea el problema.
| Síntoma | Coste probable | Qué inspeccionar |
|---|---|---|
| Lento antes de llamar herramientas | definiciones o superficie de decisión | /mcp, claude mcp list, nombres duplicados, descripciones vagas |
| Bien hasta una llamada y luego confuso | carga de resultados | logs, tablas, filas, ficheros, traces, payloads API |
| Peor después de muchos arreglos | residuo de sesión | errores viejos, planes abandonados, salidas repetidas |
| No sabe qué herramienta usar | superficie de decisión | varios servidores con acciones parecidas |
Este presupuesto evita la reacción extrema de apagarlo todo. El objetivo es dejar menos decisiones activas, resultados más pequeños y ownership claro para cada acceso externo.
Tool Search ayuda, pero los resultados siguen contando
Tool Search actualiza el consejo clásico sobre MCP. En rutas soportadas por Claude Code está activado por defecto: al inicio se cargan nombres de herramientas e instrucciones de servidores, y las tool definitions se difieren hasta que hacen falta.
Eso ayuda, pero no es un cheque en blanco. Cuando Claude llama una herramienta, la respuesta sigue entrando en la conversación. Una tabla grande, un log entero, una captura HTML, un fichero completo o un payload JSON siguen consumiendo context window. Tool Search controla principalmente cuándo se ven las definiciones; no decide si una herramienta devuelve veinte filas o veinte mil.
Mantén separadas estas fronteras:
| Frontera | Qué puede ayudar Tool Search | Qué no arregla |
|---|---|---|
| Definiciones iniciales | Diferir discovery y schemas en rutas soportadas. | Nombres vagos, descripciones largas, dueños duplicados. |
| Resultados de herramientas | Nada por sí solo. | Logs, tablas, traces, ficheros y payloads grandes. |
| Historial de sesión | Nada por sí solo. | Hilos largos, reintentos, errores viejos, decisiones antiguas. |
Si usas ANTHROPIC_BASE_URL, Google Cloud Agent Platform, gateway compatible, proxy, ruta de modelo custom o un servidor con alwaysLoad, verifica el comportamiento en tu entorno. Después de comprobar Tool Search, ejecuta un workflow real. Si el dolor aparece antes de llamar herramientas, limpia servidores y definiciones. Si aparece después, el siguiente trabajo es compresión de output.
Keep, defer, disable, split, redesign
Un buen setup MCP no tiene que ser el más pequeño posible, pero sí debe ser explicable. Cada servidor activo debe completar la frase: “En esta tarea, este MCP posee ____”. Si la respuesta es “quizá lo use luego”, no debería estar activo en el hilo principal.
| Acción | Cuándo usarla | Ejemplo |
|---|---|---|
| Keep | Posee el workflow actual y no se reemplaza con ficheros locales, memory o skill. | GitHub MCP durante review de PR; docs MCP durante migración de framework. |
| Defer | Será útil después, pero no en esta fase. | Dejar QA de navegador para cuando la UI ya esté corregida. |
| Disable | No ayuda a esta tarea o duplica otro dueño activo. | Dos docs servers responden la misma pregunta de librería. |
| Split | Un servidor custom mezcla lecturas, escrituras, deploys y métricas sin relación clara. | Separar búsqueda read-only de issues y acciones de deploy. |
| Redesign | El servidor es necesario, pero la herramienta devuelve demasiado. | Cambiar dump_database por search_errors(service, time_range, limit). |
Usa /mcp dentro de Claude Code para ver lo activo. Usa claude mcp list, claude mcp get y claude mcp remove cuando necesites revisar la configuración desde terminal. La meta no es presumir de pocos servidores, sino dejar un conjunto activo que Claude pueda razonar sin ambigüedad.
Si todavía estás eligiendo qué instalar primero, consulta Best Claude Code MCP Servers. Este artículo aborda la fase posterior: el setup ya creció demasiado y hay que devolverlo a un tamaño de trabajo.
Comprime la salida antes de meterla en la conversación
Después de Tool Search, la compresión de salida suele importar más que el número de servidores. Una sola llamada de alto volumen puede hacer más daño que varios servidores silenciosos.
El aviso de 10.000 tokens, el máximo por defecto de 25.000 tokens y MAX_MCP_OUTPUT_TOKENS son barandillas, no el objetivo de diseño. La documentación también ofrece a autores de servidores anthropic/maxResultSizeChars y recomienda paginación para resultados grandes. La mejor respuesta no es “casi bajo el límite”; es la respuesta más pequeña que todavía permite decidir el siguiente paso.
| Regla | Mala forma | Mejor forma |
|---|---|---|
| Summary first | stream completo de logs | anomalías, conteos y tres líneas de ejemplo |
| Filtrar en origen | todas las filas | filas por servicio, tiempo, estado u owner |
| Paginar | una respuesta gigante | lote inicial y next_cursor |
| Límite por defecto | resultados ilimitados | limit: 20 con override explícito |
| Devolver handles | fichero o dataset completo | path, object id, job id, stored result |
| Vista previa antes de raw | payload raw inmediato | summary primero, raw solo si se pide |
El usuario también controla el coste. En vez de “lee la base de datos”, pregunta “top 20 errores de las últimas 24 horas, agrupados por servicio, con count y una trace de ejemplo”. En vez de “mira los logs”, pregunta “solo errores después del deploy fallido, sin health checks”. Cuanto más estrecha sea la pregunta, más fácil será para la herramienta devolver poco.
Diseña servidores MCP compactos
Si controlas el servidor MCP, el mayor arreglo no es activarlo o apagarlo. Es cambiar la forma de las herramientas. Un servidor compacto expone menos herramientas, con dueños claros, nombres específicos, descripciones cortas, defaults seguros y salida acotada.
Pasa este checklist:
- Una herramienta debe tener un trabajo. No mezcles issues, logs, métricas, ficheros y deploys.
- Nombra el resultado, no la implementación. search_recent_errors es mejor que query_system.
- La descripción debe ayudar a elegir la herramienta, no documentar todo tu backend.
- Usa mode: summary/detail/export en vez de tres herramientas casi iguales.
- Summary debe ser el default. Raw output debe requerir parámetro explícito.
- Datos grandes necesitan filtros, límites, paginación o cursors.
- Si el payload es grande, devuelve paths, ids o handles.
- Separa exploración read-only de acciones write o destructivas.
Una mala herramienta es get_everything_from_database(), porque devuelve rows, logs, traces y metadata sin foco. Una buena herramienta es search_errors(service, time_range, limit), porque devuelve summary, top rows y next_cursor. La segunda no solo gasta menos tokens; también deja claro qué preguntar después.
Mueve el trabajo pesado fuera del hilo principal
A veces la respuesta correcta no es “menos MCP”, sino “menos MCP dentro del main thread”. Los subagents de Claude Code pueden investigar datos ruidosos, probar hipótesis y devolver un resumen compacto. Así el hilo principal conserva la decisión.
Pero un subagent no es una frontera automática de compresión. Si hereda demasiadas herramientas, replica el mismo problema. Dale solo los servidores necesarios y pide findings, counts, paths, risks y next actions, no dumps completos.
Skills resuelven otro problema. Si falta método, checklist, referencia o secuencia de scripts, usa una skill. Si falta acceso externo o una acción, usa MCP. Si faltan ambos, separa roles: MCP da alcance y la skill da método. Las reglas duraderas deben ir a memory, no a un transcript cada vez más largo.
Limpieza MCP de 20 minutos
Cuando Claude Code se vuelve lento, se compacta demasiado pronto o pierde señal después de añadir MCP, haz este pase:
- Ejecuta /mcp y lista los servidores activos.
- Marca cada servidor como keep, defer, disable, split o redesign.
- Apaga o aplaza todo lo que no tenga current workflow owner.
- Repite una tarea pequeña y observa si el dolor aparece antes o después del tool call.
- Antes del tool call: mira definitions, names, descriptions y soporte de Tool Search.
- Después del tool call: mira output size, summary, filters, limits, cursors y handles.
- Tras muchos reintentos o auto-compaction repetida: resume la decisión actual y abre un hilo limpio.
- Si falta método, escribe una skill en vez de añadir otro servidor.
La métrica útil no es el número total de servidores configurados. Importa cuántas opciones activas debe considerar Claude para esta tarea y cuánto dato devuelven las herramientas al hilo. El setup más útil suele ser pequeño, aburrido y muy claro.
Preguntas frecuentes
¿Tool Search resuelve la sobrecarga de contexto MCP?
No por completo. Puede reducir definiciones iniciales en rutas soportadas, pero no comprime resultados, no limpia historial y no arregla herramientas custom demasiado amplias.
¿Por qué Claude Code se vuelve lento después de añadir MCP?
Separa la lentitud antes del tool call de la lentitud después del tool call. Antes de llamar herramientas, revisa servidores activos, definiciones, nombres parecidos, soporte real de Tool Search, plugins, hooks y carga local; ejecuta /doctor, mira /context y repite con claude --safe-mode. Después de llamar herramientas, casi siempre el problema es output demasiado grande, así que comprime con summary, filtros, límites, paginación o handles antes de meter el resultado en la conversación.
¿Cuántos servidores MCP debería activar?
No hay número universal. Activa los que poseen el workflow actual. Un solo servidor de base de datos que devuelve dumps enormes puede ser peor que varios servidores pequeños y claros.
¿Qué hago si el output MCP es enorme?
Comprime en origen: summaries, filtros, paginación, límites, cursors, paths, ids o handles. Raw data debe ser una petición explícita.
¿Cuándo usar una skill en lugar de MCP?
Usa skill cuando falta método repetible. Usa MCP cuando Claude necesita acceso externo o una acción. Si el workflow necesita ambos, deja que MCP aporte acceso y la skill aporte disciplina.
¿Cómo diseño un servidor MCP compacto?
Con menos herramientas, dueños claros, descripciones cortas, salidas acotadas, filtros, limits, cursors, summary first y separación read/write. Evita herramientas que devuelven todo porque pueden.
¿Apagar todos los MCP es lo más seguro?
Solo como diagnóstico. La solución duradera es un active set compacto: conserva el acceso crítico, aplaza lo demás y rediseña las herramientas que devuelven demasiado.
La sobrecarga de contexto en Claude Code por MCP se arregla cuando dejas de coleccionar integraciones y empiezas a presupuestar memoria de trabajo. Conserva solo el acceso que posee el workflow actual, comprime resultados antes de meterlos en conversación, mueve el método a skills y aísla exploraciones ruidosas. El setup que Claude puede razonar mejor suele ser el más pequeño que todavía hace el trabajo.