Code execution with MCP: Building more efficient agents

[cliffhall]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Direct tool calls consume context for each definition and result. Agents scale better by writing code to call tools instead. Here's how it works with MCP.

This is the topic of a recent blog post from Anthropic. Please share your thoughts and experiences here!

[scottyak-datadog]

While I appreciate the attempt to address the context clogging issue caused by always putting the tool response into the LLM context window, it seems to me that the code execution post is primarily dealing with tools that are essentially "API wrappers" that produce structured data, but not tools that also attempt to guide the MCP client with additional instructions and metadata. The layering blog post has been pretty influential to MCP server developers. Some MCP server developers now expect that they can "guide" the MCP client with next steps, query refinements, error responses, and so on. In other words, the response payload is a channel for both "instructions" and "data". By bypassing the LLM context window entirely, MCP servers become no more than APIs. I think this would be a step backwards -- there are MCP servers, that with "guiding instructions", produce a "magical" experience.

What I would like to propose is a pattern to give MCP tools two output channels:

1. (What we have today) An instruction or metadata channel that is unstructured, and is meant to be placed directly into the LLM context window., and
2. (What we don't really have today) A data channel for structured data that is meant to be read by programs.

I think the MCP protocol today already contains the ingredients for MCP servers to implement this pattern:

1. For data querying tools, return a Resource Link. The description can be used to provide the instruction that is meant to guide the LLM.
2. The MCP client then programmatically reads the resource using the resource read capability. The resource description field can contain instructions for how to parse this data, schema, size hints, etc. The output of resource-read is the data.

But what is still missing is that the MCP client needs to know that that resource can be read programmatically, not fed into the LLM context window.

Edit: Perhaps there can be a short list of mime-types that can MCP clients can choose to hardcode and say "we will always use code execution to read (say) text/csv or application/json"

Edit 2: Added a link to the "layering" blog post.

[chipgpt]

OpenAI apps do something like this where structuredContent is passed into the rendered UI but not the LLM, and content is used for the text that goes to the LLM.

However, when using the mcp inspector in the past, it complained when structuredContent and content are not the same in the tool response. This made me feel like they are expected/supposed to be the same.

[cliffhall]

when using the mcp inspector in the past, it complained when structuredContent and content are not the same in the tool response. This made me feel like they are expected/supposed to be the same.

Yep, you are correct. I remember accepting the PR that shows the indicator when there is a disparity. That is how we interpret the spec, which says:

• Structured content is returned as a JSON object in the structuredContent field of a result.
• For backwards compatibility, a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block.

However, the OpenAI Apps SDK certainly strikes out on its own in this respect. They use structuredContent as a way to pass data to the widget. I would rather they have used _meta for that as they do for the data about the widget, and stuck to having content and structuredContent be used for informing the model.

I expect the guidance on these fields to change in time.

[scottyak-datadog]

Oh interesting, thanks for the additional context on structuredContent and _meta field.

With the _meta field, I propose an even simpler implementation for this "two channel" pattern:

• Tools that can output large structured data (e.g., search_logs) also accept an extra field use_data_channel: bool (we can gate this to MCP clients that pass in a special HTTP header so that MCP clients that don't know about this feature don't get confused).
• When called with use_data_channel=true, search_logs would return metadata (like length and columns found) and instructions in the text content of the ToolResult, but the structured data itself would be placed in _meta: { data_channel: { schema: ..., data: ... } }. This way, MCP hosts can add the "instructions" to the LLM context window and the MCP host can parse the data, maybe put it in an in-memory file, write code, and execute code that uses that in-memory file in a subprocess, put the code execution result into the LLM context window, and continue.
• When called with use_data_channel=false, search_logs will do what it normally does -- place both the instructions and data in their respective xml tags, but all in the text content of the ToolResult.

Thus, the tool behaves exactly the same for MCP clients that don't know about this data channel, while MCP hosts that know about this channel can take advantage of it using code execution.

(The reason why I don't really want to use structuredContent and outputSchema is that if most of our MCP clients are just going to dump everything into the context window without taking advantage of the schema, then outputSchema would just waste tokens in the context window for most clients)

(I might give this a shot)

Edit: Realized that we should not use HTTP headers to let the MCP client declare to the MCP server that it knows about the data channel, because MCP is supposed to operate above the transport layer. Instead, during initialization, the MCP client should declare it has the experimental: { data_channel: {} } capability. That way, the MCP server would know that it can send data in the _meta: { data_channel: { schema: ..., data: ... } } instead of the ToolResult text payload. Perhaps the tool itself does not even need to expose the use_data_channel: bool param -- the MCP server could assume that any MCP client that declares the data_channel capability should know where to find the data, and the MCP host can decide for itself whether to put the data into the LLM context without involving the tool.

[willpocknell-insight]

I was going to suggest something similar, essentially allow data between tool calls to be passed by reference rather than value by the LLM in the MCP client. This would allow for efficiently passing data between sequential tool calls where the intermediate data isn't of interest, only the final output. This has identified an area to expand the protocol, not circumvent it via the code execution route.

[scottyak-datadog]

Pass by reference, interesting idea. This would require the MCP Host to know that a certain part of the MCP server's payload is not meant to be passed into the LLM context window. When the LLM generates the tool call that references this data, perhaps the LLM could output the tool call with a placeholder, then the MCP Host programmatically substitutes the placeholder with the referenced data before actually making the tool call.

I was also considering whether the reference itself (e.g. the resource url) could be passed as the tool call, but realized that the other tool would not have the credentials to access the resource, so the MCP Host needs to be the one getting the data and sending it to the other tool. But going through the MCP Host programmatically is already a lot faster than going through the LLM context!

[cliffhall]

From the blog post

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.

What's missing from a folder of sometool.ts files is the tool description, which can give details about when to use the tool. This approach places a lot of descriptive burden on the tool name.

[xwhysi]

I’m a developer deeply involved in building agents using MCP. One recurring challenge I’ve faced is that we often need to feed the entire MCP tool response back into the prompt, which isn’t always optimal and can be wasteful in terms of tokens.

That’s why the recent “Code Execution with MCP” post caught my attention, which seems like a promising direction to address this inefficiency.

After reading it, I had some thoughts and questions about the core idea. The post suggests letting the agent write and execute code to interact with MCP servers. This effectively adds a post-processing step to transform or filter the MCP tool results before passing them back to the LLM.

In my own work, I’ve approached a similar problem a bit differently:

• Dynamic tool loading: The agent dynamically decides which MCP tools to load based on context. It only needs to know which tools are relevant, not their full input/output schemas.
• Custom interception logic: I intercept MCP tool results in code and apply custom logic per tool when needed. In other words, I define bespoke handling logic within the agent for specific MCP tools.

With this setup, I can achieve the same goal, efficient post-processing of MCP responses but without spinning up a separate virtual environment or executing LLM-generated code, which can add unnecessary overhead.

I wanted to share this approach with the community to get feedback:
Where might I be missing something compared to the “Code Execution with MCP” solution?
Are there hidden advantages to letting the LLM generate and run code for this, beyond flexibility?
For additional context, I control both the agent and the MCP implementation, so I can ensure stable tool schemas, which my approach relies on.

[Aryan863]

How are you dynamically loading tools? If you explain the approach in detail, we can more easily compare the pros and cons of each method.

[anouar-bm]

I think it's difficult since the llm at the beginning should know the definition of each tool (loading it in context ), or if the user specifically mentions to use tool_1 or tool_2 the load it ( the cons it will not be fully agentic )
what do you think @xwhysi ?

[xwhysi]

@Aryan863

How are you dynamically loading tools? If you explain the approach in detail, we can more easily compare the pros and cons of each method.

Not very fancy, just provide high level context of tools to LLM and basically ask "is this tool relevant to this query?", then rebuild the context with tools which are "selected" and call again.

[xwhysi]

I think it's difficult since the llm at the beginning should know the definition of each tool (loading it in context ), or if the user specifically mentions to use tool_1 or tool_2 the load it ( the cons it will not be fully agentic ) what do you think @xwhysi ?

@anouar-bm, I have multiple MCP servers and each might be in a specific "domain", mostly I just first ask LLM to decide the relevance of each MCP servers/tools (with only a high level description) to current context and only load selected ones

[woweow]

I'm reading the article about code execution. The article talks about an agent using slack and gsuite APIs. How are you supposed to give the agent access to those services? Would you set up your env like any other server with slack and gsuite keys and then an example usage and then tell the agent to follow the precedent set by your example?

Secondly, it says that the MCP client intercepts PII data. These clients are like cursor and Claude code right? How can these 1) be validated that the do this implementation correctly and 2) accurately and deterministically identify which data is PII in the first place?

