MCP code mode is Cloudflare's proposed alternative to standard MCP tool calling, where instead of having an LLM emit JSON tool-call tokens directly, the LLM writes TypeScript code that calls your MCP tools as regular API functions. Cloudflare says their results are striking — agents handle more tools, and more complex ones, when tools are framed as a TypeScript API rather than exposed as raw tool calls. This article breaks down why that first claim is almost certainly correct, and why the second claim — that code mode eliminates the need for intermediate reasoning steps — is where the argument starts to fall apart.
What Is MCP Code Mode and Is It Better Than Tool Calling?
The core idea behind MCP code mode is simple: instead of asking an LLM to perform a tool call by emitting structured JSON tokens in a special format, you convert your MCP tools into a TypeScript API and let the LLM write code to call them. The LLM generates a code block, that code is executed in an isolate, and the result comes back.
01:45
Cloudflare's core claim: LLMs handle more tools when presented as TypeScript APIs vs direct MCP tool calls
Watch at 01:45 →
Cloudflare published an article titled Code Mode: The Better Way to Use MCP making exactly this case. Theo (T3.gg) covered it and broadly agreed with the framing. And honestly, on the surface, the argument is strong. When you frame tools as a TypeScript API, you're asking the LLM to do something it has seen millions of times in its pre-training data — write code that calls an API. That's deeply familiar territory.
Standard MCP tool calling, by contrast, is a behavior baked in during post-training — fine-tuning, RLHF, and similar processes using relatively small sets of contrived examples. Think of it this way: the pre-training knowledge is ingrained. The post-training behavior is tacked on. Cloudflare's Shakespeare analogy captures it well: putting Shakespeare through a one-month Mandarin course and asking him to write a play in Mandarin. He can do it. But it won't be his best work.
Why Are LLMs Better at Writing Code Than Using Tool Calls?
The reason LLMs likely perform better when tools are presented as TypeScript APIs comes down to training data distribution. Pre-training datasets contain an enormous volume of real-world code — GitHub repositories, documentation, Stack Overflow threads, tutorials. Examples of someone wanting to call an API and wiring that together correctly are everywhere. The types fit, the patterns are familiar, and the LLM has deeply internalized how this is supposed to work.
MCP tool calling syntax, on the other hand, is relatively new. The examples in training data are sparse and mostly synthetic. The LLM knows how to do it, but it's operating in a mode that isn't nearly as well-reinforced. When you present the same underlying capability as a TypeScript function signature, you're speaking the LLM's native language rather than asking it to use a second language it picked up recently.
04:20
The Shakespeare analogy: pre-training knowledge vs post-training tool-call behavior
Watch at 04:20 →
This is a strong argument for code mode as a general pattern, and it's likely why several major providers are already doing something similar internally — even if they don't call it that publicly.
How Does Cloudflare's Code Mode Work With MCP Servers?
In practice, Cloudflare's code mode pipeline works by taking your existing MCP tool definitions and converting them into TypeScript API interfaces. Instead of the LLM seeing a list of tool names and JSON schemas, it sees typed function signatures it can call like any other code. The LLM writes a code block using those functions, and the code is executed inside a V8 isolate — a sandboxed environment that Cloudflare already uses extensively in its Workers platform.
This is genuinely elegant. The tooling infrastructure under the hood is still MCP. The LLM just never has to think about that. From its perspective, it's writing a short program that calls some well-typed functions and returns a result. That's something it's extremely good at.
What Goes Wrong When You Chain MCP Tool Calls Together?
Here's where the argument gets more contentious — and where both the Cloudflare article and Theo's commentary arguably miss something important.
07:10
Why real-world tool outputs break the 'write the plan upfront' assumption
Watch at 07:10 →
One of the headline benefits of code mode is that when an LLM needs to chain multiple tool calls together, it can write all of that logic upfront as a single code block. Instead of calling tool one, getting the result back into the context window, calling the LLM again, calling tool two, and so on — the LLM writes getWeather(getLocation()) and you execute it once. No intermediate round-trips to the LLM. Faster, cheaper, fewer tokens wasted.
This sounds great. And for simple, well-defined tool chains, it probably is great. But the assumption underneath this benefit is significant: it assumes that the output of each intermediate tool call is deterministic enough that the LLM could have predicted the correct next action before seeing it.
Real-world tool outputs are messy. A location service doesn't always return a clean GPS coordinate. Sometimes it returns a street address. Sometimes it returns a best guess with a confidence score. Sometimes it returns a question back to the user. Sometimes it errors out with a partial result. If your code is written upfront as a single block, none of that messiness gets a chance to be reasoned about. You've effectively told the LLM: I trust that your plan will work perfectly, and I don't need you to check your work along the way.
Think about how you approach a complex task with many unknowns. You make a plan, sure. But how often does that plan survive contact with the first few steps exactly as written? Usually, you look at what came back, decide whether it matched your expectations, and adjust. That's not a bug in how humans plan — it's the whole point of iterative reasoning. Skipping intermediate evaluation in agentic tool chains is equivalent to claiming your plans always work out perfectly. For toy examples with predictable APIs, maybe. For anything genuinely complex, probably not.
What Is Speculative Tool Calling and How Does It Help?
There's actually a way to get most of the speed and efficiency benefits of code mode without sacrificing intermediate reasoning — and it maps loosely to how speculative decoding works in LLM inference.
The idea: run the full code-mode execution speculatively. Execute all the tool calls in sequence, record every intermediate output, and then present the LLM with the complete trace — every tool call, every intermediate result, and the final output — and ask it to validate whether anything looks wrong.
If the LLM reviews the trace and says everything looks correct, you accept the final output and you've saved all those intermediate round-trips. If the LLM spots a problem — say, the location service returned an ambiguous result that should have triggered a clarification step — it can flag exactly where the plan went off-track, and you can re-execute from that point.
This is speculative tool calling. You optimistically execute the full chain, then validate after the fact. In cases where the tools are well-behaved and the data is clean, you get the full speed benefit. In cases where something went sideways, you catch it rather than silently returning a wrong answer. You spend a few extra tokens on intermediate validation, but you potentially save a lot of latency in the happy path.
Does MCP Actually Add New Capabilities to AI Agents?
It's worth stepping back and saying this clearly: MCP does not add new capabilities to AI agents. It is a standardized protocol for exposing APIs to LLMs. That's genuinely useful — standards reduce friction, enable interoperability, and make it easier to build ecosystems of tools that work together. But MCP itself doesn't make an LLM smarter, doesn't give it access to anything it couldn't access before, and doesn't solve any of the fundamental challenges of agentic reasoning.
If you've been following the space closely, this is obvious. But the amount of hype around MCP right now sometimes implies it's something more fundamental than it is. It's a good standard. Use it. But don't confuse the packaging with the capability.
The Bottom Line on Code Mode
Code mode is a genuinely good idea for improving how LLMs interact with tools. Framing MCP tools as TypeScript APIs plays to the LLM's strengths and almost certainly improves performance on a wide range of tasks. The Cloudflare article is worth reading, and Theo's commentary is worth watching.
But the claim that code mode eliminates the value of intermediate reasoning steps — that you can write the whole plan upfront and just read the final output — is only true for simple, deterministic tool chains. For anything involving messy real-world data, ambiguous outputs, or decisions that depend on intermediate state, the iterative loop back through the LLM isn't overhead to be eliminated. It's the mechanism by which the agent actually reasons correctly.
Speculative tool calling is one way to get the best of both worlds. Run optimistically, validate after the fact, and only pay the cost of intermediate reasoning when something actually goes wrong. That's a direction worth exploring seriously as agentic architectures mature.
