Agents & Tool Use advanced 7 min read 6 flashcards

Code Execution as a Tool Interface

Instead of calling tools one at a time through the context window, the agent writes code against tool APIs in a sandbox, which cuts both tool-definition overhead and intermediate results out of the token budget.

Connect an agent to twelve MCP servers and it faces a bill before it has read the request. Every tool definition, every parameter schema, every description sits in the context window from the first token. Anthropic put the number bluntly: agents connected to large tool ecosystems can be "processing hundreds of thousands of tokens before reading a request" (Anthropic, Code execution with MCP, 4 November 2025).

The second bill is worse and less obvious. Direct tool calling routes every intermediate result through the model. Fetch a two-hour meeting transcript to copy it into a CRM, and the transcript enters the window once as a tool result and leaves it once as a tool argument. Anthropic's worked example puts that single round trip at roughly 50,000 extra tokens for one transcript.

The pattern

Present each MCP server as a code API on a filesystem rather than as a block of tool definitions in the prompt. servers/google-drive/getDocument.ts, servers/salesforce/updateRecord.ts, and so on. The agent is given a sandbox and writes a program:

const transcript = await gdrive.getDocument({ documentId: id });
const mentions = transcript.text
  .split("\n")
  .filter(line => /pricing|discount/i.test(line));
await salesforce.updateRecord({ id: acct, notes: mentions.join("\n") });
console.log(mentions.length + " pricing mentions logged");

The transcript never enters the context window. Only the last line does. Anthropic reports one such workflow dropping from 150,000 tokens to 2,000, a 98.7% reduction.

What the pattern buys, mechanism by mechanism

Progressive disclosure of tools. The agent lists a directory or calls a search function to find the tool it needs, then reads that one definition. Tool count stops driving prompt size, which is what makes a thousand-tool deployment tractable at all.

Results filtered before they are read. A 10,000-row query becomes rows.filter(...).slice(0, 5) inside the sandbox. The model sees five rows. Under direct tool calling it would see ten thousand, or the tool author would have had to anticipate the filter.

Control flow in a language built for it. Loops, retries and conditionals expressed as code cost one generation, not one generation per iteration. An agent polling a job to completion through direct tool calls pays a full model round trip per poll.

Data that never leaves the sandbox. Intermediate values can be tokenised or redacted in the execution environment, so PII can flow from one system to another without the model ever seeing it. This is the only mechanism on this list that changes what is possible rather than what is cheap.

Persistence and skills. Files written in the sandbox survive across turns, so a useful function the agent wrote once becomes a reusable capability rather than something it re-derives.

The cost, stated plainly

You now have to run untrusted, model-generated code. Anthropic names this directly: the approach "requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring", and those "infrastructure requirements add operational overhead and security considerations that direct tool calls avoid."

That is not a footnote. Direct tool calling has an auditable, enumerable action space: every possible call is a tool the operator registered. Code execution has an action space bounded only by the sandbox. The security model moves from "which tools did I expose" to "what can escape this container", which is a much harder question and a much older one.

When it breaks

Single-call tasks get worse. One tool call to check the weather is cheaper than writing, shipping and executing a program that makes one tool call. The pattern pays off with many tools, large results, or loops, and is pure overhead without them.

Debuggability drops. A failed tool call has a name, arguments and an error. A failed program has a stack trace inside a container, and reconstructing what the agent intended requires reading its code.

Sandbox cold start lands on user-facing latency. If the environment is provisioned per session, the first call pays container startup, which can dwarf the token savings for short tasks.

Model code quality becomes a reliability floor. The agent is now a programmer. Every silent off-by-one in generated filter logic is a wrong answer delivered confidently, and unlike a malformed tool call it does not raise a schema error.

Check yourself

6 flashcards for this concept

Click a card to reveal the answer.

Drill the whole track