[mxcoppell]

I got confused when reading this article and would like to have some clarification:

• The article mixed the concept of agent and MCP clients. an Agent could have multiple MCP clients to connect to different MCP services.
• The "short-term memory" of an agent is the context we are trying to manage.
• How do the models used by the agent know what tools are available when trying to generate code to execute the tools?
• It's natural for the agent to have local tools or code logic to preprocess the data returned by the MCP tools before feeding the tool responses back to the agent's memory context. This is nothing new, it's agent memory management to only keep the relevant data that matters to next inference API call to be sent to the model.

What exactly are the points this article trying to make?

[xbiggyl]

Tbh, I'm not really sure where to start af how to implement it in my own projects. I'd appreciate if someone can point to any additional resources (if and when they're available).

[sudhanva99-cpu]

Post reading the blog, have some follow-up questions.

• When the code gets written, by whom and how we ensure it doesn't violate any security issues ?Are there recommended best practices or patterns for validating dynamically generated code ?

• The Anthropic article focuses on code generation during agent build time, where code is tested before deployment. In our case, MCP servers would be connected dynamically at runtime. How does MCP recommend handling code generation in dynamic runtime scenarios where pre-validation isn’t possible?

[cliffhall]

How does MCP recommend handling code generation in dynamic runtime scenarios where pre-validation isn’t possible?

AFAIK, MCP isn't recommending any particular approach. Code execution is meta to MCP. A server exposes tools, and you either let the LLM call them one at a time or you can have it write some code that calls them from an execution environment in a sort of batch mode. Either way, the server doesn't know or care how a tool is called. IMHO, the protocol spec should not venture into the area of opining on code execution strategies.

That said, if I personally wanted to reduce the number of tokens it takes for an agent to complete a given multi-tool workflow using code execution, I think I'd want to do that in a development sandbox, try different models, see which one generates the best code by applying some evals, and then have the agent reuse the best code from a library. You perhaps even write an MCP server that has a tool that serves optimized code snippets for executing workflows. Or even get really wacky and write the code yourself.

But having the LLM generate code on the fly for accessing arbitrary MCP servers seems... risky. Individual tool selection and calling already has a certain amount of non-determinism associated with it. This strategy would seem to amplify that.

[stevejmonk]

I just incorporated this model into an AI agent I’m building and training, i have built 7 tools, it’s working well for any GET type request, but when i try to get it to POST, the Llm refuses to call the tool and lies about it. i watched my coding AI sonnet 4.5 and my agent using gpt 4 mini arguing over it, it got to the point where my coding AI wrote a new system prompt for the bot in all caps! eventually i had to step in and break it up. Anyway if anyone can explain why the Llm refuses a direct instruction to trigger a POST using an MCP2.0 tool please tell.

[cliffhall]

How does the LLM even know that the tool will do a POST?

[sangemaru]

@stevejmonk , how did you set up the code execution environment? My own agents are spinning around in circles, telling me to call Anthropic and to ask about it.

[pietrozullo]

Hey guys! Just wrote code_mode support for MCP in our client https://github.com/mcp-use/mcp-use if you want to try it out and check out the implementation.
So far, it works great, I have a few open questions I am trying to address:

• in one use case I am tryin to solve a tool returns a humongous JSON, I wonder if the models will be able to navigate this better thanks to code mode (similar to @xwhysi problem)
• security wise: should the client be run in a sandbox if the client allows arbitrary code execution in the execute code tool (right now it does not, but it restricts imports)
• how about having a code mode in the server ?

[olaservo]

I also built a working implementation of this pattern (using the Claude Agent SDK) and ran a few experiments comparing code execution vs direct MCP on real-world GitHub issue analysis tasks: https://github.com/olaservo/code-execution-with-mcp

The Readme includes a full breakdown of my first experiments. tldr; version:

Large Dataset (5,205 issues):

• Code execution: 100% success (5/5 runs)
• Direct MCP: 0% success (5/5 runs, context overflow)

Small Dataset (45 issues):

• Code execution: 3.5× faster, 67% cheaper
• Direct MCP: Still worked but significantly less efficient

Re: @scottyak-datadog's concern about losing "guiding instructions:" this seems to be a valid point. This approach seems best for data-heavy operations where structured data processing matters more than iterative guidance.

[rkondra-eightfold]

Critique: Code Execution vs. Native Introspection & Schema Standards

I read the Code Execution with MCP article and wanted to share some thoughts. While it tries to address the very real problem of context window bloat, the proposed solution ("Code Execution" via virtual filesystems) feels somewhat "handwavy" and introduces unnecessary complexity for problems that could be solved more elegantly within the protocol itself.

Here are a few specific critiques and alternative proposals:

1. Code Execution is a Heavy Abstraction for Discovery

The article proposes mapping MCP servers to a local file system so agents can "discover" tools by listing directories and reading files. This feels like a workaround. An intelligent agent can already dynamically determine which servers to use based on high-level server descriptions. (i.e. we could say, ask LLMs which servers to use based on description for the task at hand and only discover tools on those servers ... ) We shouldn't need a code execution sandbox just to perform progressive disclosure of tools.

2. A Better Alternative: "GraphQL-style" Introspection

Instead of forcing the LLM to write code to discover tools from each server, a better protocol-level solution would be a standardized, layered introspection flow (similar to GraphQL):

Level 1 (Discovery): The client requests a lightweight list of tools containing only names and descriptions. This is cheap and fits in context.

Level 2 (Definition): The agent identifies relevant tools and requests the specific Input/Output schemas and annotations for only those tools.

Level 3 (Execution): The agent constructs the plan or call.

This achieves the same token savings as the article's method but keeps the architecture deterministic and cleaner.

3. The "Output Schema" Gap

The article's code examples rely on the agent knowing the shape of the return data (e.g., accessing .content or .rows on a result).

const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;

However, Output Schemas are not yet a standard in MCP. Without a strict, enforceable contract on what a tool returns, asking an LLM to write code against that return value is incredibly brittle. The model is essentially guessing property names. Whether we use "Code Mode" or standard tool calling, we first need standardized Output Schemas to make reliable agentic workflows possible.

[Edit] Adding to this

4. Filesystem Abstraction Imposes an Artificial Model
   Mapping servers → folders and tools → files forces a hierarchical structure that doesn’t match how MCP servers actually behave (dynamic tools). It solves a problem by introducing a less accurate abstraction.

For instance in our MCP server for SaaS product, we list_tools dynamically based on users' role and access ...

5. More Complexity for MCP Clients
   To adopt the approach, every client now has to build and secure a sandbox, sync tools to files, handle code execution, and pipe errors back to the model, a lot of complexity for something introspection APIs could solve far more cleanly.

[AbhinavMalkoochi]

I've been following the discussion and agree with most of the points made here. In case anyone wanted to try, I developed a basic implementation of the blog here: https://www.npmjs.com/package/@abmalk/mcpcode. Looking for any suggestion on improving it, adding functionality, and thinking of ways to improve the idea. It discovers servers, collects tools/schemas, and generates input and output typescript interfaces.

[ltcompounder]

does this implementation have sandboxing or some way to prevent against the likes of prompt injection and permission modification?

[DaSchTour]

I think the code execution through MCP is somehow strange to me. It feels like an even bigger nightmare to develop remote code execution. For me there are also two very different use cases for MCP. One very important is to connect applications like Jira, Google Suite and so on through OAuth to a Web Client. I'm not sure how this is expected to work then.
One other use case is having MCP used locally for example in Claude Code. There it is a bit different. I recently for example switch from using Gitlab through MCP to using Gitlab CLI. But I doubt we will create CLI tools for everything, although there is something for Jira I'm not sure if that would work great in Claude Code.

But just going from how we humans work and keep our context clean is through "partial discovery". When using a CLI tool I don't know I get get a "cmd help" to get the basics with all possible sub commands. Then there is a "cmd tool help" that returns the details for a given tool.
The same could be done for MCP. Instead of putting everything always into context it could be done in steps. So If I have an MCP for Github it could have something like tool groups and only load the basics into the context. And then if a certain tool group is needed then this could be loaded into the context and reveal either further groups or certain tools. And the tools are only loaded with the description and not all parameters.
I have the impression that this is mainly an issue of how MCP-Clients are handling MCP-Servers and how they are presented to the LLM and when and how they are part of the context.

[mattarderne]

I found this blog interesting, I wanted to validate getting this working locally (without MCP...), and to run it on a tiny local models. I thought to share my notes for what it may be worth to someone.

https://rdrn.dev/ai-agents/

What I found really interesting is that the tool definition and ergonomics seemed to matter a lot, and the best way to make them effective was to make them obvious. This felt like the only way to scale the tools so that you could run progressive discovery

Example of "obvious" tools:

plan(prompt: str) -> list[str]      # string in, list out
write(prompt: str) -> str           # string in, string out
combine(contents: list[str]) -> str # list in, string out

When plan() returns list[str], the model knows it needs to iterate. When combine() takes list[str], the model knows to collect results. The generated code became correct without explicit patterns

This made the code composition much more reliable for small models, and to me this was the most interesting aspect of the original blog from Anthropic: that you could chain together tools, and the orchestrator model never sees the content of each tool call (unless needed).

[jancurn]

Hey all, few days ago I've launched mcpc, a new universal CLI client for MCP.

Among other things, it supports JSON output mode (--json) to enable integration with other CLI tools like jq, scripting, and code mode in shell. Here's an example of Claude Code-generated script that uses mcpc --json.

Thanks to schema validation (--schema) you can ensure the generated code fails fast on incompatible schema changes. And the --proxy option creates an MCP server proxy, so that you can securely use authenticated MCP sessions from AI code sandboxes without sharing credentials.

We will add generation of TypeScript server stubs soon to enable code mode also in TS.

I think you might find it interesting...

[BobDickinson]

It's interesting to see the different responses and solutions around Code Mode. My take was that I saw the problem in my use cases and I liked the idea, but I didn't like the "code" part, so I built an MCP-based solution for agents to build directed graphs to compose and orchestrate tool calls: https://github.com/TeamSparkAI/mcpGraph. I refer to is as "No Code Code Mode".

[jsaldanaperez]

Adding empirical observations to this thread, alongside @olaservo's benchmark above. I built a harness reproducing the patterns from the post across 3 languages × 2 models × 2 spec shapes, using a code-generation MCP as the test workload. Two patterns stood out. (Disclosure: I build MetaEngine, the MCP code-generation server used here as the workload — it's the test surface, not the focus of this comment.)

