On this page
Tool descriptions eat the context
An MCP server tells your agent about every tool it has, with a full description and schema for each one. Add a handful of servers and the agent is carrying hundreds of tool descriptions before it reads your task. That costs tokens on every turn and makes picking the right tool harder.
Code mode changes the shape. The agent gets a small set of tools, writes a short piece of TypeScript that calls the tools it needs, and the code runs in a sandbox. Only the final result comes back into the conversation. The open-source pctx engine is one way to run it.
Your existing MCP servers, or any API with an OpenAPI spec, sit behind one code-mode server. The agent writes a short script against them. A sandbox runs the script and only the result returns to the agent. In the Docker version, any write the script tries to make pauses until you approve it, and every action is written to an audit log on your machine.
- Your MCP servers or an OpenAPI specwhat you already use
- Code-mode servera few tools in place of many
- Short codethe agent writes it
- Sandboxruns it, returns only the result
- Approval (Docker version)writes wait for you
Start with the light version
The light version wraps the MCP servers you already run in Claude Code, Claude Desktop or Cursor into one code-mode server with three tools. Nothing runs in the background and there is no approval step. Your agent calls the same tools as before, through code.
In one test against a public filesystem MCP server, 14 tool descriptions (about 3,278 tokens) became 3 tools (about 753 tokens), a 77% cut. That is one server. Your number depends on what you run, so measure your own.
Step up to Docker when writes need a gate
The Docker version gives your agent one endpoint on your own computer for the APIs you use. Reads run straight away. Every write (create, update, delete) waits until you approve it, and the pending writes and an audit log stay on your machine. It needs Docker running.
| You want | Light version | Docker version |
|---|---|---|
| Less context from MCP servers you already use | Yes | Yes |
| To work with APIs that have an OpenAPI spec | Yes | Yes |
| Every write to wait for your approval | No | Yes |
| An audit log on your machine | No | Yes |
| Nothing to install beyond Node.js | Yes | No, needs Docker |
Not sure? Start light. If you later want a gate on writes, move to Docker.
Six steps on one page
- Inventory your servers. List the MCP servers your agent loads and roughly how many tools each one adds.
- Decide what you need. Smaller context only, or smaller context plus approval on writes.
- Run one read-only test. Pick a task that only reads, such as listing files or fetching records, and run it through code mode.
- Compare tokens. Note the tool tokens before and after, and whether the agent still picked the right tool.
- Check the trail. On the Docker version, try one harmless write and confirm it waits for approval and shows up in the audit log.
- Decide. Adopt it for the servers where the saving is real, and leave small servers as they are.
Get the choice table and test checklist
Source notes
This guide describes the two code-mode setups I use. The token figures come from one measured run against a public filesystem MCP server. pctx is an open-source project by its own maintainers. The Legion toolkit has both versions with a setup lesson for members; nothing here depends on it.
Run your agency on agents you can check
Get one useful GTM email a week. Then join the community on Skool.
Get the newsletter
