list_serversLABSCO SUMMARY
One round trip instead of several, because the orchestration is code.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command — npx mcpcodeserver --config <YOUR_PATH_TO_MCP_CONFIG> --transport stdio
USE CASES
01
Doing the same thing to many items
Write a loop that calls the tool once per item and returns only what matched.
02
Passing data between two servers
Take one server's output straight into another's input inside the code, without it round-tripping through the model.
03
Keeping the tool list from swamping the context
Ask for definitions from just the servers this task needs.
04
Handling failure sensibly
Wrap the calls in error handling and decide in code what to do when one fails.
05
Seeing what is actually connected
List the child servers before assuming a tool is available.
3 tools
Listed in project docs. Your client may show a different list.
get_tool_definitionsgenerate_and_execute_codeBEFORE YOU INSTALL
What to know first
Tools you get
3 tools named in the project's documentation.
Requires
- npx on PATH
- Node.js >= v18.0.0
INSTALLATION
Connect your client
Server setup
TERMINAL
npx mcpcodeserver --config <YOUR_PATH_TO_MCP_CONFIG> --transport stdio<YOUR_PATH_TO_MCP_CONFIG> is the full path of a JSON file listing the servers to wrap, in the mcpServers format your client already uses.
MCP Clients
Cursor, Windsurf, Continue, Cline, Roo Code, JetBrains IDEs
JSON
{
"mcpServers": {
"mcpcodeserver": {
"command": "npx",
"args": [
"-y",
"mcpcodeserver",
"--config",
"<YOUR_PATH_TO_MCP_CONFIG>"
]
}
}
}VS Code
VS CODE · JSON
{
"servers": {
"mcpcodeserver": {
"command": "npx",
"args": [
"-y",
"mcpcodeserver",
"--config",
"<YOUR_PATH_TO_MCP_CONFIG>"
]
}
}
}Claude Code
CLAUDE CODE · TERMINAL
claude mcp add mcpcodeserver -- npx -y mcpcodeserver --config <YOUR_PATH_TO_MCP_CONFIG>Amp
AMP · TERMINAL
amp mcp add mcpcodeserver -- npx -y mcpcodeserver --config <YOUR_PATH_TO_MCP_CONFIG>Neovim
NEOVIM
{ mcpServers = { mcpcodeserver = { command = "npx", args = {"-y", "mcpcodeserver", "--config", "<YOUR_PATH_TO_MCP_CONFIG>"} } } }Emacs
EMACS
(setq mcp-servers '((mcpcodeserver :command "npx" :args ("-y" "mcpcodeserver" "--config" "<YOUR_PATH_TO_MCP_CONFIG>"))))