First pattern: when the MCP returns many artifacts in one call, the agent loop runs 11–15× shorter than a Write-tool loop emitting one file per turn — independent of how the agent constructs the call.

Second pattern: this matches the article's prediction directly. Instead of inlining the spec into the tool call, the agent writes a Python script that produces the input file at runtime, then calls the MCP with a file path. Output tokens drop ~70–77%, wall-clock roughly halves. The mechanism: tool_use input bytes are billed as output tokens, so routing data through disk avoids that channel.

To test, I used a two-session setup per run: a warmup session reads the MCP's documentation and writes a knowledge brief; a generation session uses that brief and does the actual work. This gives a clean phase split — the one-time cost of teaching the model how the MCP works vs the per-codebase cost of using it. Tests ran on Opus 4.7 and Sonnet 4.6, across two spec shapes (uniform DDD and modular-monolith).

Findings writeup: https://github.com/meta-engine/mcp-server/blob/main/benchmark/FINDINGS.md

My observations are not claims — I'm not a researcher, and the tests I can run on a single account are limited. So for the sake of being pragmatic, I built a harness as the contribution so that anyone can reproduce it themselves.

Harness: https://github.com/meta-engine/mcp-server/tree/main/benchmark

The harness's spec tops out at ~70 entities (within MetaEngine's current 100-type request limit). If anyone wants larger-N reproduction or larger spec sizes on specific cells, I can fund a higher-tier window — bounded, no strings.

