Code execution with MCP: how "Code Mode" cuts agent token costs 90%+

What you need to know

There is a quiet tax buried inside almost every agent you have built on the Model Context Protocol, and most teams only notice it when the invoice arrives. Each tool you connect ships its full schema into the model's context. Each tool call the model makes returns a result that also passes back through context. Wire up a dozen integrations with a few hundred operations between them, run a multi-step workflow, and the model can burn through a hundred thousand tokens before it has produced a single line of useful output. The work is real, but most of the tokens are plumbing.

Anthropic's engineering team put a name and a fix to this with a pattern they call code execution with MCP. The idea is deceptively simple: instead of the model making many direct tool calls — each tool definition and each intermediate result flowing through context — the agent writes code that calls the MCP tools, treating each tool as a file or module it can import. The intermediate data stays inside the execution environment and never round-trips through the model's context at all. Cloudflare shipped its own take, a "Code Mode" MCP server, in April 2026, aimed squarely at letting agents work across large APIs at minimal token usage. The reported reductions are not marginal. They are the difference between an agent that is too expensive to run at scale and one that is not.

This guide is for Builders who already run MCP-based agents and have watched the token counter climb. We will walk through what actually changes in the request flow, look at the numbers Anthropic and others have published, show a before-and-after in code, and — just as importantly — be honest about when this pattern is the wrong tool. A Chennai SaaS team wiring a support agent into a handful of internal APIs has a very different calculus from a Manchester operations team orchestrating hundreds of workflow steps across a dozen systems. Both should read the decision table before they refactor anything.

The hidden cost of the direct tool-call loop

To see why code execution helps, it is worth being precise about where the tokens go in a conventional MCP setup. When you connect an MCP server to a model, two things happen on every turn. First, the schemas for the available tools are loaded into context so the model knows what it can call and how. With a handful of tools this is trivial; with several servers exposing hundreds of operations between them, the tool definitions alone can run to tens of thousands of tokens before the user has said a word.

Second, and more insidiously, the model works by emitting a tool call, receiving the result back into context, reasoning over it, and emitting the next call. Every intermediate artefact — a list of files from a drive, a query result, a fetched document, a partial transform — travels back through the model. Consider a common enterprise workflow: pull records from one system, reshape them, and push them into another. The model calls a list operation, reads the full list; calls a fetch on each item, reads each payload; assembles the result; calls a write. In a naive implementation the intermediate data is read by the model at every hop, even though the model is not making a decision about most of it. It is acting as an expensive courier for bytes that could have moved directly from A to B.

This is the core inefficiency. The model is a reasoning engine being asked to also be a data bus. Code execution separates those two jobs.

How code execution rewires the flow

Under the code-execution pattern, the model is not handed every tool schema up front and it does not call tools one at a time. Instead it is given a small set of meta-tools — typically a search tool that lets it discover which tools exist and what they do, and an execute tool that runs a script the model writes against those tools. The tools themselves are exposed to the execution environment as importable files or modules. The model discovers what it needs, writes a short program that imports exactly those tools, and runs it. The program does the fetching, the filtering, the reshaping and the writing, all inside a sandbox. Only the final result — or a deliberately chosen summary — comes back into the model's context.

The effect on the token budget is structural, not incremental. The tool schemas no longer all sit in context; the model pulls only the ones it searches for. The intermediate data no longer passes through the model at all; a thousand-row query result that gets filtered down to three rows costs you the three rows, not the thousand. The multi-step orchestration that used to be a chain of context round-trips becomes a single script execution. You are asking the model to do the thing it is uniquely good at — writing the logic — and letting ordinary code do the thing code is good at, which is moving and transforming data.

If you are new to authoring the tools this pattern consumes, our walkthrough on building your first MCP server with FastMCP in twelve steps is the natural prerequisite — the cleaner your tool boundaries, the better this pattern behaves.

Before: the direct tool-call flow

Here is a stripped-down sketch of the conventional loop for a "copy new records from a drive into a CRM" task. Each step is a separate tool call, and each result flows back through the model's context before the next call is decided.

# BEFORE — direct tool calls, every intermediate result flows through the model
# The model emits these one at a time; each response re-enters context.

