Code Mode: the better way to use MCP

Agents should be writing code, not calling tools

The standard way to give an LLM access to external tools via the Model Context Protocol is to expose those tools directly to the model. That means the model produces special tokens that its harness parses as a structured tool call, executes the call, and feeds the result text back into the model's input stream.

That flow works, but it has a serious weakness. Tool call formatting is synthetic: the tokens used to denote calls are not anything the LLM encounters in natural text. Models only learn tool calling from curated training sets built by their developers. Code, on the other hand, exists in the wild in staggering quantities. An LLM asked to write TypeScript can draw on millions of real-world examples; an LLM asked to emit a properly formatted tool call can draw on only what its trainers contrived.

The gap shows up in practice. Give an agent many tools or tools with complex parameters, and it will make mistakes. But that same agent, asked to write code against a similarly complex API, does fine. And once an agent is writing code, it can chain operations without the model needing to see the intermediate outputs. In the tool-call model, each call's result must pass back through the LLM just so the model can copy it into the next call's arguments. When the agent writes a script, it can hold values in variables, loop, and conditionally branch, reading only the final results it needs.

We tested this idea directly. Instead of handing MCP tools to the model, we convert them into a TypeScript API and ask the model to write a program that calls it. The improvement was immediate.

What MCP actually gives you

MCP gained traction through 2025 because it standardizes how agents reach external systems. Each MCP server exposes a set of tools, where each tool is essentially an RPC function with parameters and a response. But the protocol does more than define a call format. It bundles together the API specification, the documentation an LLM needs to understand it, and handles authorization out of band. That uniformity is valuable on its own.

Traditional APIs assume the client developer knows the API they are coding against. MCP does not. An agent can connect to any MCP server and discover every available operation on the fly. That property survives even when you stop presenting tools to the model directly. The agent still needs a sandboxed environment where it can only reach the servers you have authorized. MCP provides a standard way to handle connectivity and authorization regardless of which agent or server is involved, and it supplies the documentation the model needs so it does not have to search the internet.

How Code Mode works

We have added this mode to the Cloudflare Agents SDK. If your app already uses the SDK with tools, you can wrap them with the code mode helper and get the new behavior. Instead of presenting every connected tool to the model, the agent receives a single tool: one that executes TypeScript code.

When the agent connects to an MCP server in code mode, the SDK fetches the server's schema and converts it into TypeScript definitions with doc comments derived from the schema. For example, connecting to an MCP server for a GitHub-hosted repository yields a typed interface the model can read directly. Currently the whole generated API is loaded into the agent's context; later versions may let the agent search and browse the API dynamically the way a coding assistant does.

The code the agent writes runs in a sandbox that is completely isolated from the internet. The only way the script reaches the outside world is through the generated TypeScript APIs, which are backed by RPC calls that loop back to the agent's runtime and dispatch to the appropriate MCP server. The script reports results by calling console.log(), and when the script finishes all output logs are returned to the agent.

No containers needed

The sandbox requirement sounds heavy until you realize Cloudflare Workers has been running on V8 isolates from the start. Isolates are JavaScript runtimes with security boundaries enforced by the V8 engine rather than by operating system process isolation. They start in milliseconds and use a few megabytes of memory.

That speed means the platform can create a fresh isolate for each script the agent runs, execute it, and discard it. There is no pool to prewarm and no reuse. The overhead is close to eval(), but with real isolation.

The missing piece was a way to load arbitrary Worker code from inside another Worker. Historically, Worker code had to be uploaded through the Cloudflare API, which deploys it globally. For agents, the code needs to run wherever the agent is running. The new Worker Loader API fills that gap, letting you load Worker code on demand from within your own Worker.

The Worker Loader API is available now when running workerd locally with Wrangler. Production use is in beta; you can sign up for access.

Code Mode: Putting MCP Inside a Proper Sandbox

MCP servers give an AI model a clean, standardized way to reach outside tools and data. But connecting a model directly to those servers, with raw network access and live credentials, creates a security hole that widens as AI-generated code gets more ambitious. Cloudflare's Code Mode approach sidesteps that by making the sandbox itself the star of the show.

Isolates beat containers for disposable compute

The core of Code Mode's design is that it runs every snippet of agent-generated code in a fresh sandbox built on Workers' isolate model, not a container. Workers uses isolates, which are dramatically lighter than containers — a fresh isolate spins up in milliseconds, and the cost is low enough that Cloudflare can throw one away after every single code snippet the agent produces. There is no pooling, no prewarming, no lifecycle management. Just create, run, dispose.

Cloudflare has not finalized pricing for the Worker Loader API that powers this, but the company says the isolate-based architecture will let it undercut container-based alternatives by a significant margin.

Bindings make isolation a feature, not a limitation

The real problem with sandboxing an AI agent is that you usually have to give it some kind of network access to reach the tools it needs. Then you're stuck writing network-level filters, HTTP proxies, or trying to explain to the LLM which requests are allowed and which get blocked. That is a mess for both the model and the supervisor.

Workers avoids this by design. The env object in a Worker does not just hold strings — it holds live objects called bindings. These bindings hand the sandbox direct references to specific resources without any need for generic network calls.

In Code Mode, the sandboxed Worker gets bindings that represent the MCP servers it is connected to. The agent's code can call those MCP servers precisely, but it cannot reach the broader Internet. The global fetch() and connect() functions simply throw errors inside the sandbox.

This makes the boundary explicit from the start. The binding defines a JavaScript interface, and that interface is the entire surface area the agent is permitted to use. There is no ambiguity about what traffic is legal, because there is no traffic at all.

Credentials stay out of the code

Because the binding is an already-authorized client, the sandboxed code never sees an API key. Any call the agent makes flows to the supervisor, which holds the actual access tokens and attaches them to the outbound MCP request.

That sidesteps one of the most common and dangerous failures in AI-authored code today: the model writing credentials into a file, committing them, or accidentally exporting them in a log. The code physically cannot leak keys it was never given.

Code Mode is less about making the model better at writing code, and more about giving it a workspace that is cheap, airtight, and incapable of doing damage beyond the narrow scope of the bindings it was handed.