Kind regards,
José

[caioribeiroclw-pixel]

One invariant I would add to code-mode implementations is an auditable boundary record for context routing, not raw data logging.

Code mode creates at least four different states that are easy to blur:

1. a schema/API was discovered by the model
2. large data was read inside the execution environment but intentionally kept out of model context
3. model-generated code/arguments executed against MCP tools
4. only some result/output was promoted back into the next model turn

A small receipt per run could make that explicit without storing private payloads:

{
  "loadedApis": [{ "server": "github", "tool": "listIssues", "schemaHash": "sha256:...", "sourceRef": "..." }],
  "dataReads": [{ "resource": "issues", "bytes": 184203, "contentHash": "sha256:...", "modelVisible": false }],
  "generatedCode": { "hash": "sha256:...", "sandbox": "...", "allowedImports": ["..."] },
  "toolCalls": [{ "server": "github", "tool": "listIssues", "argsHash": "sha256:..." }],
  "promotedOutputs": [{ "fromCall": "...", "contentHash": "sha256:...", "tokenSpan": [1200, 1450], "truncated": false }],
  "rejectedPromotions": [{ "fromCall": "...", "reason": "pii|untrusted-instruction|too-large" }]
}

That would help with two concerns raised in this thread:

• channel separation: the client can prove what stayed machine-readable data vs what became model-visible text;
• auditability/security: the risky object is no longer just the original tool output, but also the generated code + final tools/call arguments + the subset of output promoted back into context.

Without this boundary record, code mode can reduce token bloat while making context routing less inspectable. With it, implementations can say: “the model saw these schemas, did not see this large/private data, executed this code/args, and only this hashed/truncated result crossed back into the model.”