Code Mode Over MCP: Escaping the Tool Maze

The Basic Pattern

Instead of exposing a large set of individual MCP tools directly to the agent, you expose one MCP tool: execute. That tool accepts a small TypeScript or Python program. Inside that execution environment, the program uses an SDK to read state, update resources, call product actions, handle errors, and return a final result.

MCP is still the protocol boundary. The agent is still making an MCP tool call. The difference is that the call can contain a small executable plan instead of a single low-level operation.

Why This Feels Obvious

Models are very good at writing code. So why are we asking them to call tools one at a time?

A lot of agent integrations make the model behave like a person clicking through a UI. Search this. Read that. Update this. Parse the response. Remember the ID. Call the next thing. Pull every intermediate result back into context. Then hope the model still remembers what it was doing after ten tool calls.

That works, but it is a strange shape for the problem. If the model can write the plan as code, much of the mechanical orchestration should happen inside the execution environment.

What You Probably Think Code Mode Is About

The obvious argument for code mode is efficiency. Ten MCP tool calls means ten round trips. Ten responses come back into the conversation. Intermediate observations consume context. Tool schemas have to be loaded and understood before the model can pick the right call.

Code mode reduces that overhead. The agent can write a short script that performs the sequence inside the execution environment, keeps temporary state locally, and returns only what matters. That can reduce latency, context bloat, and confusion from overly large tool surfaces.

That argument is true, but it is the least interesting part.

This Pattern Is Already Showing Up

Cloudflare has been one of the clearest public examples. Their Code Mode work describes giving the agent one tool that executes TypeScript in a sandbox, with API access exposed through typed interfaces rather than a giant list of individual tools. Their later MCP Code Mode work frames the pattern as letting the model write code against a typed SDK and execute that code safely.

FastMCP has a Code Mode transform that can wrap an MCP server with discovery tools like Search and GetSchemas, so the model can discover what it needs and then work through a more compact programmable interface. StackOne has described a similar direction for large tool catalogs, including a search-and-execute mode where an agent sees discovery and execution tools instead of hundreds of individual definitions.

Anthropic is also pushing the broader pattern through programmatic tool calling and code execution with MCP. Their framing is slightly different because it is a managed model-side capability, but the idea rhymes: let the model write code, call tools from inside that code, and keep raw intermediate tool responses out of the main context loop.

The common thread is simple. When the tool surface gets large or the workflow gets multi-step, asking the model to select one tool at a time starts to look like the wrong interface.

The Real Power Is the SDK

The real power of code mode is the SDK surface you choose to expose.

A lot of people will naturally start by wrapping each MCP tool as an SDK method. You had search_records tool, so now you have client.searchRecords(). You had update_ticket tool, so now you have client.updateTicket(). That is useful, but it leaves the deepest opportunity on the table.

The better question is: what is the most powerful SDK I can expose to agents so they can drive my product features in the smartest way possible?

That is how we are thinking about it at ThruWire. The SDK is not just a convenience layer over tools. It is a way to use the precision of an SDK spec to shape model behavior when the model interacts with the product. You can give the agent a clear set of objects, methods, constraints, defaults, and examples that point it toward the right product behavior.

This is different from asking the model to infer your product from a flat list of tools. A semantic SDK can encode judgment. It can collapse common sequences. It can make invalid states harder to reach. It can expose concepts that match the work instead of backend operations. It can turn "call the right tools in the right order" into "write against the right product abstraction."

That is the part I think matters most. Code mode is not only about moving tool calls into a script. It is about designing the interface that gives the agent the best possible grip on your product.

MCP as Transport, SDK as Interface

In the direct MCP pattern, the MCP tool list often becomes the product surface. The agent sees your product as a collection of callable functions, and the quality of the integration depends on how well the model can reason across that list.

In code mode, MCP remains the transport and permission boundary. The SDK becomes the working interface. The agent is programming against a temporary environment shaped around the task.

That distinction matters. The SDK can be more coherent, more opinionated, and more semantic than the raw MCP tools underneath it. It can represent workflows instead of endpoints, expose domain concepts instead of storage concepts, and make the right path easier to discover.

Self-Describing SDKs

The other powerful idea is that the SDK can be self-describing at runtime. It only has to be coherent for the agent at the moment it is used.

That changes the versioning problem. You do not need one universal SDK, kept stable forever, forcing every agent interaction through the same abstraction. The execution environment can expose the SDK that makes sense for the current task, user, project, vertical, or workflow stage.

For one use case, the SDK might expose research primitives. For another, compliance review primitives. For another, planning, editing, or deployment primitives. The underlying MCP server can keep evolving while the agent sees an interface tailored to the work in front of it.

Faster Product Iteration

This creates a different product iteration loop. You can introduce new capabilities by changing the SDK surface, not just by adding more MCP tools. You can experiment with higher-level abstractions before hardening them into permanent APIs. You can expose narrower SDKs when the agent needs guardrails and richer SDKs when it needs room to explore.

You can also change the SDK as the workflow progresses. Discovery, execution, review, and publishing may each need different affordances. Code mode makes it possible to present the right programmable surface at the right moment, while keeping the whole thing behind a single MCP execute tool.

The Shift

Code mode over MCP is usually described as a way to reduce round trips and context bloat. Useful, but only the starting point.

The bigger shift is that MCP gives you the protocol boundary, and code mode gives you a programmable product surface. Once the agent is writing against an SDK, you are no longer limited to exposing your product as a flat list of tools. You can expose it as a semantic environment designed for the task.

That is why I keep coming back to the same question: if models are already this good at writing code, why are we still designing so many integrations as if the model can only press one tool button at a time?