Dale a tu agente una shell, no un protocolo

Cada MCP server que instalas es un impuesto silencioso sobre todas las conversaciones que tengas después. Lo pagas aunque la herramienta nunca se llame.

El instinto tiene sentido. Aparece una capacidad nueva. Alguien publica un MCP server para ella. Instalas, configuras, olvidas. Repites hasta que tu lista de herramientas tiene catorce entradas y cada sesión arranca quemando dieciocho mil tokens en schemas que el modelo quizá ni use ese día.

Uso un agente de IA para código todos los días. Construí solo una fintech cripto de 13 apps con agentes de IA en 70 días. En ese sprint aprendí una cosa sobre MCP y CLI más rápido que cualquier otra: el protocolo no es el cuello de botella que el ecosistema finge que es. La shell resuelve la mayor parte más barato, y solo notas la diferencia cuando empiezas a mirar a dónde se van los tokens.

MCP suma tokens antes de que escribas nada

La mecánica es esta. Cuando tu agente arranca, cada MCP server registrado empuja los schemas de sus herramientas a la context window. Nada de lazy loading. Nada bajo demanda. Todos, de entrada, en cada sesión, los uses hoy o no.

Un MCP server popular puede consumir entre 13.000 y 18.000 tokens de contexto antes de que escribas un solo carácter. Eso es más o menos entre siete y nueve por ciento de una ventana de 200k, perdido. Corre tres o cuatro MCP servers y la cuenta se acumula. Gastaste una parte importante de todo tu presupuesto de contexto en definiciones de schema para capacidades que quizá nunca corran en esa sesión.

Una herramienta de CLI no cuesta nada de eso. La invocas vía bash. El modelo paga cero tokens por saber que existe. Cuando necesita saber qué flags acepta, corre <tool> --help y el schema aparece bajo demanda, una vez, en el momento de usarla. Eso es progressive disclosure. MCP es lo opuesto: carga todo por adelantado, usa una fracción y paga por todo en cada turno.

El impuesto de tokens por adelantado

13k-18k

tokens por MCP servercargados en cada sesión, se usen o no

0

tokens para CLI vía bashhasta que la herramienta realmente se invoca

7-9%

de la ventana consumidapor server popular en un contexto de 200k

La asimetría pesa más en sesiones largas o repetidas. El modelo relee el contexto completo en cada turno. Esos 18k tokens de schema no son un costo único de arranque. Son un costo por turno, en cada sesión, se llame la herramienta o no. En una semana de uso diario, pagaste por ese server decenas de veces en sesiones en las que nunca corrió.

–help es un schema perfectamente válido

La gente trata la CLI como plan B para cuando no hay un MCP server. Ese planteo está al revés. Una herramienta de CLI con una salida de --help legible es, en la mayoría de los casos, una mejor interfaz para un agente, no una peor.

La razón: el schema de un MCP server es estático, lo escribe una vez el autor del server. Si es verboso o redundante, pagas esa verbosidad en cada sesión. El --help de una CLI también es su schema, pero el agente lo busca solo cuando es relevante y solo para el subcomando que necesita. El modelo puede correr <tool> --help <subcommand> para bajar exactamente al nivel de detalle correcto. Ningún MCP server hace eso por sí solo.

Esto es lo que harness engineering llama progressive disclosure aplicada en la capa de herramientas: darle menos al modelo por adelantado y dejar que pida exactamente lo que necesita, en el momento en que lo necesita.

✗

MCP server

1. 01Carga todos los schemas de herramientas en el contexto al iniciar la sesión
2. 02Costo de tokens fijo por server por sesión, se use o no
3. 03Schema estático, escrito una vez por el autor del server
4. 04Varios servers multiplican el costo por adelantado de forma lineal
5. 05Opaco: el modelo lee schemas que tú no escribiste

✓

CLI vía bash

1. 01Cero tokens hasta que la herramienta realmente se invoca
2. 02Costo de tokens proporcional al uso real
3. 03--help es el schema, cargado solo bajo demanda
4. 04Progressive disclosure: baja a los subcomandos según haga falta
5. 05Transparente: lees exactamente lo que lee el modelo

La postura de Pi: cuatro herramientas y una shell

Pi, el coding agent open source de Mario Zechner, viene con cero MCP servers por defecto. Le da al modelo cuatro herramientas: read, write, edit y bash. Esa es toda la superficie de herramientas.

