Code execution con MCP: cómo recortar hasta un 98% de tokens en tus agentes
Si tu agente conecta con MCP y notas que la latencia y el coste se disparan a medida que sumas servidores, el problema casi nunca es el modelo: es la forma en que le entregas las herramientas. La respuesta corta: en lugar de exponer cada tool como una llamada directa, expón los servidores MCP como una API de código que el agente importe y ejecute. Anthropic documentó este patrón con una reducción de 150.000 a 2.000 tokens en un flujo real, un 98,7% menos.
Este artículo explica cuándo ese patrón compensa, cómo se implementa y —tan importante como lo anterior— cuándo no deberías adoptarlo.
El problema: el contexto se llena antes de empezar
El Model Context Protocol resolvió el acoplamiento entre modelos y herramientas (el clásico paso de M×N a M+N integraciones). Pero la implementación por defecto de la mayoría de clientes tiene dos fugas de tokens que se agravan con la escala:
- Definiciones de tools cargadas por adelantado. El cliente inyecta en contexto la descripción de todas las herramientas de todos los servidores antes de leer siquiera la petición del usuario. Con unos pocos servidores conectados hablamos de decenas de miles de tokens consumidos "por si acaso".
- Resultados intermedios que pasan por el modelo varias veces. Si el agente lee un documento de Google Drive y lo escribe en Salesforce, ese documento entra en el contexto al leerlo y vuelve a entrar al reenviarlo. Un adjunto de 50.000 tokens se paga dos veces, y el modelo no aporta nada en ese trasiego.
El resultado es un agente más lento, más caro y más propenso a perder el hilo, precisamente cuando más herramientas le das.
La solución: presentar MCP como API de código
La idea central es cambiar el modo de interacción. En lugar de que el modelo emita llamadas a tools una a una, el agente escribe código que invoca los servidores MCP como si fueran módulos de una librería. Las herramientas se organizan en un sistema de archivos:
servers/
google-drive/
getDocument.ts
listFiles.ts
salesforce/
updateRecord.ts
query.ts
El agente descubre lo que necesita explorando ese árbol (ls ./servers/, abre el módulo, lee la firma) y solo entonces carga la definición de la tool concreta que va a usar. En vez de tres llamadas encadenadas pasando datos por el contexto, escribe algo así:
import { getDocument } from "./servers/google-drive/getDocument";
import { updateRecord } from "./servers/salesforce/updateRecord";
const doc = await getDocument({ id: fileId });
// El transcript nunca entra en el contexto del modelo:
await updateRecord({ id: leadId, notes: doc.text });
El documento viaja de Drive a Salesforce dentro del entorno de ejecución. El modelo orquesta; los datos no lo atraviesan.
Por qué funciona
- Divulgación progresiva (progressive disclosure). Los modelos navegan sistemas de archivos con naturalidad. Cargan la definición de una tool bajo demanda, no las mil de golpe. El presupuesto de contexto se gasta en el problema, no en el catálogo.
- Resultados filtrados en local. Una hoja de 10.000 filas se reduce a las 5 relevantes antes de devolver nada al modelo. El agente procesa en el sandbox y solo sube el resumen.
- Privacidad por diseño. Los datos sensibles pueden fluir entre servicios sin pasar nunca por el modelo. Puedes aplicar reglas deterministas de dónde va y de dónde viene cada dato.
- Estado y reutilización. El agente mantiene progreso entre operaciones y puede guardar código útil como "skill" reutilizable.
Comparativa: tool calls directas vs. code execution
| Dimensión | MCP con tool calls directas | MCP como API de código |
|---|---|---|
| Definiciones de tools | Todas en contexto por adelantado | Bajo demanda, al importar |
| Datos intermedios | Pasan por el modelo (a veces 2×) | Se quedan en el sandbox |
| Coste en tokens | Crece con nº de servidores | Casi plano |
| Filtrado de datos | Lo hace el modelo (caro) | Código local (barato) |
| Infraestructura | Cliente MCP estándar | Requiere sandbox seguro |
| Superficie de riesgo | Acotada al cliente | Ejecución de código generado |
Cuándo NO usar este patrón
Aquí es donde conviene ser honesto, porque el 98% de ahorro tiene letra pequeña:
- Si tienes uno o dos servidores y pocas tools, el coste de las definiciones es marginal. Montar un sandbox para ahorrar unos cientos de tokens es sobreingeniería. Quédate con las tool calls directas.
- Si no tienes un entorno de ejecución seguro y maduro. Ejecutar código generado por un modelo exige sandboxing real, límites de recursos, timeouts y monitorización. Sin eso, no estás optimizando tokens: estás abriendo una superficie de ataque. La ejecución de código no elimina los riesgos de MCP —prompt injection incluido—, los desplaza a un terreno que hay que fortificar aparte.
- Si tus flujos son cortos y no encadenan resultados grandes. El patrón brilla cuando hay muchos datos intermedios; si cada tarea es una llamada limpia, no hay trasiego que ahorrar.
La regla práctica: adopta code execution cuando el número de servidores y el tamaño de los datos intermedios ya te están doliendo en factura y latencia, y cuando ya tienes (o vas a construir de todos modos) un sandbox de confianza. Antes de eso, es complejidad prematura.
Cómo lo abordamos en Dribba
Cuando montamos agentes en producción, la decisión no es "code execution sí o no", sino dónde poner la frontera. Nuestra secuencia suele ser:
- Medir primero. Instrumentamos el consumo de tokens por servidor y por paso. Si las definiciones y los datos intermedios no son el cuello de botella, no tocamos la arquitectura.
- Empezar por lo simple. Tool calls directas con servidores enfocados y descripciones limpias. La mayoría de proyectos no necesitan más.
- Escalar a code execution cuando duele, con un sandbox aislado, reglas deterministas de flujo de datos y las mismas prácticas de seguridad que ya aplicamos a cualquier servidor MCP.
- Evaluar con evals, no con intuición. Cada cambio de arquitectura se valida contra un conjunto de casos, no contra la sensación de que "va más rápido".
Este patrón encaja con lo que ya hemos escrito sobre cuándo usar MCP en producción, sobre seguridad de agentes y MCP y sobre por qué evaluamos agentes con evals y no con vibes. Si además estás decidiendo entre protocolos, nuestra comparativa de A2A vs MCP da contexto.
Conclusión
Code execution con MCP no es una bala de plata: es una optimización potente para un problema concreto —contexto saturado por definiciones y datos intermedios— a cambio de operar un entorno de ejecución seguro. Si tu agente ya sufre por escala, el ahorro es real y grande. Si aún no, la versión directa de MCP sigue siendo la respuesta correcta.
¿Estás diseñando la arquitectura de agentes de tu producto y no tienes claro dónde poner la frontera entre modelo, tools y sandbox? En Dribba llevamos desde 2011 construyendo sistemas en producción con equipo senior in-house; podemos ayudarte a decidirlo con datos, no con hype.
