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.

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?

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?

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).

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 ?

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.

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.

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.

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).

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...

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".

Semantic Routing as an Alternative to Code Execution for MCP Efficiency

Really interesting thread. We've been working on this exact problem from a different angle with OneConnecter.

Rather than having agents write code to post-process MCP results, we route queries semantically before they hit any MCP server. The agent sends a natural language query to a single endpoint, and we:

1. Match to the right service agent using vector similarity (e.g. "Premier League standings" → sports_data_agent at 0.88 similarity)
2. Return only the relevant tools — typically 1-3 tools instead of the full server manifest
3. Execute and return structured JSON — no HTML parsing, no noise

Real-world token savings

We tested the same query ("Premier League top scorers") via web search vs OneConnecter:

That's a 95% token reduction — not from post-processing, but from never loading the irrelevant context in the first place.

How it relates to this discussion

The dynamic tool loading point raised earlier in this thread resonates strongly:

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.

This is exactly the approach we took. Instead of exposing 100+ tool definitions across 30+ service agents and letting the LLM figure it out (burning context on every definition), we use semantic vector matching to surface only what's needed per query.

The complexity concern is also valid:

Every client now has to build and secure a sandbox, sync tools to files, handle code execution, and pipe errors back to the model.

With semantic routing, there's no sandbox, no code generation, no execution environment. One MCP endpoint, one queryData call, structured response back. Works with Claude, LangChain, and any MCP-compatible client.

Architecture

User Query → Semantic Router → Matched Agent → Relevant Tools (1-3) → Execute → Structured JSON

vs the current pattern:

User Query → Load ALL tool definitions → LLM selects tool → Execute → Raw response → LLM parses

We're running this across 30+ service agents (Notion, GitHub, Airbnb, financial data, sports, jobs, etc.) through a single MCP endpoint at api.oneconnecter.io.

Happy to share more detail on the routing architecture if anyone's interested.

OneConnecter — Semantic routing layer for MCP. One endpoint, structured data, 95% fewer tokens.

Really interesting thread. We've been working on this exact problem from a different angle with [OneConnecter](https://oneconnecter.io).

Rather than having agents write code to post-process MCP results, we route queries semantically before they hit any MCP server. The agent sends a natural language query to a single endpoint, and we:

1. Match to the right service agent using vector similarity (e.g. "Premier League standings" → sports_data_agent at 0.88 similarity)
2. Return only the relevant tools — typically 1-3 tools instead of the full server manifest
3. Execute and return structured JSON — no HTML parsing, no noise

Real-world token savings

We tested the same query ("Premier League top scorers") via web search vs OneConnecter:

That's a 95% token reduction — not from post-processing, but from never loading the irrelevant context in the first place.

How it relates to this discussion

The dynamic tool loading point raised earlier in this thread resonates strongly:

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.

This is exactly the approach we took. Instead of exposing 100+ tool definitions across 30+ service agents and letting the LLM figure it out (burning context on every definition), we use semantic vector matching to surface only what's needed per query.

The complexity concern is also valid:

Every client now has to build and secure a sandbox, sync tools to files, handle code execution, and pipe errors back to the model.

With semantic routing, there's no sandbox, no code generation, no execution environment. One MCP endpoint, one queryData call, structured response back. Works with Claude, LangChain, and any MCP-compatible client.

Architecture

User Query → Semantic Router → Matched Agent → Relevant Tools (1-3) → Execute → Structured JSON

vs the current pattern:

User Query → Load ALL tool definitions → LLM selects tool → Execute → Raw response → LLM parses

We're running this across 30+ service agents (Notion, GitHub, Airbnb, financial data, sports, jobs, etc.) through a single MCP endpoint at api.oneconnecter.io.

Happy to share more detail on the routing architecture if anyone's interested.

[OneConnecter](https://oneconnecter.io) — Semantic routing layer for MCP. One endpoint, structured data, 95% fewer tokens.