Code Execution with MCP: Token Efficiency for Complex Agents

Code execution with MCP refers to an agent pattern in which an AI agent writes and runs code that calls MCP tools programmatically in a sandbox, instead of issuing many individual tool calls. This noticeably reduces token consumption and latency, because tool definitions and intermediate results are processed in the code context rather than passing in full through the language model's context window. It is an optimization for complex, data-intensive workflows, not a replacement for classic tool calls.

Quick answers

• What it is: the agent generates a program that calls MCP tools as functions; only the condensed final result returns to the model.
• What it is good for: token and latency efficiency with many tools, many steps and large intermediate results.
• What it requires: an isolated sandbox, scope-limited tokens and least privilege, because executable model code is an attack surface in its own right.

The problem: tool calls scale poorly

The Model Context Protocol (MCP) was introduced by Anthropic as an open standard on November 25, 2024, to connect AI applications with external systems such as file systems, databases, business applications and developer tools. Technically, MCP is based on JSON-RPC 2.0 over two standard transports: stdio for local servers and an HTTP transport, which the 2025-03-26 spec revision (March 2025) switched from HTTP+SSE to Streamable HTTP. The same revision added OAuth 2.1 and tool annotations. JSON-RPC batching, also introduced in that revision, was removed again in the 2025-06-18 revision. As of 2026, MCP is the de facto standard for agent-to-tool communication; on December 9, 2025, Anthropic donated the protocol to the newly founded Agentic AI Foundation (AAIF) under the umbrella of the Linux Foundation. At that point, according to Anthropic, the SDKs recorded more than 97 million monthly downloads across Python and TypeScript.

In the classic pattern, the agent calls each tool individually. Every call passes through the language model (LLM): the model sees the tool definition, formulates the call, receives the full result back into its context window, and decides on the next step. For simple tasks, this is ideal: transparent and easy to audit. For complex workflows, however, two token guzzlers arise:

1. Tool definitions up front. If an agent has dozens or hundreds of MCP tools at its disposal, their descriptions must be loaded into the context in advance. That often means thousands of tokens before the agent even starts working.
2. Intermediate results in the context. A tool that returns a long list, a large document or an extensive API response writes this in full into the context window, even if the agent needs only three values from it. Across multi-step chains, this adds up.

The solution: the agent writes code

The code execution pattern, which Anthropic published as an engineering approach in late 2025, inverts the logic. The agent generates a program, typically Python or TypeScript, that treats the MCP tools as importable functions. This code runs in a sandbox. Filtering, loops, branching and aggregation happen there, in the code runtime context. Only the condensed final result returns to the model's context window.

The difference can be shown with pseudocode. The task: the agent is to find every contact in the CRM whose last order brought in more than 10,000 euros in revenue.

Classic, with many tool calls through the model:

LLM: call get_contacts()

-> 5,000 contacts (in full into the context)

LLM: for each contact, call get_last_order(id)

-> 5,000 further tool calls, each one individually through the model

LLM: filter those with revenue > 10,000

-> large volumes of data in the context again

Code execution, with one generated program:

# code generated by the agent, executed in the sandbox

contacts = mcp.crm.get_contacts()

revenue = {c.id: mcp.crm.get_last_order(c.id).revenue for c in contacts}

return [{"name": c.name, "revenue": revenue[c.id]} for c in contacts if revenue[c.id] > 10000]

In the second case, the model sees neither the 5,000 contacts nor the 5,000 order responses. It sees only the code it has written, and at the end the filtered list. The tool calls themselves run programmatically, not as individual LLM rounds. This saves both tokens and latency, because loops are executed without model round-trips.

A second effect is on-demand tool discovery: instead of loading all tool definitions in advance, the agent can browse the available MCP servers and their functions like a module directory and import only those actually needed. This keeps the up-front overhead small, even when hundreds of tools are theoretically available.

Example with numbers

A simplified calculation illustrates the lever. Assume an agent is to identify the top customers from a CRM and enrich them with order data. The figures are illustrative. They show orders of magnitude and are not a benchmark. The classic column reflects the cheapest case: it counts only the up-front load and a single raw list of 5,000 records. The 5,000 individual get_last_order calls from the pseudocode above are not included. Each of them would add its own order response and a model round-trip, so the real classic total would be many times higher.

In the table, the decisive item is not the up-front load, but the intermediate results: they are processed in code and occupy no model context. This is precisely where the lever lies. The larger the volumes of data and the more iterations, the greater the difference. For a simple single query, by contrast, the calculation reverses: the overhead of generating and executing a program exceeds the benefit.

Anthropic gives concrete figures in its engineering post of November 4, 2025. In its example, an agent downloads a meeting transcript from Google Drive and attaches it to a Salesforce lead. With direct tool calls, the transcript passes through the model twice. For a two-hour meeting, that can mean 50,000 additional tokens. When the tools are exposed as files and the agent loads only the definitions it needs for the current task, token usage drops from 150,000 to 2,000, a saving of 98.7% according to Anthropic.

When it makes sense and when it does not

Code execution is an optimization, not a standard pattern for everything. It fits data-intensive, recurring multi-tool workflows. For simple, one-off actions, direct tool calls remain faster, cheaper and more transparent: the trace shows every step directly, without the detour via generated code.

Security: the sandbox is mandatory

The biggest difference compared with classic tool calls is security-relevant: in the code execution pattern, the system runs executable code generated by a language model. This is an attack surface in its own right. For MCP, as of 2026 a deliberately optimistic trust model is documented, which equates syntactic correctness with semantic safety. There are also concrete attack classes: indirect prompt injection via server descriptions, tool poisoning (Invariant Labs PoC, April 2025), look-alike server squatting and CyberArk's full-schema poisoning, in which every part of a tool schema can be an injection vector. Hardening is explicitly the operator's task here.

For code execution, this means concretely:

• Isolated sandbox. The generated code runs in a sealed-off runtime environment without broad file and network access, with resource and time limits against infinite loops and resource exhaustion.
• Scope-limited tokens. MCP servers behind OAuth 2.1 (since the 2025-03-26 spec revision, March 2025) with the minimum necessary permissions. The code gets access only to what the task requires.
• Least privilege and no autonomous installation. Agents must not load or install MCP servers from untrusted registries on their own.
• Complete audit logging. Every tool call from the sandbox code is logged, with an end-to-end trace, pinned model versions and correlation via a trace ID. In regulated DACH industries, auditors and supervisory authorities may ask for this kind of evidence.

Anyone running executable model code without these protective layers trades token efficiency for a considerable security and data-protection risk. In regulated DACH industries, that is a no-go.

For agencies and B2B decision-makers

For DACH agencies and AI vendors building products, code execution with MCP is the direct lever on the unit economics of agentic products. Those running multi-tenant services (such as SEO, newsletter or research agents) pay per run in tokens; the code execution pattern measurably lowers these costs for data-intensive workflows and at the same time reduces latency, which improves perceived product quality. The practical starting point: review existing MCP-based agents to identify which workflows run through many tools and large intermediate results, switch precisely those over to code execution, and build in sandbox, OAuth 2.1 scopes and audit logging from day one. For B2B decision-makers, the rule is: the pattern is an architectural decision per workflow, not a platform switch. It builds on the already established MCP standard and can be introduced step by step, without discarding the existing tool integration.