Code execution con MCP: eficiencia de tokens para agentes complejos

La ejecución de código con MCP es un patrón de agentes en el que un agente de IA, en lugar de hacer muchas llamadas individuales a herramientas, escribe y ejecuta código que invoca las herramientas MCP de forma programática dentro de un sandbox. Esto reduce de forma perceptible el consumo de tokens y la latencia, porque las definiciones de herramientas y los resultados intermedios se procesan en el contexto del código, en lugar de pasar completos por la ventana de contexto del modelo de lenguaje. Es una optimización para flujos de trabajo complejos y con muchos datos, no un sustituto de las llamadas clásicas a herramientas.

Respuestas rápidas

• Qué es: el agente genera un programa que llama a las herramientas MCP como funciones; solo el resultado final condensado vuelve al modelo.
• Para qué sirve: eficiencia en tokens y latencia cuando hay muchas herramientas, muchos pasos y grandes resultados intermedios.
• Qué necesita: un sandbox aislado, tokens con scopes limitados y mínimo privilegio, porque el código ejecutable del modelo es una superficie de ataque propia.

El problema: las llamadas a herramientas escalan mal

El Model Context Protocol (MCP) fue presentado por Anthropic el 25 de noviembre de 2024 como estándar abierto para conectar aplicaciones de IA con sistemas externos, por ejemplo, sistemas de archivos, bases de datos, aplicaciones empresariales y herramientas para desarrolladores. Técnicamente, MCP se basa en JSON-RPC 2.0 sobre dos transportes estándar: stdio para servidores locales y un transporte HTTP que la revisión de la especificación 2025-03-26 (marzo de 2025) cambió del anterior HTTP+SSE a Streamable HTTP. Esa misma revisión trajo OAuth 2.1 y las anotaciones de herramientas. El batching de JSON-RPC, introducido también entonces, lo eliminó de nuevo la revisión 2025-06-18. En 2026, MCP es el estándar de facto para la comunicación entre agentes y herramientas; el 9 de diciembre de 2025, Anthropic donó el protocolo a la recién creada Agentic AI Foundation (AAIF), bajo el paraguas de la Linux Foundation. En ese momento, según Anthropic, los SDK registraban más de 97 millones de descargas mensuales en Python y TypeScript.

En el patrón clásico, el agente llama a cada herramienta por separado. Cada llamada pasa por el modelo de lenguaje (LLM): el modelo ve la definición de la herramienta, formula la llamada, recibe el resultado completo de vuelta en su ventana de contexto y decide el siguiente paso. Para tareas simples, esto es ideal: transparente y fácil de auditar. En flujos de trabajo complejos, sin embargo, aparecen dos devoradores de tokens:

1. Definiciones de herramientas por adelantado. Si un agente tiene a su disposición decenas o cientos de herramientas MCP, sus descripciones deben cargarse de antemano en el contexto. A menudo son miles de tokens antes de que el agente empiece siquiera a trabajar.
2. Resultados intermedios en el contexto. Una herramienta que devuelve una lista larga, un documento grande o una respuesta de API extensa la escribe completa en la ventana de contexto, aunque el agente solo necesite tres valores. En cadenas de varios pasos, esto se acumula.

La solución: el agente escribe código

El patrón de ejecución de código, que Anthropic publicó a finales de 2025 como enfoque de ingeniería, invierte la lógica. El agente genera un programa, normalmente en Python o TypeScript, que trata las herramientas MCP como funciones importables. Este código se ejecuta en un sandbox. El filtrado, los bucles, las bifurcaciones y las agregaciones ocurren allí, en el contexto de ejecución del código. Solo el resultado final condensado vuelve a la ventana de contexto del modelo.

La diferencia se ve bien con pseudocódigo. La tarea: el agente debe encontrar en el CRM todos los contactos cuyo último pedido generó más de 10.000 euros de facturación.

Enfoque clásico, con muchas llamadas a herramientas a través del modelo:

LLM: ruf get_contacts() auf

-> 5.000 Kontakte (vollständig in den Kontext)

LLM: für jeden Kontakt ruf get_last_order(id) auf

-> 5.000 weitere Tool-Calls, jeder einzeln durchs Modell

LLM: filtere die mit Umsatz > 10.000

-> erneut große Datenmengen im Kontext

Ejecución de código, con un programa generado:

# vom Agenten generierter, in der Sandbox ausgeführter Code

kontakte = mcp.crm.get_contacts()

umsaetze = {k.id: mcp.crm.get_last_order(k.id).umsatz for k in kontakte}

return [{"name": k.name, "umsatz": umsaetze[k.id]} for k in kontakte if umsaetze[k.id] > 10000]

En el segundo caso, el modelo no ve ni los 5.000 contactos ni las 5.000 respuestas de pedidos. Solo ve el código que ha escrito y, al final, la lista filtrada. Las llamadas a herramientas se ejecutan de forma programática, no como rondas individuales del LLM. Eso ahorra tanto tokens como latencia, porque los bucles se ejecutan sin idas y vueltas al modelo.