files = drive.list_files(folder="Q3 Leads")          # returns 1,200 file records -> all into context
for f in files:                                       # model iterates by emitting a call per file
    doc = drive.get_file(id=f["id"])                  # each full document -> into context
    if "lead" in doc["content"].lower():              # model reasons over full text each time
        record = parse_lead(doc["content"])           # another model turn
        salesforce.create_record(record)              # write call -> confirmation into context

# Reality: ~150,000 tokens for a workflow like this, most of them
# intermediate documents the model never needed to "read".

After: the agent writes code that imports the tools

Now the same task expressed as a single script the model writes and hands to execute. The tools are imported as modules; the loop, the filter and the parsing all run in the sandbox. Only a small summary returns to the model.

// AFTER — code execution: the model writes ONE script; tools are imported modules.
// Intermediate data (all 1,200 docs) stays in the sandbox, never touching context.

import { drive } from "./servers/drive";
import { salesforce } from "./servers/salesforce";

const files = await drive.listFiles({ folder: "Q3 Leads" });   // stays in the sandbox
let created = 0;

for (const f of files) {
  const doc = await drive.getFile({ id: f.id });                // stays in the sandbox
  if (doc.content.toLowerCase().includes("lead")) {
    await salesforce.createRecord(parseLead(doc.content));
    created++;
  }
}

// Only this line's value returns to the model's context:
return { created, scanned: files.length };                      // ~a few dozen tokens

The model wrote the second version in one turn, ran it once, and got back a two-field summary. In Anthropic's reporting, a Google Drive-to-Salesforce workflow of exactly this shape fell from around 150,000 tokens to roughly 2,000 — a reduction of about 98.7 per cent. The logic did not get smaller. The plumbing left the context.

What the numbers actually say

It is easy to be sceptical of a headline percentage, so it is worth laying the reported figures out side by side and noting what each one measures. These are the numbers Anthropic and subsequent analyses have published; treat them as evidence of the shape of the saving rather than a promise about your specific workload, which depends heavily on your tool count and how data-heavy your steps are.

Scenario	Direct tool calls	Code execution	Reduction
Google Drive → Salesforce workflow	~150,000 tokens	~2,000 tokens	~98.7%
Input-token comparison (published)	771K input tokens	165K input tokens	78.5% fewer input tokens
Large tool surface (500 tools)	baseline	~14× fewer input tokens/query	total cost ratio ~13:1
Widely cited headline figure	baseline	—	up to 92.8%

Three things stand out. First, the biggest single reduction — the 98.7 per cent Drive-to-Salesforce case — comes from a data-heavy workflow where the intermediate documents dominated the old token bill. That is the pattern where code execution wins hardest: many rows in, few rows out. Second, the 78.5 per cent input-token saving is a more conservative, general figure and is probably closer to what a typical mixed workload will see. Third, the 500-tool case shows the other axis of saving: at very high tool counts, simply not loading every schema up front produces roughly a fourteen-fold cut in input tokens per query and a total cost ratio of about thirteen to one, before you even count intermediate data. The two effects — fewer schemas in context, and no intermediate data in context — compound.

For a Chennai SaaS team running an agent against three internal services, none of these numbers will materialise, because there is barely any plumbing to remove. For a Manchester operations team fanning out across a dozen systems with hundreds of operations, the 500-tool line is the one to look at. This is the crux of the decision, and it deserves its own table.

When to use it — and when not to

Code execution is not a universal upgrade. It carries real overhead: you have to stand up a secure sandbox that runs model-written code, and you take on the debugging shift from tool-call traces to code traces. For a handful of tools and short workflows, direct tool calls are simpler and the overhead is not worth it. The pattern shines at high tool counts — dozens to hundreds — and multi-step, data-heavy workflows. As the Anthropic framing puts it, for small setups this is a long-tail escape hatch, not the front door. The table below is the decision I actually run through before reaching for it.

Signal in your workload	Direct tool calls	Code execution / Code Mode
Number of tools	A handful (up to ~10)	Dozens to hundreds
Workflow depth	One or two steps	Multi-step orchestration
Intermediate data volume	Small; model needs to see it	Large; mostly filtered/transformed away
Ratio of data in to data out	Roughly one to one	Many rows in, few rows out
Sandbox appetite	None — you want zero new infra	You can run isolated, resource-limited execution safely
Token bill today	Negligible	Dominated by schemas and intermediate results

