Code Mode: MCP without the context bloat

Common MCP setups fill an agent's context with tool definitions before they are needed, then pass intermediate results through the model on their way to another operation. MCP does not require either choice. Mario Zechner's case for Bash and code points to a familiar alternative: consult help on demand, compose commands in a shell, and return the useful output.

Code Mode gives the model an execution tool that accepts code, with access to existing tools through callable functions.¹ Discovery and data transfer can then happen in code, with only the information the model needs returned to context.

Load only the definitions you need

An agent using a CLI can consult help for one command without carrying every installed program's manual in context. A code-mode runtime can do the same with its tool catalog: load the definitions needed for the task as the model discovers them.

For “Open Wikipedia in Codex’s browser,” the agent needs a tool that opens a browser tab. Inside Codex's code-mode runtime, it can search the ALL_TOOLS catalog and return the matching definitions:

const matches = ALL_TOOLS.filter(
  tool => tool.name.startsWith("mcp__codex_app__")
    && tool.description.toLowerCase().includes("browser tab")
);
text(matches);

The search finds mcp__codex_app__open_in_codex. Its declaration describes a browser target with a URL, so the agent can make the next call:

await tools.mcp__codex_app__open_in_codex({
  target: {
    type: "browser",
    url: "https://en.wikipedia.org/"
  }
});

Executor supports the same pattern through tools.search and tools.describe.tool, callable from its execute tool. At larger scale, Cloudflare’s Code Mode MCP server reported roughly 1,000 tokens for its initial interface, compared with 1.17 million for exposing its full API as individual tools. Selected definitions still enter context when needed; the full catalog does not.

Keep intermediate results outside context

Discovering a tool does not make its output small. Anthropic’s code execution with MCP illustrates this with a task: copy a meeting transcript from Google Drive into Salesforce. With direct tool calls, the transcript enters the model’s context as a result, then the model writes it out again as the next call’s argument.

Code can carry the transcript directly between tools, just as a shell pipeline carries data between commands. Using the article’s illustrative tool wrappers:

const transcript = await gdrive.getDocument({ documentId: "abc123" });
await salesforce.updateRecord({
  objectType: "SalesMeeting",
  recordId: "00Q5f000001abcXYZ",
  data: { Notes: transcript.content }
});

The transcript stays in a variable; only completion needs to be reported to the model. If the task were to summarize the meeting, the model would need its content. Copying it requires no such judgment.

Code can also reduce what reaches the model: in Armin Ronacher’s Playwright experiment, it extracts article titles and URLs instead of returning the whole page.

Use the interface you already have

If you already have an MCP server, its tool schemas can supply the code-mode interface. Cloudflare’s schema-to-TypeScript explanation shows how to generate definitions and documentation, with calls dispatched back to the server.

If you already have an API described by OpenAPI or GraphQL, you can skip writing an MCP wrapper too: Executor accepts those sources directly and makes their operations callable from code.²

Either way, the interface you maintain already describes the operations. You do not need to build a custom CLI with new commands, argument parsing, and help text to get on-demand discovery and composition. For work that only needs a lightweight runtime and API bindings, you can also avoid provisioning a full OS sandbox.³

The useful boundary is between what the model must decide and what code can execute. Keep the integrations, bring in the definitions needed for the task, and let code carry the data until there is something for the model to decide.