Building Code Mode for APIs with MCP and Isolated Workers

Hello and welcome! 👋

This series is a practical follow-up to Code Mode, Two Tools, and an MCP Can Save Your LLM Context. That article introduced the idea: instead of making a model orchestrate every dependent tool call, let it write the orchestration as code and return only the result needed for its next decision.

Here, we will build that idea step by step. We will start with a small local file transformation, move to an OpenAPI-described API, and then replace the trusted local evaluator based on the Function constructor with an isolated runtime. The final result will be a locally runnable MCP server that can search an API specification and execute a narrow request against the API.

MCP fundamentals are outside the scope of this series. If you need an introduction to the protocol or to the basic relationship between an AI agent and an MCP server, begin with AI Agents and MCP Server: Teaming Up for the Agentic Web, especially its MCP server article.

Throughout the series, the model generates tool calls or code, the MCP client (or agent) runs the model loop, and the MCP server provides the capabilities. Keeping these roles separate is important: the host, not generated code, defines which capabilities are available.

The central idea is simple: with direct MCP tools, the model must call one tool, receive the complete intermediate result, and then use that result to decide how to call the next tool. With Code Mode, the model writes the orchestration as code, the code accesses the capabilities it needs inside the execution environment, and the model receives only the desired final result to continue.

Code Mode is not automatically the right choice. Direct MCP tools remain simpler for small, obvious actions. The extra runtime is worthwhile when a task contains dependent calls, requires local data processing, or needs to navigate a large and evolving API surface, like an OpenAPI specification that can be larger than the model's context window.

Throughout this journey, we will:

1. Beyond One Tool Call at a Time: Introducing Code Mode: Build two direct Drive tools over a Markdown fixture and observe how the complete file content travels through the model's context before the next tool call.
2. Let the Model Orchestrate Tools with a Local Code Runtime: Replace the two direct tools with one generic code tool, expose a typed Drive facade, and introduce the executor interface that later parts will replace. The local evaluator based on the Function constructor is intentionally a trusted development shortcut, not a production sandbox.
3. Searching OpenAPI Specifications Without Filling Context: Keep the OpenAPI document inside the server, resolve its local $ref values, and let generated code search a compact type facade instead of returning the complete specification to the model.
4. Calling APIs with Code Mode and Returning Only What Matters: Add a separate execute tool with a host-owned api.request() helper. We will validate request options, call the local MarketHub fixture, and return a narrow projection rather than the complete API response.
5. Replacing the Evaluator with Isolated Cloudflare Workers: Swap only the executor boundary for fresh Dynamic Workers. Search will run without outbound access, execute will use an allowlisted gateway, and credentials will remain outside generated code. We will also cover result bounds, resource limits, and host deadlines.

The companion repository, code-mode, is an executable textbook for the series. Each article has a complete checkpoint branch, a small evaluation, and a focused diff from the previous step. I recommend that you check out a branch and inspect the implementation for a better understanding of the concepts, as the articles will not cover every detail.