Applying "Code Execution with MCP"

[technicalpickles]

Anthropic published this last week: https://www.anthropic.com/engineering/code-execution-with-mcp

I think mcpproxy addresses some of high level things it calls out:

Most MCP clients load all tool definitions upfront directly into context, exposing them to the model using a direct tool-calling syntax.
a search_tools tool can be added to the server to find relevant definitions.

It doesn't address:

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

I'm not sure what form this would take, but wanted to bring it to y'all attention.

[Dumbris]

@technicalpickles Thanks for drawing my attention to this post - super helpful context.

On the first point: yeah, it’s nice that we already cover the "search_tools / retrieve_tools" angle.

The second part of the Anthropic article - using a real programming language to compose MCP tool calls inside a code-execution sandbox - is a very interesting direction and definitely worth exploring. From a technical point of view I can see how we could prototype this in mcpproxy with an embedded JS runtime (e.g. Node/QuickJS/Goja) plus a small host API like call_tool() exposed into that environment so the agent’s code can orchestrate multiple tools in one “execution”.

My main hesitation is around security and control: once you move orchestration into a code sandbox, you lose the nice, explicit visibility of individual MCP tool calls. That makes it harder to reason about what’s happening step-by-step and could increase the risk of accidental data damage or exfiltration if the composed logic misuses tools or passes sensitive data in ways that aren’t obvious to the user.

I really like the current "vibe" around MCP and agents in general - people are still discovering new patterns for composition, routing, and tool discovery almost weekly, and mcpproxy feels like a good place to incubate some of those ideas.

[Dumbris]

JavaScript Code Execution Feature Implementation

I've implemented a new code_execution tool that enables LLM agents to orchestrate multiple upstream MCP tools using sandboxed JavaScript. This feature significantly reduces token usage and improves context efficiency by allowing data aggregation and processing without pulling large payloads into the LLM context.

Available in release: v0.10.1

🔒 Security & Sandbox Architecture

The JavaScript VM runs in a heavily sandboxed environment with strict security constraints:

• No filesystem access - No fs module or file operations
• No network access - No http, fetch, or external connections
• No Node.js modules - No require() or module loading
• No timers - No setTimeout() or setInterval()
• No environment variables - No process.env access
• ES5.1+ standard library only - Array, Object, String, Math, Date, JSON, etc.

Available in sandbox:

• input - Global variable containing request input data
• call_tool(serverName, toolName, args) - Function to invoke upstream MCP tools
• Full ES5.1+ JavaScript standard library

Additional safeguards:

• Configurable execution timeout (default: 2 minutes, max: 10 minutes)
• Optional max tool call limits to prevent runaway loops
• Server whitelist support via allowed_servers option
• Integration with MCPProxy's existing quarantine system
• VM pool (10 concurrent VMs by default) with proper resource management

⚙️ Configuration

The feature is disabled by default via the enable_code_execution configuration option. To enable it, edit your configuration file (~/.mcpproxy/mcp_config.json):

{
  "enable_code_execution": true,
  "mcpServers": [
    // ... your existing servers
  ]
}

After updating the config, restart MCPProxy

📊 Web UI Integration

All code_execution tool calls and their nested upstream tool calls are fully visible in the Web UI's "Tool Call History" panel. You can see:

• The JavaScript code that was executed
• All upstream tool calls made from within the JavaScript
• Token metrics for both parent and nested calls
• Execution timing and results

Example: Token Reduction

Prompt example:

"Use code execution with Context7 tools to aggregate the number of available code snippets by library id for the keywords Vue, React, Angular, Svelte. Output data for all libs only - id, count"

Without code_execution (traditional approach):

• Agent makes individual tool calls for each library
• Each response contains large text payloads from the MCP server
• Agent must process and aggregate in LLM context (consumes thousands of tokens)
• Multiple model invocations required for filtering and counting

With code_execution (optimized approach):

• Agent generates single JavaScript snippet with loop and regex-based extraction
• All tool calls happen server-side in one request
• Data aggregation and filtering happens in JavaScript (no tokens consumed)
• Agent receives compact final result with library IDs and counts only

[Dumbris]

I've posted a related Show and Tell to the Model Context Protocol discussions.

Also a quick experiment showing how this new tool can help with data format conversion.

The ability to orchestrate multiple MCP tools and transform their outputs via JavaScript is incredibly powerful!

[technicalpickles]

Awesome! I will give it a shot.

One challenge I've found when having code execution (in general, not this feature) like running bash, ruby, pythong whatever, and passing in the code is that it's really easy to:

• get the syntax wrong
• accidental shell expansion

The code_execution woudln't have to worry about the latter (since it's sandboxed and also not being called via bash). But for shell commands, one way I mitigate this is by having a rule that is like "when running code, prefer writing out to a file and executing that". I've found that has better results more consistently, and has the added benefit of being reviewable and runnable by me.

I can imagine having a mcpproxy subcommand that takes a file with, and calls the tool with that as input. I think it'd be a pretty powerful tool outside of just running in an agent.

[technicalpickles]

Oh, just found the PR and it includes that already 😁 #138

# Multi-tool orchestration
mcpproxy code exec --file workflow.js --input-file data.json

[technicalpickles]

Think we can close this. I'll start a discussion for tracking other implementations of this.