Architecture for MCP Code Execution Mode - Client-Side vs Server-Side

[L0Lmaker]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

Note: I've searched existing discussions and found only #627
(MCPProxy) which is related but addresses a
different approach (server-side orchestration rather than client-side virtualization).

Context

Anthropic's recent blog post describes a powerful pattern for interacting with MCP tools through generated code instead of sequential tool calls, achieving up to 98.7% token reduction (150k → 2k tokens).

The blog describes presenting MCP tools as a virtual filesystem that agents can explore:

servers/
├── google-drive/
│   ├── getDocument.ts
│   └── uploadFile.ts
└── salesforce/
    └── updateRecord.ts

Agents progressively discover tools by exploring this structure, reading only the definitions they need, then generating code that imports and calls multiple tools efficiently.

However, the blog post doesn't specify where this should be implemented. I see two possible architectures, each with significant trade-offs. I'd like the community's input on which makes more sense.

Option 1: Client-Side Execution (What Blog Appears to Describe)

Architecture

┌─────────────────────────────────────┐
│   MCP Client (Claude Code, etc.)    │
│  ┌────────────────────────────────┐ │
│  │  Execution Environment         │ │
│  │  - Sandboxed Python/TypeScript │ │
│  │  - Virtual filesystem layer    │ │
│  │  - Generates .ts wrappers      │ │
│  └────────────────────────────────┘ │
│            ↓ MCP Protocol            │
└─────────────────────────────────────┘
         ↓           ↓           ↓
   [MCP Server A] [MCP Server B] [MCP Server C]

How It Works

1. Client calls tools/list on all connected servers, caches metadata locally
2. Client creates virtual filesystem mapping servers → directories, tools → .ts files
3. Agent explores filesystem (ls servers/, cat servers/google-drive/getDocument.ts)
4. Agent generates code: from servers.google_drive import getDocument
5. Code executes in client's sandbox, calls callMCPTool() which routes to actual MCP servers
6. Results processed locally before returning to LLM

Pros

✅ MCP servers unchanged - works with all existing servers
✅ Client controls security - single sandbox implementation
✅ Cross-server coordination - code can orchestrate multiple servers
✅ Privacy by default - data processing happens client-side
✅ Solves token problem - only loads needed tool definitions

Cons

❌ Every client reimplements - fragmentation across Claude Code, Desktop, third-party clients
❌ Complex client-side - execution environment, sandboxing, security
❌ No standardization - different virtual filesystem structures per client
❌ Heavy client - not suitable for lightweight integrations

Option 2: Server-Side Execution (Alternative)

Architecture

┌──────────────────────┐
│   MCP Client         │
│   (unchanged)        │
└──────────────────────┘
          ↓ MCP Protocol
┌─────────────────────────────────────┐
│   MCP Server with Code Execution    │
│  ┌────────────────────────────────┐ │
│  │  Execution Environment         │ │
│  │  - Sandboxed runtime           │ │
│  │  - Direct tool access          │ │
│  │  - Local data processing       │ │
│  └────────────────────────────────┘ │
│  Tools: [getDocument, uploadFile]   │
└─────────────────────────────────────┘

How It Works

1. Server exposes new tool: execute_code(language: str, code: str)
2. Client sends code to server via normal tools/call
3. Server executes in its own sandbox with direct access to its tools
4. Server processes data locally, returns results
5. Works with current MCP clients (no client changes)

Pros

✅ Works with current clients - just another MCP tool
✅ Server controls security - sandbox near the data
✅ No client fragmentation - standardized tool interface
✅ Lightweight clients - web apps, CLI tools work unchanged
✅ Better for privacy - data never leaves server

Cons

❌ Every server must implement - execution environment, sandboxing
❌ Security burden on server devs - harder to get right
❌ Can't coordinate across servers - each executes in isolation
❌ Doesn't solve token problem - still need all tool definitions upfront (unless combined with client-side caching)

Hybrid Approach?

Could we combine both?

1. Client-side caching + virtual filesystem - solves token problem via progressive discovery
2. Optional server-side execution - servers can expose execute_code for data-heavy operations
3. Client routes intelligently - run simple operations client-side, heavy operations server-side

Questions for the Community

1. Which architecture makes more sense for the MCP ecosystem?

2. Should this be standardized?

   • Protocol-level (part of MCP spec)
   • Convention-based (recommended patterns)
   • Leave it to client implementations

3. How do we avoid fragmentation?

   • If client-side: reference implementation? shared library?
   • If server-side: standard execution API? security guidelines?

4. What about the token efficiency problem?

   • Client-side naturally solves it (progressive discovery)
   • Server-side doesn't help unless client also caches metadata
   • Is this even the right problem to solve?

5. Security considerations?

   • Who should manage sandboxing? Clients or servers?
   • What are the risks of each approach?
   • Should there be execution policy configuration?

6. Backwards compatibility?

   • How do we ensure existing tools/clients continue working?
   • Should traditional tool calling remain the default?

My Current Thinking

I'm leaning toward Option 1 (client-side) because:

• Solves the token efficiency problem directly
• Works with all existing MCP servers immediately
• Enables cross-server orchestration
• Aligns with the blog post's examples

But I'm concerned about:

• Fragmentation if every client implements differently
• Could we have a reference implementation or shared library?
• Should the MCP spec provide guidance on virtual filesystem structure?

What does the community think? Has anyone started implementing this? Are there other approaches I'm missing?

Why I'm Asking

For my own MCP server, I need to know which of these architectures are on the roadmap so I can understand how I need to write my server to comply with it (if its server based). Just want to understand the direction of the ecosystem before investing development time.

My goals with this discussion:

1. Understand what's already being worked on - Is anyone actively implementing this?
2. Avoid duplicate effort - Don't want to start something that's already underway
3. Align with the ecosystem - Want to build MCP servers that work well with whatever approach gets adopted

Have I Missed Something?

I've searched the following repositories and found no public implementations or discussions:

• ✅ anthropics/claude-code, claude-agent-sdk-python, claude-agent-sdk-typescript
• ✅ modelcontextprotocol/typescript-sdk, python-sdk, specification
• ✅ Existing discussions (only found #627 MCPProxy which addresses a different approach)

If there are existing implementations, documentation, or active development efforts I've missed, please point me in the right direction! The last thing I want is to duplicate work or miss ongoing efforts.

References

• Blog post: https://www.anthropic.com/engineering/code-execution-with-mcp
• Related: MCPProxy discussion

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[Dumbris]

I’d like to propose a third option: executing code on the middleware itself - a design that mcpproxy implementation already realizes.

Today, the widely adopted pattern is to use an MCP proxy or gateway: clients access tools via standardized middleware methods like search_tools and execute_tool. That works well. However,  the middleware could present a virtual filesystem abstraction. I'm not sure that this filesystem-like semantics gives any advantages.

Meanwhile, the middleware maintains connections to upstream MCP servers (local and remote).

If code execution is implemented at the middleware level, then clients can compose tools from different servers seamlessly. There’s no need to change the client or server: everything works through the unified MCP protocol and middleware orchestration. This, to me, represents the most flexible and scalable architecture for multi-tool/multi-server workflows.