Es una decisión de diseño deliberada, no un descuido. El argumento de Zechner es que los harnesses más populares se volvieron opacos e inestables porque sus listas de herramientas y el contexto inyectado cambiaban a espaldas del usuario. El modelo es lo bastante capaz por sí solo. Cada herramienta que agregas es una apuesta a que se va a usar lo suficiente como para justificar el overhead. La mayoría de esas apuestas no se cumplen.

Bash es la válvula de escape que vuelve innecesario el resto. ¿Necesitas git? Bash. ¿Necesitas grep, jq, curl o algo para transformar JSON? Bash. Cualquier herramienta de CLI hecha en los últimos cincuenta años funciona a través de él de inmediato, con costo cero de integración y cero overhead de schema. La shell es una interfaz de herramientas increíblemente capaz. La apuesta de Pi es que cubre la gran mayoría de lo que se instala con MCP servers, a una fracción del costo de contexto.

Lee el desglose del costo de tokens para la contabilidad completa de a dónde van los tokens entre la salida de las herramientas, el historial de la conversación y volver a explicar todo en cada sesión. El overhead de schema de MCP entra en la capa de salida de herramientas de ese mismo modelo.

Cuándo MCP realmente se justifica

Nada de esto es un argumento de que MCP esté mal. El protocolo resuelve problemas reales en situaciones específicas, y esas situaciones existen.

MCP se justifica cuando una capacidad no tiene un equivalente limpio en CLI. Algunas APIs requieren flujos OAuth, sesiones con estado o navegación estructurada de recursos, cosas que las llamadas vía bash manejan mal. Un MCP server bien hecho para un sistema interno autenticado es un intercambio legítimo. Pagas el costo del schema y obtienes algo que no podrías replicar limpiamente con un comando de shell. Es un trato justo.

MCP también justifica su overhead cuando usas la herramienta en la mayoría de las sesiones. Si abres tu agente y consultas una base de datos en nueve de cada diez sesiones, el costo del schema por adelantado se amortiza con uso real. La relación tokens por valor se sostiene. Si la consultas en una de cada veinte sesiones, pagaste diecinueve veces por nada, y una llamada vía bash en la única sesión en que la necesitaste te habría costado menos en total.

La recomendación no es quitar todos los MCP servers. Es ser intencional sobre cuáles quedan registrados. Quédate con los que usas en la mayoría de las sesiones, o con los que cubren capacidades sin camino por CLI. Corta el resto.

La auditoría

Una auditoría rápida de tu setup de MCP toma diez minutos y se paga de inmediato.

Auditoría de MCP

• ✓Obligatorio:
  Lista todos los MCP servers registrados hoy en tu agente
• ✓Obligatorio:
  Revisa en tus últimas 20 sesiones qué servers se llamaron realmente
• ✓Obligatorio:
  Quédate con los servers llamados en más de la mitad de tus sesiones recientes
• ✓Obligatorio:
  Para los servers que casi no se llaman: revisa si existe un equivalente en CLI
• ✓Obligatorio:
  Reemplaza los servers con equivalente en CLI por una llamada vía bash
• •Opcional:
  Quédate con los MCP servers que cubren capacidades sin camino por CLI
• ✗Anti-pattern:
  Instalar servers por las dudas para cubrir cualquier edge case posible
• ✗Anti-pattern:
  Agregar un server sin revisar antes su costo en tokens

La auditoría es un arreglo de una sola vez que rinde para siempre. Cuando cortas un server, dejas de pagar su overhead en cada turno de cada sesión futura. El retorno no es lineal. Es permanente.

La regla de decisión

MCP o CLI no es un debate filosófico. Es una cuestión de presupuesto de tokens con dos entradas: ¿con qué frecuencia usas la capacidad?, y ¿existe un equivalente en CLI?

Si la capacidad es clave en la mayoría de las sesiones y no tiene un camino limpio por CLI, instala el MCP server. Acepta el overhead como el costo de una brecha real. Si la capacidad es ocasional, o si una CLI la resuelve, usa bash. El modelo averigua los flags. Siempre lo hizo.

El principio de fondo es el mismo que hace funcionar el harness minimalista de Pi: menos suposiciones sobre lo que el modelo va a necesitar, y menor costo para las suposiciones que resulten equivocadas. Dale a tu agente una shell. La mayor parte de lo que buscas en MCP, la shell ya lo resuelve.

