Your Deploy-from-Chat MCP Server Has Too Many Tools: What Anthropic's 98.7% Token Cut Means for Agent-Operated Infrastructure

A complex multi-step agent task that used to burn through 150,000 tokens of tool definitions and intermediate results can now run on about 2,000 — a 98.7% cut — when the agent writes code against its tools instead of calling them one at a time. That number comes from Anthropic's own engineering team, and if you run a deploy-from-chat MCP server with dozens of narrowly scoped tools, it is a direct verdict on your tool surface: every tool you add taxes every single request, whether the agent uses it or not.

The fix is not fewer capabilities. It is a different shape: a sandboxed execution environment with a handful of code-friendly primitives and fleet-scoped bindings, where the agent writes the glue itself. This post walks through why one-tool-per-turn breaks at fleet scale, what the code-execution pattern actually looks like, how to redesign a deploy-from-chat surface around it — and exactly where the token savings stop and audit-logged authorization still rules.

150,000 tokens in, 2,000 tokens out​

In November 2025, Anthropic engineers Adam Jones and Conor Kelly published "Code execution with MCP: Building more efficient AI agents". The core argument is simple: most MCP clients load every tool definition into the model's context window up front, then funnel every intermediate tool result back through it. At the scale teams now operate — hundreds or thousands of tools across dozens of MCP servers — an agent can chew through hundreds of thousands of tokens before it has even read the user's request.

Their alternative: present MCP servers as code APIs rather than direct tool calls. Each tool becomes an importable module in a file tree, the agent discovers tools by exploring the filesystem, and it filters and transforms results inside the execution environment before anything reaches the context window. Same task, same tools — 150,000 tokens down to 2,000, a 98.7% reduction in time and cost.

Cloudflare independently landed on the same insight with Code Mode: convert MCP tools into a TypeScript API and ask the model to write code against it. For a large API surface like Cloudflare's own, Code Mode cut input tokens by 99.9% — an equivalent MCP server without it would consume 1.17 million tokens, more than the entire context window of the most advanced models. Their summary line says it all: give agents an entire API in about 1,000 tokens.

Two independent teams, same conclusion: models are good at writing code, and tool surfaces should exploit that strength instead of fighting it.

Why one-tool-per-turn breaks at fleet scale​

Deploy-from-chat MCP servers are where this pain lands hardest, because infrastructure tool surfaces grow exactly the way that hurts most: one narrow tool per resource per verb. list_apps, get_app, list_deploys, get_deploy, get_logs, restart_deployment, rollback_deploy, scale_service — a modest deploy server easily reaches 30 to 40 tools, each with a JSON schema describing its parameters and return shape. At roughly 500 to 800 tokens per definition, the agent pays something like 20,000 to 30,000 tokens of context tax on every request before the first turn even starts. Add a staging environment, a second cluster, or per-tenant variants, and you are reading Anthropic's "hundreds of thousands of tokens" sentence as a description of your own server.

The second failure mode is worse because it scales with the incident, not the catalog. Ask the agent "why is the canary erroring?" and the classic loop goes: call get_logs, receive a 5,000-line tail into context, call get_deploy for the previous revision, receive another blob, call a metrics tool, receive a time series — then re-emit half of all of it as arguments to the next calls.

The transcript flows through the model twice, exactly the pattern Anthropic's Google-Drive-to-Salesforce example demonstrates: the meeting notes get loaded into context once when fetched and written out again verbatim as the argument to the update call. For infrastructure work, that means pod lists, log tails, and event streams — the bulkiest payloads you have — riding through the most expensive part of the pipeline, twice, on every multi-step task.

And unlike a docs search, deploy tasks are inherently multi-step: check status, compare revisions, read logs, decide, act, verify. Each hop re-pays the definition tax (the full catalog is in context for every turn) and adds another intermediate result. Tool count and task length multiply. That is the 150,000-token regime, and no amount of prompt tuning fixes it because the tokens are structural, not behavioral.

The pattern: MCP servers as code APIs​

The code-execution pattern replaces "here are all 40 tools, call them one per turn" with "here is a filesystem and a sandbox — import what you need, filter before you return." Concretely, Anthropic's implementation generates a file tree from the connected MCP servers:

servers/
├── fleet/
│   ├── getDeployStatus.ts
│   ├── getLogs.ts
│   ├── rollbackDeploy.ts
│   └── index.ts
├── metrics/
│   ├── queryErrorRate.ts
│   └── index.ts
└── ... (other servers)

Each tool is a typed module wrapping the underlying MCP call. The agent lists ./servers/ to see what exists, reads only the two or three files relevant to the current task, and writes a script that does the orchestration — loops, conditionals, filtering, joins across data sources — inside the sandbox. Only what the script logs or returns ever enters the context window.

Three mechanisms do most of the work:

Progressive disclosure. Models are good at navigating filesystems, so tool discovery becomes "search, then read" instead of "receive everything." Anthropic also describes a search_tools primitive with a detail-level parameter — name only, name plus description, or full schema — so the agent pays for exactly as much definition as the task needs. Cloudflare's Code Mode pushes this to the limit with essentially two primitives, search() and execute().

Filter-in-sandbox. Anthropic's canonical example fetches a 10,000-row spreadsheet and returns five rows: the filtering happens in the execution environment, and the model sees the summary. Translate that to fleet ops: grep 50,000 log lines for 5xx stack traces in the sandbox and return the ten unique signatures plus counts. The agent sees dozens of tokens instead of tens of thousands — and the answer is better, because code counted exhaustively instead of the model skimming a truncated tail.

Control flow as code. Polling for "deployment complete," retrying with backoff, branching on an error-rate threshold — these are loops and if-statements, not reasoning steps. Anthropic's example has the agent write a Slack polling loop rather than alternating between tool calls and sleep commands across a dozen model turns. Every turn you eliminate also eliminates re-sending the full tool catalog, so control-flow-in-code compounds the definition savings.

