{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/anthropic-com/2026-04-23-code-execution-with-mcp-building-more-efficient-agents/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "[The Model Context Protocol (MCP)](https://modelcontextprotocol.io/) is an open standard for connecting AI agents to external systems. Connecting agents to tools and data traditionally requires a custom integration for each pairing, creating fragmentation and duplicated effort that makes it difficult to scale truly connected systems. MCP provides a universal protocol—developers implement MCP once in their agent and it unlocks an entire ecosystem of integrations.\n\nSince launching MCP in November 2024, adoption has been rapid: the community has built thousands of [MCP servers](https://github.com/modelcontextprotocol/servers), [SDKs](https://modelcontextprotocol.io/docs/sdk) are available for all major programming languages, and the industry has adopted MCP as the de-facto standard for connecting agents to tools and data.\n\nToday developers routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers. However, as the number of connected tools grows, loading all tool definitions upfront and passing intermediate results through the context window slows down agents and increases costs.\n\nIn this blog we'll explore how code execution can enable agents to interact with MCP servers more efficiently, handling more tools while using fewer tokens.\n\n## **Excessive token consumption from tools makes agents less efficient**\n\nAs MCP usage scales, there are two common patterns that can increase agent cost and latency:\n\n1. Tool definitions overload the context window;\n2. Intermediate tool results consume additional tokens.\n\n### **1\\. Tool definitions overload the context window**\n\nMost MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax. These tool definitions might look like:\n\n```\ngdrive.getDocument\n Description: Retrieves a document from Google Drive\n Parameters:\n documentId (required, string): The ID of the document to retrieve\n fields (optional, string): Specific fields to return\n Returns: Document object with title, body content, metadata, permissions, etc.\n```\n\n```\nsalesforce.updateRecord\n Description: Updates a record in Salesforce\n Parameters:\n objectType (required, string): Type of Salesforce object (Lead, Contact, Account, etc.)\n recordId (required, string): The ID of the record to update\n data (required, object): Fields to update with their new values\n Returns: Updated record object with confirmation\n```\n\nTool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.\n\n### **2\\. Intermediate tool results consume additional tokens**\n\nMost MCP clients allow models to directly call MCP tools. For example, you might ask your agent: \"Download my meeting transcript from Google Drive and attach it to the Salesforce lead.\"\n\nThe model will make calls like:\n\n```\nTOOL CALL: gdrive.getDocument(documentId: \"abc123\")\n → returns \"Discussed Q4 goals...\\n[full transcript text]\"\n (loaded into model context)\n\nTOOL CALL: salesforce.updateRecord(\n\t\t\tobjectType: \"SalesMeeting\",\n\t\t\trecordId: \"00Q5f000001abcXYZ\",\n \t\t\tdata: { \"Notes\": \"Discussed Q4 goals...\\n[full transcript text written out]\" }\n\t\t)\n\t\t(model needs to write entire transcript into context again)\n```\n\nEvery intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.\n\nWith large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.\n\n![Image of how the MCP client works with the MCP server and LLM.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F9ecf165020005c09a22a9472cee6309555485619-1920x1080.png&w=3840&q=75)\\\nThe MCP client loads tool definitions into the model's context window and orchestrates a message loop where each tool call and result passes through the model between operations.\n\n## **Code execution with MCP improves context efficiency**\n\nWith code execution environments becoming more common for agents, a solution is to present MCP servers as code APIs rather than direct tool calls. The agent can then write code to interact with MCP servers. This approach addresses both challenges: agents can load only the tools they need and process data in the execution environment before passing results back to the model.\n\nThere are a number of ways to do this. One approach is to generate a file tree of all available tools from connected MCP servers. Here's an implementation using TypeScript:\n\n```\nservers\n├── google-drive\n│ ├── getDocument.ts\n│ ├── ... (other tools)\n│ └── index.ts\n├── salesforce\n│ ├── updateRecord.ts\n│ ├── ... (other tools)\n│ └── index.ts\n└── ... (other servers)\n```\n\nThen each tool corresponds to a file, something like:\n\n```\n// ./servers/google-drive/getDocument.ts\nimport { callMCPTool } from \"../../../client.js\";\n\ninterface GetDocumentInput {\n documentId: string;\n}\n\ninterface GetDocumentResponse {\n content: string;\n}\n\n/* Read a document from Google Drive */\nexport async function getDocument(input: GetDocumentInput): Promise {\n return callMCPTool('google_drive__get_document', input);\n}\n```\n\nOur Google Drive to Salesforce example above becomes the code:\n\n```\n// Read transcript from Google Docs and add to Salesforce prospect\nimport * as gdrive from './servers/google-drive';\nimport * as salesforce from './servers/salesforce';\n\nconst transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;\nawait salesforce.updateRecord({\n objectType: 'SalesMeeting',\n recordId: '00Q5f000001abcXYZ',\n data: { Notes: transcript }\n});\n```\n\nThe agent discovers tools by exploring the filesystem: listing the `./servers/`directory to find available servers (like `google-drive` and `salesforce`), then reading the specific tool files it needs (like `getDocument.ts` and `updateRecord.ts`) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%**.**\n\nCloudflare [published similar findings](https://blog.cloudflare.com/code-mode/), referring to code execution with MCP as “Code Mode.\" The core insight is the same: LLMs are adept at writing code and developers should take advantage of this strength to build agents that interact with MCP servers more efficiently.\n\n## **Benefits of code execution with MCP**\n\nCode execution with MCP enables agents to use context more efficiently by loading tools on demand, filtering data before it reaches the model, and executing complex logic in a single step. There are also security and state management benefits to using this approach.\n\n### Progressive disclosure\n\nModels are great at navigating filesystems. Presenting tools as code on a filesystem allows models to read tool definitions on-demand, rather than reading them all up-front.\n\nAlternatively, a `search_tools` tool can be added to the server to find relevant definitions. For example, when working with the hypothetical Salesforce server used above, the agent searches for \"salesforce\" and loads only those tools that it needs for the current task. Including a detail level parameter in the `search_tools` tool that allows the agent to select the level of detail required (such as name only, name and description, or the full definition with schemas) also helps the agent conserve context and find tools efficiently.\n\n### Context efficient tool results\n\nWhen working with large datasets, agents can filter and transform results in code before returning them. Consider fetching a 10,000-row spreadsheet:\n\n```\n// Without code execution - all rows flow through context\nTOOL CALL: gdrive.getSheet(sheetId: 'abc123')\n → returns 10,000 rows in context to filter manually\n\n// With code execution - filter in the execution environment\nconst allRows = await gdrive.getSheet({ sheetId: 'abc123' });\nconst pendingOrders = allRows.filter(row => \n row[\"Status\"] === 'pending'\n);\nconsole.log(`Found ${pendingOrders.length} pending orders`);\nconsole.log(pendingOrders.slice(0, 5)); // Only log first 5 for review\n```\n\nThe agent sees five rows instead of 10,000. Similar patterns work for aggregations, joins across multiple data sources, or extracting specific fields—all without bloating the context window.\n\n#### **More powerful and context-efficient control flow**\n\nLoops, conditionals, and error handling can be done with familiar code patterns rather than chaining individual tool calls. For example, if you need a deployment notification in Slack, the agent can write:\n\n```\nlet found = false;\nwhile (!found) {\n const messages = await slack.getChannelHistory({ channel: 'C123456' });\n found = messages.some(m => m.text.includes('deployment complete'));\n if (!found) await new Promise(r => setTimeout(r, 5000));\n}\nconsole.log('Deployment notification received');\n```\n\nThis approach is more efficient than alternating between MCP tool calls and sleep commands through the agent loop.\n\nAdditionally, being able to write out a conditional tree that gets executed also saves on “time to first token” latency: rather than having to wait for a model to evaluate an if-statement, the agent can let the code execution environment do this.\n\n### Privacy-preserving operations\n\nWhen agents use code execution with MCP, intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return, meaning data you don’t wish to share with the model can flow through your workflow without ever entering the model's context.\n\nFor even more sensitive workloads, the agent harness can tokenize sensitive data automatically. For example, imagine you need to import customer contact details from a spreadsheet into Salesforce. The agent writes:\n\n```\nconst sheet = await gdrive.getSheet({ sheetId: 'abc123' });\nfor (const row of sheet.rows) {\n await salesforce.updateRecord({\n objectType: 'Lead',\n recordId: row.salesforceId,\n data: { \n Email: row.email,\n Phone: row.phone,\n Name: row.name\n }\n });\n}\nconsole.log(`Updated ${sheet.rows.length} leads`);\n```\n\nThe MCP client intercepts the data and tokenizes PII before it reaches the model:\n\n```\n// What the agent would see, if it logged the sheet.rows:\n[\n { salesforceId: '00Q...', email: '[EMAIL_1]', phone: '[PHONE_1]', name: '[NAME_1]' },\n { salesforceId: '00Q...', email: '[EMAIL_2]', phone: '[PHONE_2]', name: '[NAME_2]' },\n ...\n]\n```\n\nThen, when the data is shared in another MCP tool call, it is untokenized via a lookup in the MCP client. The real email addresses, phone numbers, and names flow from Google Sheets to Salesforce, but never through the model. This prevents the agent from accidentally logging or processing sensitive data. You can also use this to define deterministic security rules, choosing where data can flow to and from.\n\n### State persistence and skills\n\nCode execution with filesystem access allows agents to maintain state across operations. Agents can write intermediate results to files, enabling them to resume work and track progress:\n\n```\nconst leads = await salesforce.query({ \n query: 'SELECT Id, Email FROM Lead LIMIT 1000' \n});\nconst csvData = leads.map(l => `${l.Id},${l.Email}`).join('\\n');\nawait fs.writeFile('./workspace/leads.csv', csvData);\n\n// Later execution picks up where it left off\nconst saved = await fs.readFile('./workspace/leads.csv', 'utf-8');\n```\n\nAgents can also persist their own code as reusable functions. Once an agent develops working code for a task, it can save that implementation for future use:\n\n```\n// In ./skills/save-sheet-as-csv.ts\nimport * as gdrive from './servers/google-drive';\nexport async function saveSheetAsCsv(sheetId: string) {\n const data = await gdrive.getSheet({ sheetId });\n const csv = data.map(row => row.join(',')).join('\\n');\n await fs.writeFile(`./workspace/sheet-${sheetId}.csv`, csv);\n return `./workspace/sheet-${sheetId}.csv`;\n}\n\n// Later, in any agent execution:\nimport { saveSheetAsCsv } from './skills/save-sheet-as-csv';\nconst csvPath = await saveSheetAsCsv('abc123');\n```\n\nThis ties in closely to the concept of [Skills](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview), folders of reusable instructions, scripts, and resources for models to improve performance on specialized tasks. Adding a SKILL.md file to these saved functions creates a structured skill that models can reference and use. Over time, this allows your agent to build a toolbox of higher-level capabilities, evolving the scaffolding that it needs to work most effectively.\n\nNote that code execution introduces its own complexity. Running agent-generated code requires a secure execution environment with appropriate [sandboxing](https://www.anthropic.com/engineering/claude-code-sandboxing), resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid. The benefits of code execution—reduced token costs, lower latency, and improved tool composition—should be weighed against these implementation costs.\n\n## **Summary**\n\nMCP provides a foundational protocol for agents to connect to many tools and systems. However, once too many servers are connected, tool definitions and results can consume excessive tokens, reducing agent efficiency.\n\nAlthough many of the problems here feel novel—context management, tool composition, state persistence—they have known solutions from software engineering. Code execution applies these established patterns to agents, letting them use familiar programming constructs to interact with MCP servers more efficiently. If you implement this approach, we encourage you to share your findings with the [MCP community](https://modelcontextprotocol.io/community/communication).\n\n### Acknowledgments\n\n*This article was written by Adam Jones and Conor Kelly. Thanks to Jeremy Fox, Jerome Swannack, Stuart Ritchie, Molly Vorwerck, Matt Samuels, and Maggie Vo for feedback on drafts of this post.*\n", "authors": [], "captured_at": "2026-09-27T19:29:15.293681927+00:00", "category": "programming", "content_html": "

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external systems. Connecting agents to tools and data traditionally requires a custom integration for each pairing, creating fragmentation and duplicated effort that makes it difficult to scale truly connected systems. MCP provides a universal protocol—developers implement MCP once in their agent and it unlocks an entire ecosystem of integrations.

\n

Since launching MCP in November 2024, adoption has been rapid: the community has built thousands of MCP servers, SDKs are available for all major programming languages, and the industry has adopted MCP as the de-facto standard for connecting agents to tools and data.

\n

Today developers routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers. However, as the number of connected tools grows, loading all tool definitions upfront and passing intermediate results through the context window slows down agents and increases costs.

\n

In this blog we'll explore how code execution can enable agents to interact with MCP servers more efficiently, handling more tools while using fewer tokens.

\n

Excessive token consumption from tools makes agents less efficient

\n

As MCP usage scales, there are two common patterns that can increase agent cost and latency:

\n
    \n
  1. Tool definitions overload the context window;
    2. \n
  2. Intermediate tool results consume additional tokens.
    3. \n
\n

1. Tool definitions overload the context window

\n

Most MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax. These tool definitions might look like:

\n
gdrive.getDocument\n     Description: Retrieves a document from Google Drive\n     Parameters:\n                documentId (required, string): The ID of the document to retrieve\n                fields (optional, string): Specific fields to return\n     Returns: Document object with title, body content, metadata, permissions, etc.\n
\n
salesforce.updateRecord\n    Description: Updates a record in Salesforce\n    Parameters:\n               objectType (required, string): Type of Salesforce object (Lead, Contact,      Account, etc.)\n               recordId (required, string): The ID of the record to update\n               data (required, object): Fields to update with their new values\n     Returns: Updated record object with confirmation\n
\n

Tool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.

\n

2. Intermediate tool results consume additional tokens

\n

Most MCP clients allow models to directly call MCP tools. For example, you might ask your agent: "Download my meeting transcript from Google Drive and attach it to the Salesforce lead."

\n

The model will make calls like:

\n
TOOL CALL: gdrive.getDocument(documentId: "abc123")\n        → returns "Discussed Q4 goals...\\n[full transcript text]"\n           (loaded into model context)\n\nTOOL CALL: salesforce.updateRecord(\n\t\t\tobjectType: "SalesMeeting",\n\t\t\trecordId: "00Q5f000001abcXYZ",\n  \t\t\tdata: { "Notes": "Discussed Q4 goals...\\n[full transcript text written out]" }\n\t\t)\n\t\t(model needs to write entire transcript into context again)\n
\n

Every intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.

\n

With large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.

\n
\"Image
The MCP client loads tool definitions into the model's context window and orchestrates a message loop where each tool call and result passes through the model between operations.
\n

Code execution with MCP improves context efficiency

\n

With code execution environments becoming more common for agents, a solution is to present MCP servers as code APIs rather than direct tool calls. The agent can then write code to interact with MCP servers. This approach addresses both challenges: agents can load only the tools they need and process data in the execution environment before passing results back to the model.

\n

There are a number of ways to do this. One approach is to generate a file tree of all available tools from connected MCP servers. Here's an implementation using TypeScript:

\n
servers\n├── google-drive\n│   ├── getDocument.ts\n│   ├── ... (other tools)\n│   └── index.ts\n├── salesforce\n│   ├── updateRecord.ts\n│   ├── ... (other tools)\n│   └── index.ts\n└── ... (other servers)\n
\n

Then each tool corresponds to a file, something like:

\n
// ./servers/google-drive/getDocument.ts\nimport { callMCPTool } from "../../../client.js";\n\ninterface GetDocumentInput {\n  documentId: string;\n}\n\ninterface GetDocumentResponse {\n  content: string;\n}\n\n/* Read a document from Google Drive */\nexport async function getDocument(input: GetDocumentInput): Promise<GetDocumentResponse> {\n  return callMCPTool<GetDocumentResponse>('google_drive__get_document', input);\n}\n
\n

Our Google Drive to Salesforce example above becomes the code:

\n
// Read transcript from Google Docs and add to Salesforce prospect\nimport * as gdrive from './servers/google-drive';\nimport * as salesforce from './servers/salesforce';\n\nconst transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;\nawait salesforce.updateRecord({\n  objectType: 'SalesMeeting',\n  recordId: '00Q5f000001abcXYZ',\n  data: { Notes: transcript }\n});\n
\n

The agent discovers tools by exploring the filesystem: listing the ./servers/directory to find available servers (like google-drive and salesforce), then reading the specific tool files it needs (like getDocument.ts and updateRecord.ts) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%.

\n

Cloudflare published similar findings, referring to code execution with MCP as “Code Mode." The core insight is the same: LLMs are adept at writing code and developers should take advantage of this strength to build agents that interact with MCP servers more efficiently.

\n

Benefits of code execution with MCP

\n

Code execution with MCP enables agents to use context more efficiently by loading tools on demand, filtering data before it reaches the model, and executing complex logic in a single step. There are also security and state management benefits to using this approach.

\n

Progressive disclosure

\n

Models are great at navigating filesystems. Presenting tools as code on a filesystem allows models to read tool definitions on-demand, rather than reading them all up-front.

\n

Alternatively, a search_tools tool can be added to the server to find relevant definitions. For example, when working with the hypothetical Salesforce server used above, the agent searches for "salesforce" and loads only those tools that it needs for the current task. Including a detail level parameter in the search_tools tool that allows the agent to select the level of detail required (such as name only, name and description, or the full definition with schemas) also helps the agent conserve context and find tools efficiently.

\n

Context efficient tool results

\n

When working with large datasets, agents can filter and transform results in code before returning them. Consider fetching a 10,000-row spreadsheet:

\n
// Without code execution - all rows flow through context\nTOOL CALL: gdrive.getSheet(sheetId: 'abc123')\n        → returns 10,000 rows in context to filter manually\n\n// With code execution - filter in the execution environment\nconst allRows = await gdrive.getSheet({ sheetId: 'abc123' });\nconst pendingOrders = allRows.filter(row => \n  row["Status"] === 'pending'\n);\nconsole.log(`Found ${pendingOrders.length} pending orders`);\nconsole.log(pendingOrders.slice(0, 5)); // Only log first 5 for review\n
\n

The agent sees five rows instead of 10,000. Similar patterns work for aggregations, joins across multiple data sources, or extracting specific fields—all without bloating the context window.

\n

More powerful and context-efficient control flow

\n

Loops, conditionals, and error handling can be done with familiar code patterns rather than chaining individual tool calls. For example, if you need a deployment notification in Slack, the agent can write:

\n
let found = false;\nwhile (!found) {\n  const messages = await slack.getChannelHistory({ channel: 'C123456' });\n  found = messages.some(m => m.text.includes('deployment complete'));\n  if (!found) await new Promise(r => setTimeout(r, 5000));\n}\nconsole.log('Deployment notification received');\n
\n

This approach is more efficient than alternating between MCP tool calls and sleep commands through the agent loop.

\n

Additionally, being able to write out a conditional tree that gets executed also saves on “time to first token” latency: rather than having to wait for a model to evaluate an if-statement, the agent can let the code execution environment do this.

\n

Privacy-preserving operations

\n

When agents use code execution with MCP, intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return, meaning data you don’t wish to share with the model can flow through your workflow without ever entering the model's context.

\n

For even more sensitive workloads, the agent harness can tokenize sensitive data automatically. For example, imagine you need to import customer contact details from a spreadsheet into Salesforce. The agent writes:

\n
const sheet = await gdrive.getSheet({ sheetId: 'abc123' });\nfor (const row of sheet.rows) {\n  await salesforce.updateRecord({\n    objectType: 'Lead',\n    recordId: row.salesforceId,\n    data: { \n      Email: row.email,\n      Phone: row.phone,\n      Name: row.name\n    }\n  });\n}\nconsole.log(`Updated ${sheet.rows.length} leads`);\n
\n

The MCP client intercepts the data and tokenizes PII before it reaches the model:

\n
// What the agent would see, if it logged the sheet.rows:\n[\n  { salesforceId: '00Q...', email: '[EMAIL_1]', phone: '[PHONE_1]', name: '[NAME_1]' },\n  { salesforceId: '00Q...', email: '[EMAIL_2]', phone: '[PHONE_2]', name: '[NAME_2]' },\n  ...\n]\n
\n

Then, when the data is shared in another MCP tool call, it is untokenized via a lookup in the MCP client. The real email addresses, phone numbers, and names flow from Google Sheets to Salesforce, but never through the model. This prevents the agent from accidentally logging or processing sensitive data. You can also use this to define deterministic security rules, choosing where data can flow to and from.

\n

State persistence and skills

\n

Code execution with filesystem access allows agents to maintain state across operations. Agents can write intermediate results to files, enabling them to resume work and track progress:

\n
const leads = await salesforce.query({ \n  query: 'SELECT Id, Email FROM Lead LIMIT 1000' \n});\nconst csvData = leads.map(l => `${l.Id},${l.Email}`).join('\\n');\nawait fs.writeFile('./workspace/leads.csv', csvData);\n\n// Later execution picks up where it left off\nconst saved = await fs.readFile('./workspace/leads.csv', 'utf-8');\n
\n

Agents can also persist their own code as reusable functions. Once an agent develops working code for a task, it can save that implementation for future use:

\n
// In ./skills/save-sheet-as-csv.ts\nimport * as gdrive from './servers/google-drive';\nexport async function saveSheetAsCsv(sheetId: string) {\n  const data = await gdrive.getSheet({ sheetId });\n  const csv = data.map(row => row.join(',')).join('\\n');\n  await fs.writeFile(`./workspace/sheet-${sheetId}.csv`, csv);\n  return `./workspace/sheet-${sheetId}.csv`;\n}\n\n// Later, in any agent execution:\nimport { saveSheetAsCsv } from './skills/save-sheet-as-csv';\nconst csvPath = await saveSheetAsCsv('abc123');\n
\n

This ties in closely to the concept of Skills, folders of reusable instructions, scripts, and resources for models to improve performance on specialized tasks. Adding a SKILL.md file to these saved functions creates a structured skill that models can reference and use. Over time, this allows your agent to build a toolbox of higher-level capabilities, evolving the scaffolding that it needs to work most effectively.

\n

Note that code execution introduces its own complexity. Running agent-generated code requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid. The benefits of code execution—reduced token costs, lower latency, and improved tool composition—should be weighed against these implementation costs.

\n

Summary

\n

MCP provides a foundational protocol for agents to connect to many tools and systems. However, once too many servers are connected, tool definitions and results can consume excessive tokens, reducing agent efficiency.

\n

Although many of the problems here feel novel—context management, tool composition, state persistence—they have known solutions from software engineering. Code execution applies these established patterns to agents, letting them use familiar programming constructs to interact with MCP servers more efficiently. If you implement this approach, we encourage you to share your findings with the MCP community.

\n

Acknowledgments

\n

This article was written by Adam Jones and Conor Kelly. Thanks to Jeremy Fox, Jerome Swannack, Stuart Ritchie, Molly Vorwerck, Matt Samuels, and Maggie Vo for feedback on drafts of this post.

\n", "content_markdown": "[The Model Context Protocol (MCP)](https://modelcontextprotocol.io/) is an open standard for connecting AI agents to external systems. Connecting agents to tools and data traditionally requires a custom integration for each pairing, creating fragmentation and duplicated effort that makes it difficult to scale truly connected systems. MCP provides a universal protocol—developers implement MCP once in their agent and it unlocks an entire ecosystem of integrations.\n\nSince launching MCP in November 2024, adoption has been rapid: the community has built thousands of [MCP servers](https://github.com/modelcontextprotocol/servers), [SDKs](https://modelcontextprotocol.io/docs/sdk) are available for all major programming languages, and the industry has adopted MCP as the de-facto standard for connecting agents to tools and data.\n\nToday developers routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers. However, as the number of connected tools grows, loading all tool definitions upfront and passing intermediate results through the context window slows down agents and increases costs.\n\nIn this blog we'll explore how code execution can enable agents to interact with MCP servers more efficiently, handling more tools while using fewer tokens.\n\n## **Excessive token consumption from tools makes agents less efficient**\n\nAs MCP usage scales, there are two common patterns that can increase agent cost and latency:\n\n1. Tool definitions overload the context window;\n2. Intermediate tool results consume additional tokens.\n\n### **1\\. Tool definitions overload the context window**\n\nMost MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax. These tool definitions might look like:\n\n```\ngdrive.getDocument\n Description: Retrieves a document from Google Drive\n Parameters:\n documentId (required, string): The ID of the document to retrieve\n fields (optional, string): Specific fields to return\n Returns: Document object with title, body content, metadata, permissions, etc.\n```\n\n```\nsalesforce.updateRecord\n Description: Updates a record in Salesforce\n Parameters:\n objectType (required, string): Type of Salesforce object (Lead, Contact, Account, etc.)\n recordId (required, string): The ID of the record to update\n data (required, object): Fields to update with their new values\n Returns: Updated record object with confirmation\n```\n\nTool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.\n\n### **2\\. Intermediate tool results consume additional tokens**\n\nMost MCP clients allow models to directly call MCP tools. For example, you might ask your agent: \"Download my meeting transcript from Google Drive and attach it to the Salesforce lead.\"\n\nThe model will make calls like:\n\n```\nTOOL CALL: gdrive.getDocument(documentId: \"abc123\")\n → returns \"Discussed Q4 goals...\\n[full transcript text]\"\n (loaded into model context)\n\nTOOL CALL: salesforce.updateRecord(\n\t\t\tobjectType: \"SalesMeeting\",\n\t\t\trecordId: \"00Q5f000001abcXYZ\",\n \t\t\tdata: { \"Notes\": \"Discussed Q4 goals...\\n[full transcript text written out]\" }\n\t\t)\n\t\t(model needs to write entire transcript into context again)\n```\n\nEvery intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.\n\nWith large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.\n\n![Image of how the MCP client works with the MCP server and LLM.](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F9ecf165020005c09a22a9472cee6309555485619-1920x1080.png&w=3840&q=75)\\\nThe MCP client loads tool definitions into the model's context window and orchestrates a message loop where each tool call and result passes through the model between operations.\n\n## **Code execution with MCP improves context efficiency**\n\nWith code execution environments becoming more common for agents, a solution is to present MCP servers as code APIs rather than direct tool calls. The agent can then write code to interact with MCP servers. This approach addresses both challenges: agents can load only the tools they need and process data in the execution environment before passing results back to the model.\n\nThere are a number of ways to do this. One approach is to generate a file tree of all available tools from connected MCP servers. Here's an implementation using TypeScript:\n\n```\nservers\n├── google-drive\n│ ├── getDocument.ts\n│ ├── ... (other tools)\n│ └── index.ts\n├── salesforce\n│ ├── updateRecord.ts\n│ ├── ... (other tools)\n│ └── index.ts\n└── ... (other servers)\n```\n\nThen each tool corresponds to a file, something like:\n\n```\n// ./servers/google-drive/getDocument.ts\nimport { callMCPTool } from \"../../../client.js\";\n\ninterface GetDocumentInput {\n documentId: string;\n}\n\ninterface GetDocumentResponse {\n content: string;\n}\n\n/* Read a document from Google Drive */\nexport async function getDocument(input: GetDocumentInput): Promise {\n return callMCPTool('google_drive__get_document', input);\n}\n```\n\nOur Google Drive to Salesforce example above becomes the code:\n\n```\n// Read transcript from Google Docs and add to Salesforce prospect\nimport * as gdrive from './servers/google-drive';\nimport * as salesforce from './servers/salesforce';\n\nconst transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;\nawait salesforce.updateRecord({\n objectType: 'SalesMeeting',\n recordId: '00Q5f000001abcXYZ',\n data: { Notes: transcript }\n});\n```\n\nThe agent discovers tools by exploring the filesystem: listing the `./servers/`directory to find available servers (like `google-drive` and `salesforce`), then reading the specific tool files it needs (like `getDocument.ts` and `updateRecord.ts`) to understand each tool's interface. This lets the agent load only the definitions it needs for the current task. This reduces the token usage from 150,000 tokens to 2,000 tokens—a time and cost saving of 98.7%**.**\n\nCloudflare [published similar findings](https://blog.cloudflare.com/code-mode/), referring to code execution with MCP as “Code Mode.\" The core insight is the same: LLMs are adept at writing code and developers should take advantage of this strength to build agents that interact with MCP servers more efficiently.\n\n## **Benefits of code execution with MCP**\n\nCode execution with MCP enables agents to use context more efficiently by loading tools on demand, filtering data before it reaches the model, and executing complex logic in a single step. There are also security and state management benefits to using this approach.\n\n### Progressive disclosure\n\nModels are great at navigating filesystems. Presenting tools as code on a filesystem allows models to read tool definitions on-demand, rather than reading them all up-front.\n\nAlternatively, a `search_tools` tool can be added to the server to find relevant definitions. For example, when working with the hypothetical Salesforce server used above, the agent searches for \"salesforce\" and loads only those tools that it needs for the current task. Including a detail level parameter in the `search_tools` tool that allows the agent to select the level of detail required (such as name only, name and description, or the full definition with schemas) also helps the agent conserve context and find tools efficiently.\n\n### Context efficient tool results\n\nWhen working with large datasets, agents can filter and transform results in code before returning them. Consider fetching a 10,000-row spreadsheet:\n\n```\n// Without code execution - all rows flow through context\nTOOL CALL: gdrive.getSheet(sheetId: 'abc123')\n → returns 10,000 rows in context to filter manually\n\n// With code execution - filter in the execution environment\nconst allRows = await gdrive.getSheet({ sheetId: 'abc123' });\nconst pendingOrders = allRows.filter(row => \n row[\"Status\"] === 'pending'\n);\nconsole.log(`Found ${pendingOrders.length} pending orders`);\nconsole.log(pendingOrders.slice(0, 5)); // Only log first 5 for review\n```\n\nThe agent sees five rows instead of 10,000. Similar patterns work for aggregations, joins across multiple data sources, or extracting specific fields—all without bloating the context window.\n\n#### **More powerful and context-efficient control flow**\n\nLoops, conditionals, and error handling can be done with familiar code patterns rather than chaining individual tool calls. For example, if you need a deployment notification in Slack, the agent can write:\n\n```\nlet found = false;\nwhile (!found) {\n const messages = await slack.getChannelHistory({ channel: 'C123456' });\n found = messages.some(m => m.text.includes('deployment complete'));\n if (!found) await new Promise(r => setTimeout(r, 5000));\n}\nconsole.log('Deployment notification received');\n```\n\nThis approach is more efficient than alternating between MCP tool calls and sleep commands through the agent loop.\n\nAdditionally, being able to write out a conditional tree that gets executed also saves on “time to first token” latency: rather than having to wait for a model to evaluate an if-statement, the agent can let the code execution environment do this.\n\n### Privacy-preserving operations\n\nWhen agents use code execution with MCP, intermediate results stay in the execution environment by default. This way, the agent only sees what you explicitly log or return, meaning data you don’t wish to share with the model can flow through your workflow without ever entering the model's context.\n\nFor even more sensitive workloads, the agent harness can tokenize sensitive data automatically. For example, imagine you need to import customer contact details from a spreadsheet into Salesforce. The agent writes:\n\n```\nconst sheet = await gdrive.getSheet({ sheetId: 'abc123' });\nfor (const row of sheet.rows) {\n await salesforce.updateRecord({\n objectType: 'Lead',\n recordId: row.salesforceId,\n data: { \n Email: row.email,\n Phone: row.phone,\n Name: row.name\n }\n });\n}\nconsole.log(`Updated ${sheet.rows.length} leads`);\n```\n\nThe MCP client intercepts the data and tokenizes PII before it reaches the model:\n\n```\n// What the agent would see, if it logged the sheet.rows:\n[\n { salesforceId: '00Q...', email: '[EMAIL_1]', phone: '[PHONE_1]', name: '[NAME_1]' },\n { salesforceId: '00Q...', email: '[EMAIL_2]', phone: '[PHONE_2]', name: '[NAME_2]' },\n ...\n]\n```\n\nThen, when the data is shared in another MCP tool call, it is untokenized via a lookup in the MCP client. The real email addresses, phone numbers, and names flow from Google Sheets to Salesforce, but never through the model. This prevents the agent from accidentally logging or processing sensitive data. You can also use this to define deterministic security rules, choosing where data can flow to and from.\n\n### State persistence and skills\n\nCode execution with filesystem access allows agents to maintain state across operations. Agents can write intermediate results to files, enabling them to resume work and track progress:\n\n```\nconst leads = await salesforce.query({ \n query: 'SELECT Id, Email FROM Lead LIMIT 1000' \n});\nconst csvData = leads.map(l => `${l.Id},${l.Email}`).join('\\n');\nawait fs.writeFile('./workspace/leads.csv', csvData);\n\n// Later execution picks up where it left off\nconst saved = await fs.readFile('./workspace/leads.csv', 'utf-8');\n```\n\nAgents can also persist their own code as reusable functions. Once an agent develops working code for a task, it can save that implementation for future use:\n\n```\n// In ./skills/save-sheet-as-csv.ts\nimport * as gdrive from './servers/google-drive';\nexport async function saveSheetAsCsv(sheetId: string) {\n const data = await gdrive.getSheet({ sheetId });\n const csv = data.map(row => row.join(',')).join('\\n');\n await fs.writeFile(`./workspace/sheet-${sheetId}.csv`, csv);\n return `./workspace/sheet-${sheetId}.csv`;\n}\n\n// Later, in any agent execution:\nimport { saveSheetAsCsv } from './skills/save-sheet-as-csv';\nconst csvPath = await saveSheetAsCsv('abc123');\n```\n\nThis ties in closely to the concept of [Skills](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview), folders of reusable instructions, scripts, and resources for models to improve performance on specialized tasks. Adding a SKILL.md file to these saved functions creates a structured skill that models can reference and use. Over time, this allows your agent to build a toolbox of higher-level capabilities, evolving the scaffolding that it needs to work most effectively.\n\nNote that code execution introduces its own complexity. Running agent-generated code requires a secure execution environment with appropriate [sandboxing](https://www.anthropic.com/engineering/claude-code-sandboxing), resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid. The benefits of code execution—reduced token costs, lower latency, and improved tool composition—should be weighed against these implementation costs.\n\n## **Summary**\n\nMCP provides a foundational protocol for agents to connect to many tools and systems. However, once too many servers are connected, tool definitions and results can consume excessive tokens, reducing agent efficiency.\n\nAlthough many of the problems here feel novel—context management, tool composition, state persistence—they have known solutions from software engineering. Code execution applies these established patterns to agents, letting them use familiar programming constructs to interact with MCP servers more efficiently. If you implement this approach, we encourage you to share your findings with the [MCP community](https://modelcontextprotocol.io/community/communication).\n\n### Acknowledgments\n\n*This article was written by Adam Jones and Conor Kelly. Thanks to Jeremy Fox, Jerome Swannack, Stuart Ritchie, Molly Vorwerck, Matt Samuels, and Maggie Vo for feedback on drafts of this post.*\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2026-04-23T00:00:00+00:00", "date_modified": null, "date_published": "2026-04-23T00:00:00+00:00", "description": "As agents grow more capable, so does their potential blast radius. The engineering question is how to cap it. Here’s what we’ve learned building containment for claude.ai, Claude Code, and Cowork.", "external_url": "https://www.anthropic.com/engineering/code-execution-with-mcp", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/anthropic-com/2026/04/2026-04-23-code-execution-with-mcp-building-more-efficient-agents.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/anthropic-com/2026/04/2026-04-23-code-execution-with-mcp-building-more-efficient-agents.md" }, "id": "urn:aggr:item:15d65302b7334f3bd7e1a14b0a08e3d629b22860", "isBasedOn": { "@id": "https://www.anthropic.com/engineering/code-execution-with-mcp" }, "mainEntity": { "@id": "https://www.anthropic.com/engineering/code-execution-with-mcp", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/anthropic-com/2026-04-23-code-execution-with-mcp-building-more-efficient-agents/#webpage" }, "datePublished": "2026-04-23T00:00:00+00:00", "headline": "Code execution with MCP: Building more efficient agents", "timeRequired": "PT9M", "url": "https://www.anthropic.com/engineering/code-execution-with-mcp", "wordCount": 1899 }, "name": "Archived snapshot: Code execution with MCP: Building more efficient agents", "preview": null, "reading_minutes": 9, "replicated_at": null, "source": "anthropic-com", "source_name": "Engineering \\ Anthropic", "summary": "As agents grow more capable, so does their potential blast radius. The engineering question is how to cap it. Here’s what we’ve learned building containment for claude.ai, Claude Code, and Cowork.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Code execution with MCP: Building more efficient agents", "url": "https://aggr.aymericbeaumet.com/items/anthropic-com/2026-04-23-code-execution-with-mcp-building-more-efficient-agents/", "word_count": 1899 }