Cuándo NO usar tu MCP (aunque lo tengas a la mano)

Tengo un agente en producción que se llama Ghosty. Atiende WhatsApp, cotiza, y desde hace rato tiene un MCP de base de datos conectado. Esta tarde le pedí algo aparentemente simple: "toma este Excel de 1,259 clientes y pásalos a la DB del catálogo, en una colección nueva".

26 minutos después seguía pensando. Cero filas insertadas.

Lo que estaba haciendo

Ghosty armó un plan razonable: dividir los 1,259 registros en 26 batches de ~50 filas, prepararlos como JSON en /tmp, y "ejecutarlos en paralelo" llamando al MCP db_query con cada batch.

Cada llamada al MCP se ve más o menos así desde su perspectiva:

Inocente, ¿no? El problema es que cada uno de esos tool_use y tool_result vive dentro del contexto del agente. 28 KB de args × 26 batches = ~728 KB solo de argumentos, sin contar los resultados, sin contar la narrativa que el agente escribe entre llamada y llamada para "decidir qué sigue".

Resultado: el autocompact de Claude se dispara antes de terminar el primer round. Se pierde el hilo. El agente reinicia, regenera los /tmp/batch_*.json, vuelve a intentar, vuelve a compactarse. Loop infinito. En 26 minutos pasó tres veces por autocompact y no escribió una sola fila a la DB.

La regla

Si la respuesta del tool no necesita razonamiento entre cada call, no debe pasar por el contexto del agente.

El MCP es buenísimo para queries puntuales:

• "¿Cuántos productos hay activos?"
• "Dame los 5 clientes que más han comprado este mes."
• "Inserta este pedido nuevo."

Esos casos necesitan que el agente lea la respuesta, razone, y decida qué hacer con ella. El contexto se gana porque hay una decisión que tomar.

Los bulk ops son lo opuesto: 1,259 inserts idénticos, sin decisiones intermedias. Hacerlos pasar uno por uno por el cerebro del agente es como pedirle a un cirujano que cuente los granos de arroz en una bolsa: técnicamente puede, pero estás pagando talento caro para una tarea de bucle.

La alternativa

El mismo MCP de EasyBits que Ghosty tiene conectado expone un endpoint HTTP por debajo. Lo correcto es:

Donde el script:

1. Lee el .xlsx desde disco.
2. Itera fila por fila.
3. Hace fetch directo a la API con el EASYBITS_API_KEY que ya está en el env del contenedor.
4. Imprime OK: 1259 filas al final.

¿Qué ve el agente?

Impacto en contexto: ~80 bytes. Un solo tool_use. El bucle de 1,259 inserts vive en un proceso aparte que ni se entera de Claude.

Generalizando

El MCP no es la herramienta del agente — es una herramienta del agente. La distinción importa cuando el costo es contexto, que es lo único que realmente escasea cuando armas flujos largos.

Mi regla mental para decidir dónde vive un bucle:

La heurística rápida: si pudieras escribir el bucle como un for sin if's intermedios, no necesita al agente.

Lo que cambié en Ghosty

Le agregué tres bullets a su CLAUDE.md (la memoria persistente del agente para ese grupo):

Tres líneas. Le toma 80 tokens leerlas al boot, le ahorra varios cientos de miles cuando aplica.

Si te interesa ver cómo estos patrones se ven en vivo —agentes en producción, MCPs, contexto que se va y se viene— en el canal de YouTube subo los episodios donde se ve la cocina por dentro.

Cierre

Cuando hablamos de "engineering" para agentes, casi siempre pensamos en prompts, herramientas, system messages. Pero la batalla real es por el contexto: qué entra, qué se queda afuera, qué pasa por un proceso paralelo.

El MCP te da acceso a una API. Eso no significa que el agente sea el lugar correcto para correrla.

Abrazo. bliss.

*_