There is a privacy dividend too: intermediate results stay in the execution environment by default, and the MCP client can tokenize sensitive values before they reach the model — Anthropic demonstrates PII flowing from Sheets to Salesforce as opaque tokens that are only resolved at the tool boundary. For fleet ops, read that as secrets, kubeconfig material, and customer data never entering the context window unless the script explicitly logs them.

Redesigning a deploy-from-chat surface for code-writing agents​

Here is the concrete redesign the pattern implies. The "before" is the tool surface most deploy MCP servers ship today; the "after" is the same capability expressed for an agent that writes code.

The "after" surface is small on purpose: execute_code (run TypeScript in the sandbox), search_tools (find fleet bindings with progressive detail), and a set of fleet-scoped bindings — apps, deploys, logs, metrics, status — exposed as importable modules rather than callable tools. The agent that used to call eight tools across eight turns to "roll back the canary and show me the error-rate delta" now writes one script:

import * as fleet from './servers/fleet';
import * as metrics from './servers/metrics';
 
// Roll back the canary, then quantify the before/after delta in-sandbox.
await fleet.rollbackDeploy({ app: 'checkout', target: 'stable' });
 
const before = await metrics.queryErrorRate({ app: 'checkout', window: '30m' });
await fleet.waitForRollout({ app: 'checkout', timeoutMs: 300_000 });
const after = await metrics.queryErrorRate({ app: 'checkout', window: '30m' });
 
const delta = ((before.rate - after.rate) * 100).toFixed(2);
console.log(`canary rolled back; error rate ${before.rate} -> ${after.rate} (delta ${delta}pp)`);

Count what crosses the context boundary: two module definitions the agent chose to read, plus one summary line back. The rollout polling loop, the two metrics queries, and the arithmetic all ran in the sandbox. Under the old shape, the same task paid the full 40-tool catalog on every one of its ~8 turns plus two raw metrics payloads — comfortably tens of thousands of tokens for a task whose actual information content is one sentence.

Rough token math for this task makes the tradeoff explicit. These are illustrative estimates for a typical mid-size deploy server, not benchmarks — your schemas will differ, but the structure of the comparison holds:

That ~97% gap lands in the same neighborhood as Anthropic's measured 98.7% and Cloudflare's 99.9% — different workloads, same structural win. One honest caveat: prompt caching softens the repeated-definition half of the tool-calling bill on APIs that price cache reads cheaply. But you still pay the full first-turn load, every uncacheable intermediate result, and per-turn latency — the structural gap survives caching.

And the open-source ecosystem has already productized the pattern: Runbyte wraps any MCP server with a sandboxed TypeScript execution surface in this style, and independent implementations report matching numbers — one Deno-based executor measured 141k down to 1.6k tokens (98%) with ~200ms sandbox startup.

One more compounding benefit: Anthropic notes that agents can persist working scripts as reusable skills. Your agent's third canary rollback doesn't re-derive the procedure — it imports last month's tested script. The tool-calling agent starts from zero every time.

Where the 98.7% doesn't transfer — and what to build this week​

Now the boundary, because infrastructure is not Salesforce records. The token savings come from batching reads, filtering data, and moving control flow into code. None of that changes the rule that every mutating fleet action needs its own authorization and its own audit-log entry. A script that rolls back production in one execute_code call must not smuggle an unapproved mutation past the gate that a direct rollback_deploy tool call would have hit.

Concretely, the code-first deploy server needs controls the demo examples don't show:

• Mutating bindings stay gated. Reads (getLogs, queryErrorRate) can be freely importable; writes (rollbackDeploy, scaleService, deleteApp) execute only with a per-action approval — a signed token, a policy check, a human confirm — evaluated at the tool boundary, not in agent code. One approval per mutation, even when ten mutations share one script.
• Every mutation lands in an append-only audit log. The fleet already has the right model: Kubernetes API audit logs, and MCP-native versions like Open Cluster Management's MCP server with its pending-proposals queue and get_audit_trail over an append-only record. Code execution makes this more important, not less, because the blast radius of one approved script exceeds one tool call.
• Dry-run is a first-class binding. The agent should be able to execute the identical script against a preview binding (fleet.preview.rollbackDeploy) and show the diff before the real binding is armed. If your surface can't answer "what would this script change?" without changing it, code execution is a footgun.
• The sandbox gets no ambient credentials. Anthropic's own caveat applies double to fleet ops: the execution environment needs sandboxing, resource limits, and monitoring, and fleet bindings should be capability-scoped handles — this script may read logs for app X and roll back app X — not a mounted kubeconfig with cluster-admin.

With that boundary respected, the build list for this week is short:

1. Expose search_tools with detail levels and execute_code on your deploy MCP server, and publish fleet bindings as importable modules instead of flat tools.
2. Keep every mutating binding behind per-action approval and an append-only audit trail; add a preview twin for each one.
3. Redact secrets at the client boundary (the tokenization pattern) so connection strings and tokens can flow through scripts without entering model context.
4. Borrow before building: Runbyte-style sandboxed executors and Cloudflare's Code Mode work show the harness shape, including the ~200ms cold-start class of overhead to budget for.

The scarce resource in agent-operated infrastructure was never model intelligence — it was context, and then trust. Code execution fixes the context half so thoroughly that tool-count ceilings effectively stop mattering; what remains is the approval and audit path, which no token optimization can compress and no agent should be allowed to skip. Design for both halves and your deploy-from-chat surface gets cheaper and safer at the same time — a combination infrastructure work rarely offers.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators: deploy-from-chat against a fleet you control, with every mutation auditable. Star the repo on GitHub or deploy your first app today.