Contexto MCP en Claude Code: ¿mantener la herramienta o ejecutar un comando?
Un método reversible para estimar el efecto de un servidor MCP en el contexto de Claude Code sin inventar un ahorro fijo de tokens.
Índice
Contexto MCP en Claude Code: ¿mantener la herramienta o ejecutar un comando?
Un servidor MCP sirve cuando Claude Code necesita un sistema fuera del directorio de trabajo: tickets, una API interna, una base de datos o datos de observabilidad. También incorpora a la sesión nombres de herramientas, descripciones, esquemas de entrada y acciones posibles. Por eso la pregunta debe resolverse para una tarea concreta: ¿hace falta acceso externo repetido o basta una acción local corta?
No desactives todos los servidores por una respuesta larga. Elige una tarea breve, repetible y sin efecto externo, mídela y limita un solo servidor. Los turnos, las llamadas que de verdad hicieron falta y el resultado verificable dicen más que la sensación de que el contexto creció.
Si pruebas un flujo de API separado para Claude Code, abre la guía actual de BetterToken, ejecuta dos veces el mismo prompt con el mismo modelo y compara enseguida en Dashboard la hora, el modelo, el estado, los tokens de input/output/cache y el consumo mostrado. Así una sospecha sobre contexto sobrante se convierte en una prueba A/B verificable. Empieza con una tarea read-only y no guardes la clave API en el repositorio.
De dónde puede salir el contexto extra
La documentación de MCP para Claude Code define los servidores como conexiones a herramientas y datos externos. Para el modelo no cuenta solo el resultado de una llamada: antes de llamarla debe considerar el propósito de la herramienta, sus parámetros y límites. Un servidor amplio con muchas herramientas sin filtrar aumenta esa superficie.
No existe, sin embargo, un «coste de tokens MCP» fijo. Depende del servidor, las herramientas activadas, el prompt, el modelo, el historial y lo que devuelva cada herramienta. Separa estas observaciones:
- se anuncian muchos esquemas aunque ninguno sea útil para la tarea;
- una llamada devuelve un resultado largo que los turnos posteriores deben leer;
- un resultado demasiado amplio provoca búsquedas o lecturas repetidas;
- al retirar una herramienta se pierde una comprobación externa y el agente empieza a adivinar.
Ninguna prueba por sí sola explica todos los tokens. El tamaño del repositorio y el historial de la sesión también cambian la comparación.
Elegir la interfaz útil más pequeña
| Situación | Empieza con | Motivo |
|---|---|---|
| Leer y actualizar tickets repetidamente | MCP estrecho del gestor | Hace falta un modelo de objetos externo y repetible. |
| Consultar una vez un estado local | comando local o archivo de estado | El dato ya está en el workspace. |
| Leer una API interna en muchas tareas | herramientas MCP read-only con alcance reducido | El acceso puede ser repetible y revisable. |
| Abrir un documento del repositorio | buscar y leer el archivo | No hace falta un catálogo externo de herramientas. |
| Cambiar un sistema externo | revisión manual o read-only primero | Siguen siendo necesarias autorización, idempotencia y comprobación. |
Deciden la frecuencia y el límite de los datos, no la popularidad del servidor. Para un único estado de Git suele bastar un comando. Un comando no sustituye una interfaz segura cuando se necesitan varias operaciones relacionadas sobre datos externos con esquema definido.
Medir una tarea comparable
Escoge una tarea sin efecto externo: encontrar el responsable de un archivo cambiado, revisar el estado local o leer elementos abiertos en un proyecto de prueba. No compares tareas distintas ni saques una regla general de una sesión excepcionalmente larga.
- Anota el prompt, el directorio y el resultado esperado. Por ejemplo: «muestra los archivos modificados y propone un siguiente paso sin cambiar el repositorio».
- Ejecuta la tarea con el perfil MCP actual. Guarda solo observaciones seguras: turnos, herramientas usadas, resultado y hora. No copies la API key,
.envni una salida sensible completa. - Desactiva exactamente un servidor en
/mcp. La interfaz conserva su configuración y lo marca como disabled. Cierra la sesión, abre una sesión nueva, comprueba en/mcpque sigue listado pero no conectado y repite el mismo prompt. - Compara primero el hecho obtenido. ¿El agente logró el mismo dato necesario o sustituyó una llamada útil por una conjetura?
- Vuelve a activar el servidor desde
/mcp, abre otra sesión nueva y comprueba su estado. Restáuralo si su ausencia obliga a copiar datos manualmente o elimina una validación importante. Conserva la configuración pequeña si mantiene el resultado y reduce llamadas innecesarias.
La sesión nueva importa porque la anterior ya contiene resultados de herramientas. Esta prueba no mide el rendimiento universal de Claude Code; ayuda a decidir sobre tu flujo habitual.
Un comando realmente equivalente
No sustituyas MCP por cualquier comando. Para el mismo hecho local, este comando read-only puede ser comparable:
git status --shortEn las dos variantes pide solo la lista de archivos modificados y un siguiente paso sin escritura. El prompt y la lista esperada deben ser iguales. Verifica primero la lista; después, turnos, llamadas y tokens. Si MCP aportaba un hecho externo que git status no contiene, no hay equivalencia: conserva un MCP read-only estrecho o documenta un comando para ese mismo sistema.
Reducir superficie y riesgo antes de eliminar
Un servidor puede ofrecer muchos comandos aunque el proyecto use regularmente solo uno o dos. Reduce primero la superficie:
- activa solo herramientas read-only en la primera prueba;
- desactiva integraciones que el repositorio no utiliza;
- separa perfiles de desarrollo, soporte y administración;
- no incluyas secretos, logs largos ni historial de conversación en la descripción de una herramienta;
- para una operación rara, deja un comando corto documentado con el resultado esperado.
MCP puede leer datos externos o iniciar acciones; su configuración no reemplaza comprobar el scope ni revisar el resultado de la llamada. Una respuesta del modelo no demuestra que una operación externa haya terminado correctamente.
Comparar uso y coste sin falsear datos
Para una prueba de API, configura Claude Code con tu propia clave BetterToken siguiendo la guía de Claude Code. BetterToken es acceso API separado, no una suscripción de Claude. La clave se crea y gestiona en la cuenta del usuario; no debe aparecer en el repositorio, un handoff ni las notas del experimento.
El Dashboard de BetterToken muestra hora, modelo, estado y tokens de input, output y cache con el consumo asociado. Anota por ejecución model, fecha y hora, input, output, cache, coste mostrado y turnos. Mantén el mismo modelo y prompt para los dos casos.
Si Dashboard muestra el coste, calcula diferencia observada = coste con MCP − coste sin MCP. Si solo se ven tokens, abre antes la página de precios actual, anota fecha, modelo y reglas de cache y usa coste = input/1.000.000 × Pinput + output/1.000.000 × Poutput + cache/1.000.000 × Pcache únicamente cuando el cache tenga precio separado. Un campo vacío o dudoso no es cero y no se reutilizan tarifas antiguas. La diferencia describe dos ejecuciones observadas, no una tarifa fija de MCP.
Revisar la decisión en el orden correcto
- Hecho externo requerido. El sustituto debe obtener el ticket, estado, registro de API o documento necesario, no adivinarlo.
- Corrección y frontera de acceso. Compara el resultado esperado y mantén la prueba read-only, sin un secreto nuevo ni un scope más amplio.
- Validación conservada. Confirma que el sustituto no quitó una comprobación que hacía la herramienta; una respuesta de modelo no es prueba externa.
- Solo entonces, el coste. Compara turnos, llamadas, tokens input/output/cache y coste de Dashboard con el mismo prompt en una sesión nueva.
Si fallan los tres primeros puntos, usar menos tokens no mejora el flujo: las tareas ya no son iguales o una persona asumió la validación perdida.
Cuándo revisar la elección
Restaura un servidor si retirarlo impide obtener un hecho externo obligatorio, produce propuestas no verificadas o obliga a copiar los mismos datos en cada prompt. Mantén el perfil más reducido si el resultado requerido sigue validado con menos llamadas inútiles. Un buen perfil MCP suele ser discreto: cada herramienta activa tiene un trabajo repetido; para lo demás existe un comando corto, un documento o una comprobación manual.
