Let the Model Orchestrate Tools with a Local Code Runtime

Code Mode was popularized by Cloudflare in September 2025 with an article titled Code Mode: the better way to use MCP. The article is well worth reading, but it can be a little overwhelming at first. It took me several months to fully understand the concept and how to use it correctly.

In this part, we will replace the two direct Drive tools with one generic code tool. We will expose a typed Drive facade and use a trusted local evaluator based on the Function constructor as a development shortcut before isolating it in Part 5.

From a multi-turn mode ​

In the previous article, we saw the following example: creating a file that contains all the titles of one Markdown file within a Drive.

To do that, we built an MCP server with two tools: readFile and writeFile, and predicted the model's behavior.

First, the model must read the file with readFile, loading the entire file content into its context. Then, it must extract the titles from the content and call writeFile to write the titles into a new file.

From a network perspective, the messages exchanged between the model and the MCP server will look like this:

LLM -> MCP: readFile(path="myfile.md")
MCP -> LLM: { content: "..." }  // entire file content
LLM -> MCP: writeFile(path="myfile_titles.md", content="...")
MCP -> LLM: { content: "{ success: true }" }

To a single-turn mode ​

While the previous approach works fine, we can see some flaws in it.

1. For our goal, the write step is intrinsically linked to the read step. We know, from the start, that both steps are required to achieve our goal so, in theory, a single turn should be enough to achieve it.
2. The model has to load the entire file content into its context which consumes both processing time, tokens, and context space for something the model doesn't need to know.

That is precisely why Code Mode shines.

As if it was an API ​

If, instead of being an MCP, the drive were exposed as a package API, what would our code look like?

import { readFile, writeFile } from 'drive'

async function createFileWithTitles(inputPath: string, outputPath: string) {
  const content = await readFile(inputPath)
  const titles = content.match(/^# (.*)$/gm)?.map(title => title.replace(/^# /, '')) ?? []
  await writeFile(outputPath, titles.join('\n'))
}

It could look like that.

Instead of exposing readFile and writeFile as individual tool calls, we expose them as functions. Behind the scenes, the implementation could be the same; only the facade changes, and the expected behavior remains the same.

Now, instead of asking the model to orchestrate the tools, we could ask it to orchestrate the functions by writing the code for us.

LLMs know code better than we do ​

LLMs are often more reliable at writing familiar code patterns than at selecting from a complex tool surface. Code Mode takes advantage of that strength without giving generated code unrestricted access to the host.

So, instead of providing tools to the model, we can provide a single code tool. To let the model know what to do and which functions are available, we can provide a typed interface in the tool description, exactly like in TypeScript .d.ts files.

Run one small JavaScript program against the local Drive capability.

The generated code is an async arrow function. It receives only the named capabilities below and should return the compact result needed by the next decision.

interface Drive {
  readFile: (path: string) => Promise<string>;
  writeFile: (path: string, content: string) => Promise<void>;
}

declare const drive: Drive;

Example:
async () => {
  const content = await drive.readFile('article.md');
  const headings = content
    .split('\\n')
    .filter((line) => /^#{1,6}\\s/.test(line))
    .map((line) => line.replace(/^#+\\s*/, ''));

  await drive.writeFile('titles.md', headings.join('\\n'));
  return { headingCount: headings.length };
}

Within this description, we provide the model with multiple pieces of information:

• A short description of what the code should do.
• An explanation of the expected code format, which is an async arrow function that receives only the named capabilities and should return a compact result.
• The Drive interface describes the available functions and their types.
• The drive constant is the instance of the Drive interface that the model can use. It tells the model that it can use drive.readFile and drive.writeFile to read and write files as a global variable.
• The example shows how to use the drive constant. This is a good practice: it provides the model with a clear example of how to use the available functions. This makes it more reliable and reduces the risk of the model generating code that does not work.

And the tool could look like this:

server.registerTool(
  'code',
  {
    title: 'Drive Code Mode',
    description: '...', // Description from the previous code block
    inputSchema: z.object({
      code: z
        .string()
        .describe('An async arrow function that uses the typed Drive capability')
    }),
    annotations: {
      title: 'Drive Code Mode'
    }
  },
  async ({ code }) => {
    const result = await evaluateCode(code)
    const text = formatCodeResult(result)
    return { content: [{ type: 'text', text }] }
  }
)

As you can see, the code tool is pretty generic. The power happens in the evaluateCode function, which will execute the code, preferably in a sandboxed environment.

However, for our example, we'll use a trusted local evaluator based on the Function constructor. It is not safe for production, but it is enough for this development checkpoint.

// eslint-disable-next-line no-new-func
const orchestrate = new Function(
  ...Object.keys(capabilities),
  `"use strict"; return (${code.trim()});`
)(...Object.values(capabilities))

const result = await orchestrate()

If you've never used this constructor, that's normal. It is unsafe and should not run untrusted code, including LLM-generated code, outside this trusted development checkpoint.

To quickly explain the Function constructor, it creates a new function from the provided code string. The first arguments are the parameter names, and the last argument is the function body. In our case, we pass the drive capability as a parameter and return the async arrow function generated by the model.

Code Mode into libraries ​

Code Mode can be painful to implement because you have to keep the types in the tool description in sync with the actual implementation.

Fortunately, libraries like Cloudflare Code Mode and TanStack Code Mode provide an easy way to implement Code Mode with the same tool definition as an MCP.

What we have built ​

We have replaced two dependent tool calls with one generated program that uses a typed Drive facade and returns only the result needed for the next decision. The executor boundary is deliberately narrow: the next articles keep the same pattern while changing the capability from a local Drive to a much larger OpenAPI specification.

In Part 3, we will use that boundary to search an OpenAPI document without placing the whole specification in the model's context.