AI & MCP

Code mode is overkill for your MCP server. It's not for your gateway.

Thomas Rooney

Published November 11, 2026 · 7 min read

A year ago, we said you don’t need code mode

A year ago this month, we published Reducing MCP token usage by 100x: you don’t need code mode. The argument was that MCP’s context problem could be solved inside the protocol, with progressive disclosure, without building a code execution environment.

A couple months ago, we ended up building code mode anyway. This is the story of where we were right, where we were wrong, and what makes gateways different…

We were so right about progressive disclosure for MCP, we were wrong

Our previous work found that building a server which used progressive disclosure reduced token consumption by 90% and totally eliminated the issue of context bloat in agents that MCP was causing at the time. However, the server ended up not being the right place for progressive disclosure. The client was much better suited.

Instead of needing to rely on every server to be architected efficiently, it made much more sense for clients to slap semantic search in front of the tool catalog. Shortly after that post, Anthropic shipped tool search in the Claude API. You mark a tool, or a whole MCP server, as deferred, and the model only loads its definition once it searches for it. OpenAI, GitHub Copilot and others offer their own versions, and the major harnesses all support some form of tool search for MCP today.

This raises an obvious question, one David Cramer (Sentry) asked recently:

I’m curious folks opinions in the MCP/Harness space.

All tier 1 harnesses now support tool search and deferred tools for MCP.

Should we drop all of our internal tool search primitives and just expose every tool?

The labs’ answer is yes.

The labs are post-training their models to be good at their own tool search. A second search layer inside your MCP server competes with it, and makes your real tools harder to find. At this point, progressive disclosure in your server is a hat on a hat.

But where does this conversation leave “code mode” MCP servers?

Code mode: the post that launched a thousand agents

Code mode didn’t start with MCP, but MCP gave the idea a much bigger stage. To boil down the idea: AI is really good at writing code, so instead of structured tool calls, let the agent write code. The idea really took off in September 2025 when Kenton Varda and Sunil Pai at Cloudflare published Code Mode: the better way to use MCP. They converted an MCP server’s tools into a TypeScript API, gave the agent a single tool that runs code, and executed that code in a sandboxed V8 isolate with no internet access. The only way out of the sandbox was through bindings to the connected MCP servers, so API keys never reached the model’s code.

The excitement skipped over some real costs, which is why we were initially skeptical of code mode as opposed to a solution like progressive disclosure:

• The server provider runs a lot more infrastructure. Running code an agent wrote means isolation, resource limits and monitoring, overhead that direct tool calls avoid. That’s not really a downside for a company like Cloudflare that sells ephemeral environments, but for most server providers it’s a pain in the neck.
• One script is harder to govern than many calls. With direct tool calls, each call is a discrete event you can log, approve or block. A script that makes ten calls in a loop is one opaque step, unless whatever runs it still checks every call against policy.

We maintain that for most companies, building a code mode MCP server is a feat of over-engineering.

Amortizing the cost of code mode

So far this isn’t a ringing endorsement for code mode, so why did we recently build it for the Speakeasy gateway?

Much like it ultimately made more sense for progressive disclosure to live in the AI client, the math of code mode makes a lot more sense when you implement it in a gateway rather than a single server.

A gateway sits between an organization’s agents and every downstream server: the CRM, ticketing, the data warehouse, internal APIs, etc. It already runs infrastructure, holds every user’s credentials and enforces policy on every call. Adding a sandbox to that is an incremental cost paid once, not a new cost every server provider pays separately. We implemented code mode in our gateway, and the benefits are spread across every MCP server an org uses.

So that takes care of the cost concern of code mode. Naturally, the next question is why a gateway needs code mode when the major agents (Claude, ChatGPT and Cursor) already support progressive disclosure. Isn’t this another hat on a hat?

Where code mode can help

Not every agent runs in a tier-1 harness

Tool search is built into the labs’ harnesses. Teams building internal agents on raw model APIs, open-source frameworks or their own runtimes usually get none of it. When those agents connect to a gateway with thousands of tools behind it, the gateway has to provide discovery itself, or the agent’s first request carries every tool definition.

Tool search finds tools. It doesn’t make using them cheaper.

Harness tool search keeps definitions out of context until they’re needed. It does nothing about intermediary results. Ask an agent to copy 500 records from your CRM into your warehouse, and every record still passes through the model on its way from one tool to the next. Through a code mode gateway, the agent writes a short script that reads from one system and writes to the other, and the records never enter its context. That’s fewer tokens and fewer turns, and it’s sensitive data that never lands in a transcript.

One upstream can re-authenticate without breaking the session

Every upstream has its own credentials, and they expire on their own schedules. When one upstream needs re-auth, a dedicated code mode tool prompts the user to re-authenticate just that one, and the rest of the session carries on. With a static tool list, one expired token usually means a failed call and a confused agent.

Every call in the script is still governed

Earlier we said one script is harder to govern than many calls, unless whatever runs it still checks every call against policy. At a gateway, that’s exactly what happens. Each upstream call a script makes goes through the same identity, permission checks and audit logging as a regular tool call.

So, do you need code mode?

If you run a single MCP server, probably not. Expose your tools plainly, write good descriptions, and let the harness handle discovery. The labs are post-training their models on their own tool search, and a second layer from you only gets in the way.

If you run a gateway, the answer flips. The harness can find your tools, but it can’t move data between your systems without exposing it, keep up with permissions that change mid-session, or re-authenticate one upstream on its own. All of that needs somewhere to run code. The gateway already holds the identity, credentials and policy to run it safely.

A year ago we said you don’t need code mode. For most servers, that’s still true. We just found the one place where you do.