The gain is concrete: reading a directory of files and filtering them is one call here and many there, and the intermediate data never passes through the model's context. Narrowing get_tool_definitions to the servers you need is what keeps that from backfiring. Treat the sandbox as isolation rather than security.
A proxy that connects to your other MCP servers as a client, collects their tools, and re-exposes them as TypeScript functions the model calls from code it writes and the server executes.
- The child servers it is connected to, listed by name (list_servers)
- TypeScript type definitions for every discovered tool, optionally narrowed to particular servers to keep the context small (get_tool_definitions)
- TypeScript executed in a sandbox with all those tool functions in scope, returning both the console output and the value (generate_and_execute_code)
- Loops, conditionals, variables and error handling across several tools in one round trip, with data passed between calls without going back through the model
- Function names prefixed with the server they came from, so tools with the same name across servers stay distinct
- Child servers polled for tool changes, and the parent client notified when tools appear or disappear
- Pass-through of the advanced protocol features — elicitation, roots and sampling — when both ends support them
- Child servers connected over standard input and output or over HTTP, in the same configuration file
Node.js and a configuration file listing the child servers, in the same format your MCP client already uses. The sandbox gives executed code the tool functions, console methods, the basic JavaScript globals and timers — no file system, no network and no Node modules except through the tools. The project is explicit that this is isolation and not a hardened sandbox: run trusted code only.
One command — npx mcpcodeserver --config /path/to/mcp.json --transport stdio