Un segundo efecto es el descubrimiento de herramientas bajo demanda: en lugar de cargar de antemano todas las definiciones de herramientas, el agente puede explorar los servidores MCP disponibles y sus funciones como si fueran un directorio de módulos e importar solo las que realmente necesita. Así, la carga inicial se mantiene pequeña, incluso si en teoría hubiera cientos de herramientas disponibles.

Ejemplo con cifras

Un cálculo simplificado ilustra la palanca. Supuesto: un agente debe identificar los mejores clientes de un CRM y enriquecerlos con datos de pedidos. Las cifras son ilustrativas. Muestran órdenes de magnitud y no son un benchmark. La columna clásica refleja además el caso más favorable: solo cuenta la carga inicial y una única lista en bruto con 5.000 registros. Las 5.000 llamadas individuales a get_last_order del pseudocódigo anterior no están incluidas. Cada una de ellas traería su propia respuesta de pedido y una ida y vuelta al modelo. La suma clásica sería, por tanto, varias veces mayor.

En la tabla, la partida decisiva no es la carga inicial, sino los resultados intermedios: se procesan en el código y no ocupan contexto del modelo. Ahí está precisamente la palanca. Cuanto mayores sean los volúmenes de datos y más iteraciones haya, mayor será la diferencia. En una consulta individual sencilla, en cambio, el cálculo se invierte: el coste de generar y ejecutar un programa supera el beneficio.

Anthropic da valores concretos en su artículo de ingeniería del 4 de noviembre de 2025. En el ejemplo, un agente carga la transcripción de una reunión desde Google Drive y la adjunta a un lead de Salesforce. Con llamadas directas a herramientas, la transcripción pasa dos veces por el modelo. En una reunión de dos horas, eso puede suponer 50.000 tokens adicionales. Si las herramientas están disponibles como archivos y el agente solo carga las definiciones que necesita para la tarea actual, el consumo baja, según Anthropic, de 150.000 a 2.000 tokens, es decir, un 98,7 %.

Cuándo tiene sentido y cuándo no

La ejecución de código es una optimización, no un patrón estándar para todo. Encaja en flujos de trabajo multiherramienta recurrentes y con muchos datos. Para acciones simples y puntuales, las llamadas directas a herramientas siguen siendo más rápidas, más baratas y más transparentes: la traza muestra cada paso directamente, sin pasar por código generado.

Seguridad: el sandbox es obligatorio

La mayor diferencia respecto a las llamadas clásicas a herramientas afecta a la seguridad: con el patrón de ejecución de código, el sistema pone en marcha código ejecutable generado por un modelo de lenguaje. Es una superficie de ataque independiente. Para MCP, en 2026 está documentado un modelo de confianza deliberadamente optimista que equipara la corrección sintáctica con la seguridad semántica. A eso se suman clases de ataque concretas: la inyección indirecta de prompts a través de descripciones de servidores, el Tool Poisoning (PoC de Invariant Labs, abril de 2025), el squatting de servidores look-alike y el Full-Schema Poisoning de CyberArk, en el que cualquier parte del esquema de una herramienta puede ser un vector de inyección. El bastionado es expresamente tarea del operador.

En la práctica, para la ejecución de código esto significa:

• Sandbox aislado. El código generado se ejecuta en un entorno de ejecución aislado, sin acceso amplio a archivos ni a la red, con límites de recursos y de tiempo contra bucles infinitos y agotamiento de recursos.
• Tokens con scopes limitados. Servidores MCP detrás de OAuth 2.1 (desde la revisión de la especificación 2025-03-26, marzo de 2025) con los permisos mínimos necesarios. El código solo obtiene acceso a lo que exige la tarea.
• Mínimo privilegio y ninguna instalación autónoma. Los agentes no deben cargar ni instalar por su cuenta servidores MCP de registros no fiables.
• Registro de auditoría completo. Cada llamada a herramienta desde el código del sandbox queda registrada, con traza de extremo a extremo, versiones de modelo fijadas y correlación mediante un ID de traza. En sectores regulados de la región DACH, auditores y supervisores pueden exigir este tipo de pruebas.

Quien ejecuta código de modelo sin estas capas de protección paga la eficiencia de tokens con un riesgo considerable de seguridad y protección de datos. En sectores regulados de la región DACH, eso queda descartado.

Para agencias y responsables de decisiones B2B

Para las agencias y los proveedores de IA que convierten sus servicios en productos, la ejecución de código con MCP es la palanca directa sobre las unit economics de los productos agénticos. Quien opera servicios multitenant (por ejemplo, agentes de SEO, de newsletter o de investigación) paga en tokens por cada ejecución; el patrón de ejecución de código reduce esos costes de forma medible en flujos de trabajo con muchos datos y, al mismo tiempo, baja la latencia, lo que mejora la calidad percibida del producto. Para empezar en la práctica, conviene revisar los agentes existentes basados en MCP para ver qué flujos de trabajo pasan por muchas herramientas y grandes resultados intermedios, migrar justo esos a ejecución de código e integrar desde el primer día el sandbox, los scopes de OAuth 2.1 y el registro de auditoría. Para los responsables de decisiones B2B, la clave es esta: el patrón es una decisión de arquitectura por flujo de trabajo, no un cambio de plataforma. Se apoya en el estándar MCP, ya consolidado, y se puede introducir paso a paso sin descartar la integración de herramientas existente.