Cloudflare built something really useful. Take MCP tool schemas, generate a TypeScript API, let the model write code against it, run that code in a V8 isolate. For certain workloads—massive fan-out, heavy data transformation—this beats sequential tool calling, the default behavior of most LLM APIs. The model writes orchestration logic once instead of burning tokens on intermediate results.
The work itself is solid. It’s a client-side orchestration strategy focused on how to represent capabilities to models. But the framing and the internet turned it into a protocol critique.
The headline: “we’ve all been using MCP wrong.” Cloudflare CEO Matthew Prince’s follow-up: MCP should be “more code-like” because “LLMs are really good at understanding code, less good at understanding quasi XML.” The takeaway in the discourse: MCP got something fundamental wrong.
This conflates two separate layers. MCP is how servers expose capabilities to clients. Code mode is how one client chooses to present those capabilities to models. These are different concerns. Cloudflare’s own implementation proves this—they consume MCP schemas to generate their TypeScript client.
two layers, one conflation
Capability layer: MCP standardizes how a client discovers what tools exist, fetches schemas, authorizes access. It’s a protocol handshake. The server says “here’s what’s available.” The client fetches it.
Orchestration layer: Once you have capabilities, you choose how to present them to the model. Plug them into OpenAI’s tools parameter. Generate TypeScript and let the model write code. Compile them into workflow DAGs. Whatever fits your task.
MCP doesn’t mandate orchestration strategy. It just standardizes capability discovery. Conflating these layers turns a useful client technique into a protocol critique that doesn’t land.
where code mode wins
Massive parallelization of single tools. A tiny loop orchestrates thousands of calls. The model sees final aggregates, not every intermediate result.
Heavy transformation. Filter, map, reduce happens in the sandbox. No token overhead. No context window waste.
Workflows where control flow is known upfront. The model writes the script once. The isolate just executes it.
These are real advantages. Not universal advantages.
where code mode doesn’t
Find the contact you haven’t emailed recently. Fetch their info. Draft a message. Have another model critique it. Revise based on sentiment. Send if positive, schedule follow-up if negative.
That needs the model in the loop between steps. Model judgment. Conditional logic based on intermediate outputs.
In code mode you either bounce back to the outer agent constantly—losing the efficiency win—or you expose a model binding inside the sandbox. Now your internet-isolated sandbox can make LLM calls. You’ve reintroduced the governance questions you wanted to avoid.
For interleaved reasoning, tool calling with the model in the loop works better. Code mode shines when you can define control flow upfront and execute it without model involvement.
what they actually proved
Cloudflare built a TypeScript generator from MCP schemas, packaged V8 isolates with clean bindings, and demonstrated that code orchestration beats round-trips for parallelizable workloads. The approach isn’t new—academic work like CodeAct1 explored executable code as LLM actions in 2024. But Cloudflare’s implementation with V8 isolates and the Worker Loader API is clean engineering on top of MCP’s capability substrate.
The fact that they built it by consuming MCP schemas shows what MCP is for. Standardize capability discovery. Let clients orchestrate however they want. Code mode is one strategy. Direct tool calling is another. Pick what fits the task.
The discourse conflated these layers. Code mode isn’t evidence MCP got something wrong. It’s evidence the architecture works—neutral capability protocol, flexible client orchestration.
MCP does its job. It gets out of the way. That’s the design working as intended..
https://arxiv.org/pdf/2402.01030