Building More Efficient Agents by Running Code with MCP

The Model Context Protocol (MCP) is a standard for connecting AI agents to external systems, but as the number of connected tools grows, tool definitions and intermediate results quickly consume the context window. In environments dealing with hundreds or thousands of MCP servers, loading all tools at once and having the model handle every result becomes a core bottleneck for cost and latency.

There are two main problems. First, as tool definitions multiply, the number of tokens the model has to read explodes. Second, a tool's intermediate results pass back through the model's context, causing the same data to be shuttled back and forth multiple times.

For example, in a task that pulls meeting notes from Google Drive and loads them into Salesforce, the model has to read the entire document and then feed that content back into the Salesforce call. For long documents or large-scale data, this process can add on the order of 50,000 tokens in extra cost, and in some cases the task can fail by exceeding the context limit.

The solution is to treat MCP servers like APIs within a code execution environment, rather than handling them as direct tool calls. The agent finds and reads only the servers it needs from the filesystem, performs the actual data manipulation inside the execution environment, and returns only the results to the model. Using TypeScript examples, the article presents a file structure such as servers/google-drive/getDocument.ts and servers/salesforce/updateRecord.ts, and explains how to separate tool discovery into listing files and opening files.

The key effects of this approach are as follows.

• On-demand loading: Instead of reading the entire tool list at once, only the needed definitions are loaded.
• Reduced intermediate results: Processing such as filtering, aggregation, and joins is performed in code, minimizing the data the model sees.
• Handling complex control flow: Loops, conditionals, retries, and wait logic can be written as natural code.
• Privacy protection: Sensitive data stays in the execution environment by default, and only the necessary logs are exposed to the model.
• State persistence: Intermediate outputs can be stored in the file system so work can be continued later.

The difference is especially large with large-scale data. Instead of passing a 10,000-row spreadsheet directly into context, the execution environment can first filter out only pending orders so the model sees only a subset of rows. As with a loop waiting for a Slack message, code is far more stable and expressive than a conventional MCP tool chain.

Handling of sensitive information improves in the same way. In a task that reads emails, phone numbers, and names from a spreadsheet and inserts them into Salesforce, the MCP client can automatically tokenize PII so the model only sees masked values. Since the actual values are passed only within the MCP client and never go through the model, the risk of accidental exposure in logs or unnecessary processing is reduced.

Code execution also connects with an agent's skills. By saving validated logic as reusable functions or files, an agent can increasingly make better use of tools accumulated per task. This approach extends into reusable units of capability that bundle files, scripts, and instructions, systematically improving the quality of an agent's execution.

However, there is also a cost. Safely running code generated by an agent requires sandboxing, resource limits, and monitoring, which increases operational complexity compared to direct tool calls. Ultimately, code execution with MCP is an approach that trades token savings, lower latency, and better tool-composition ability for the need to also consider whether you can build the matching execution infrastructure.