Preguntas frecuentes

¿Importa MCP vs CLI si tengo una context window grande?+

Sí. Una ventana más grande no hace gratis el desperdicio. Solo hace más fácil ignorarlo.

Un server que consume entre 13k y 18k tokens por sesión los sigue consumiendo sin importar el tamaño total de la ventana. En una ventana de 200k, eso es un nueve por ciento. Y el costo tampoco es un cargo único de arranque: el modelo relee el contexto completo en cada turno, así que vuelves a pagar esos tokens de schema en cada paso de cada tarea.

La calidad del contexto importa tanto como la cantidad. Llenar una ventana grande con schemas de herramientas que el modelo no va a usar le quita espacio al contexto de trabajo real: la spec, el diff, el mensaje de error que el modelo necesita para arreglar el bug ahora mismo. Una ventana más grande te deja ignorar el problema por más tiempo; no lo resuelve.

¿Puedo usar MCP y CLI en el mismo agente?+

Sí, y la mayoría de los setups en producción lo hacen. El objetivo no es prohibir MCP. Es ser intencional sobre qué servers quedan registrados. Deja MCP para las capacidades que usas en la mayoría de las sesiones, o para las que no tienen equivalente en CLI. Manda todo lo demás por bash. Los dos enfoques no se excluyen. La auditoría se trata de ser deliberado en lugar de acumular servers por reflejo.

¿Cómo estimo el costo en tokens de un MCP server antes de instalarlo?+

Revisa cuántas herramientas registra el server y qué tan verbosas son sus descripciones. Cada definición de herramienta suma al conteo de tokens por adelantado. Un server que registra ocho herramientas con schemas de parámetros detallados va a costar más que uno con tres herramientas simples.

El método práctico: instala el server en una sesión de prueba y pídele a tu agente que muestre su lista completa de herramientas o el system prompt. Cuenta esos tokens. Una estimación gruesa es de 200 a 500 tokens por definición de herramienta, más los schemas de recursos. Un server con diez herramientas verbosas llega fácil al rango de 13k a 18k antes de que hagas nada.

¿Qué significa 'progressive disclosure' para las herramientas de agentes de IA?+

Progressive disclosure significa que el agente carga información sobre una herramienta solo cuando necesita usarla, no antes. La CLI lo logra de forma natural: el modelo no tiene schema de una herramienta de CLI hasta que corre --help, que carga solo la documentación relevante en ese momento. MCP es lo inverso: todos los schemas se cargan al iniciar la sesión, llame o no el modelo a esas herramientas. Progressive disclosure mantiene la context window reservada para el trabajo real, en lugar de llenarla de antemano con definiciones de capacidades que quizá no importen en esa sesión.

¿Cortar MCP servers afecta lo que mi agente puede hacer?+

Solo en las sesiones específicas en las que los habrías usado, e incluso entonces solo si no existe un camino por CLI. Si cortas un server y lo reemplazas con llamadas vía bash, el agente puede seguir haciendo todo lo que hacía antes, con comandos de shell en lugar del protocolo. Para tareas de desarrollo estándar, la diferencia práctica es invisible.

La excepción real son las capacidades sin camino por CLI: APIs basadas en OAuth sin alternativa por token, sistemas de recursos con estado o navegación estructurada de datos que requeriría construir una herramienta propia considerable para replicarla. Deja MCP para esas. Para todo lo demás, bash es más rápido de configurar y más barato de correr en cada turno.

¿El enfoque sin MCP es práctico para equipos, y no solo para quien construye solo?+

Para equipos chicos que hacen desarrollo estándar, es muy práctico. Bash cubre la gran mayoría de las operaciones comunes sin ningún setup extra, y la ventaja de la transparencia es mayor en equipo, porque todos pueden leer exactamente lo que recibe el agente.

Los equipos más grandes, con infraestructura compartida, tienen más casos legítimos para MCP: acceso autenticado a sistemas internos, recursos estructurados que son incómodos por CLI pura o capacidades que requieren estado persistente entre llamadas a herramientas. El argumento no es que cuatro herramientas sean la respuesta para cualquier equipo a cualquier escala. Es que el instinto por defecto de agregar servers merece más escrutinio antes de instalar del que suele recibir.