Read the table as an "and", not an "or": the case for code execution gets stronger the more rows on the right you can tick. A single strong signal — say, five hundred tools — is enough on its own, because the schema-loading saving alone justifies it. But a two-tool, one-step agent with tiny payloads should stay on direct tool calls no matter how fashionable the alternative becomes. If your token pain is really about spend across a fleet of agents rather than any single one, our broader playbooks on LLM cost optimisation — cache, route, compress and on cost-optimising multi-agent systems cover the levers that sit alongside this one.

The trade-offs nobody puts on the slide

Beyond the sandbox requirement, three trade-offs deserve a clear-eyed look before you commit.

You must sandbox untrusted generated code. This is the big one and it is worth repeating because it changes your threat model. In the direct tool-call world, the model can only invoke operations you explicitly exposed, with arguments you can validate. In the code-execution world, the model writes arbitrary programs. Even with well-scoped tool modules, the surrounding script is model-authored. Isolation, secret hygiene and resource ceilings stop being nice-to-haves and become the price of entry.

Debugging shifts from tool-call traces to code traces. When a direct-tool-call agent misbehaves, you read a clean sequence of calls and results. When a code-execution agent misbehaves, you are debugging a program the model wrote, which may fail in ways a hand-written program would — an off-by-one in a loop, a mishandled null, a wrong field name — but that no human reviewed before it ran. Your observability has to capture the generated source, its inputs and its stack traces, not just a call log. Teams that skip this find that their savings come with a new class of opaque failures.

You still need good tool schemas. Code execution changes how tools are invoked; it does not rescue a badly designed tool. If your operations have vague names, sloppy types or inconsistent error shapes, the model will write code against them just as badly as it called them directly — arguably worse, because the mistakes are now buried inside a script. Getting the tool contracts right remains the foundational work; our guide on designing tools for AI agents — schemas, errors and retries is the piece to pair with this one.

How to adopt it without a big-bang rewrite

You do not need to convert your whole agent in one go. The sensible path is incremental and lets you measure the saving before you commit to the operational cost.

Start by identifying your single most data-heavy, multi-step workflow — the one that dominates your token bill in the trace breakdown you built earlier. Stand up a sandbox for just that path: an isolated execution environment with no production secrets, tight resource limits and no route to your internal network beyond the specific tools it needs. Expose the relevant tools to that sandbox as importable modules, and give the model the search and execute meta-tools instead of the full schema list. Run the two versions side by side on real traffic, compare the token breakdowns, and only then decide whether to widen the pattern to other workflows.

For a Chennai SaaS team, that pilot might be a nightly reconciliation agent that reads hundreds of records and writes a handful of exceptions — a textbook many-in, few-out case. For a Manchester operations team, it might be the cross-system orchestration that already spans a dozen tools. In both, the discipline is the same: prove the saving on one path, keep everything else on direct tool calls until the numbers justify moving it, and treat the sandbox as production security from day one, because it is.

Putting it together

Code execution with MCP is one of those rare optimisations where the mechanism and the saving are both easy to explain and hard to argue with. The model was doing two jobs — reasoning and shuttling data — and paying token rent on both. Let it write code, import the tools as modules, and keep the data in the sandbox, and the shuttling cost largely disappears: from around 150,000 tokens to roughly 2,000 in the Drive-to-Salesforce case, 78.5 per cent fewer input tokens in a general comparison, a fourteen-fold input-token cut at 500 tools, and a headline of up to 92.8 per cent. Cloudflare's Code Mode server shows the pattern is already productised, not just a lab result.

But the discipline is in the "when". This is a long-tail escape hatch for high tool counts and data-heavy, multi-step work — not the front door for a three-tool bot, where the sandbox you would have to secure costs more than the tokens you would save. Match the pattern to the tool surface. Sandbox the generated code as if it were hostile, because it is untrusted. Keep your tool schemas sharp, because code execution amplifies both good and bad tool design. Do that, and you turn an agent that was too expensive to run at scale into one that is not — which, for most teams shipping in India and the UK from an AWS Mumbai or London region, is the whole game.