Improving MCP tool call performance through LLM code generation

A Model Context Protocol (MCP) proxy server that translates tool calls into TypeScript code generation. Instead of making multiple tool calls back and forth, LLMs can write TypeScript code that calls multiple tools naturally, reducing token overhead and leveraging the LLM's superior code generation capabilities.

LLMs make multiple sequential tool calls, burning tokens and struggling with complex workflows:

• ❌ Multiple round-trips between LLM and tools
• ❌ Complex tool calling sequences are error-prone
• ❌ Data cannot easily be passed between tools
• ❌ Limited error handling and control flow

LLMs write TypeScript code that calls multiple tools naturally:

• ✅ Write code to call multiple tools in sequence
• ✅ Use variables, loops, and conditionals naturally
• ✅ Better error handling with try/catch
• ✅ Reduce token usage by combining operations
• ✅ Leverage LLM's strong code generation capabilities

1. Install mcpcodeserver in your MCP client (see installation section below)
2. Create an mcp.json configuration file with your child MCP servers
3. Start using it - your LLM can now generate and execute TypeScript code that calls your tools

mcpcodeserver is a unique MCP server that:

• Acts as an MCP client to connect to one or more child MCP servers
• Discovers all tools from child servers
• Exposes three powerful tools to parent LLM clients:
  1. list_servers - Lists all available sub-servers connected to this MCP server
  2. get_tool_definitions - Returns TypeScript type definitions for discovered tools (optionally filtered by server)
  3. generate_and_execute_code - Generates and executes TypeScript code that calls those tools in a sandbox

This architecture allows LLMs to orchestrate complex multi-tool workflows by writing code instead of making sequential tool calls, which is often more efficient and natural for modern language models.

This approach is inspired by recent research showing that LLMs perform better when generating executable code rather than making direct tool calls:

• CodeAct: Your LLM Agent Acts Better when Generating Code (Apple, ICML 2024) - Demonstrates that LLM agents achieve up to 20% higher success rates when using executable Python code as a unified action space instead of pre-defined tool calling formats.

• Cloudflare Code Mode - A similar implementation that converts MCP tools into TypeScript APIs, showing that "LLMs are better at writing code to call MCP, than at calling MCP directly."

The key insight from this research is that LLMs have extensive training on real-world code but limited exposure to synthetic tool-calling formats, making code generation a more natural and effective approach for complex agent workflows.

• Multiple round-trips between LLM and tools burn tokens
• LLMs often struggle with complex tool calling sequences
• Each tool call requires JSON schema understanding and formatting
• Data cannot easily be passed between tools without going through the LLM

• Write TypeScript code to call multiple tools in sequence
• Use variables, loops, and conditionals naturally
• Better error handling with try/catch
• Reduce token usage by combining operations
• Leverage LLM's strong code generation capabilities

mcpcodeserver automatically monitors child MCP servers for tool changes and notifies parent clients when tools are added, removed, or modified:

• Automatic Refresh: Checks for tool changes every 30 seconds
• Real-time Notifications: Sends notifications/tools/list_changed to parent clients
• Dynamic Updates: Tool definitions and summaries update automatically
• No Manual Refresh: Parent LLMs receive notifications to refresh their tool knowledge

This ensures that parent LLMs always have the most current tool definitions without requiring manual intervention.

To reduce context window usage and improve focus, mcpcodeserver supports filtering tool definitions by specific servers:

• List Available Servers: Use list_servers to see all connected sub-servers
• Filtered Tool Definitions: Use get_tool_definitions with server_names parameter to get tools from specific servers only
• Reduced Verbosity: Get focused TypeScript definitions without overwhelming the LLM's context window
• Method Namespacing: All generated functions are prefixed with server names (e.g., pizzashop_create_pizza, filesystem_read_file)

Example usage:

mcpcodeserver supports pass-through of advanced MCP protocol features when both parent and child servers support them:

• Elicitation: Child servers can request user input during tool execution, which is passed through to parent clients
• Roots: Lists and aggregates roots from all child servers, providing a unified view of available resources
• Sampling: Enables LLM sampling requests to be passed through to child servers for advanced AI capabilities

These features are automatically advertised to parent clients and work seamlessly when supported by the underlying child MCP servers.

Try it immediately with npx (no installation required):

• Node.js >= v18.0.0
• Cursor, Claude Code, VSCode, Windsurf or another MCP Client

To install mcpcodeserver for any client automatically via Smithery:

Go to: Settings -> Cursor Settings -> MCP -> Add new global MCP server

Pasting the following configuration into your Cursor ~/.cursor/mcp.json file is the recommended approach. You may also install in a specific project by creating .cursor/mcp.json in your project folder.

Run this command. See Claude Code MCP docs for more info.

Add to your VSCode MCP settings:

For Continue, Cline, and RooCode, add to your configuration:

Run this command in your terminal. See Amp MCP docs for more info.

For Aider, Codium, Zed, Nova, and Sublime Text, add to your configuration:

Add to your Neovim MCP configuration:

Add to your Emacs MCP configuration:

For IntelliJ IDEA, WebStorm, PyCharm, and Android Studio, add to your MCP settings:

For Codeium, Tabnine, GitHub Copilot, and Amazon CodeWhisperer, add to your MCP settings:

For Replit, CodeSandbox, StackBlitz, GitPod, GitHub Codespaces, GitLab Web IDE, and Bitbucket Cloud, add to your MCP settings:

For Xcode, Fleet, Sourcegraph, and JetBrains Gateway, add to your MCP configuration:

For remote development environments, you can also use HTTP transport:

Create an mcp.json configuration file to define your child MCP servers:

Note: This project uses Bun for better performance, but npm/node also work fine.

If you encounter ERR_MODULE_NOT_FOUND, try using bunx instead of npx:

For errors like Error: Cannot find module, try the --experimental-vm-modules flag:

Use the --experimental-fetch flag to bypass TLS-related problems:

1. Try adding @latest to the package name
2. Use bunx as an alternative to npx
3. Consider using deno as another alternative
4. Ensure you're using Node.js v18 or higher for native fetch support

• Make sure your mcp.json file is valid JSON
• Check that all child server commands are available in your PATH
• Verify that child servers can start independently
• Check file permissions for the config file path

mcpcodeserver accepts the following CLI flags:

• --config <path> – Path to the MCP configuration file (default: ./mcp.json)
• --transport <stdio|http> – Transport to use (stdio by default). Note that HTTP transport automatically provides both HTTP and SSE endpoints
• --port <number> – Port to listen on when using http transport (default 3000)
• --help – Show help message

Example with HTTP transport and port 8080:

Example with stdio transport:

You can use environment variables for configuration:

• MCP_CONFIG_PATH – Path to the MCP configuration file (alternative to --config)
• MCP_TRANSPORT – Transport type (alternative to --transport)
• MCP_PORT – Port number for HTTP transport (alternative to --port)

Example with environment variables:

Example MCP configuration using environment variables:

Note: CLI flags take precedence over environment variables when both are provided.

For local development, you can run the TypeScript source directly:

The server runs in stdio mode by default, which is perfect for integration with MCP clients like Claude Desktop:

For debugging, testing, or integration with web-based MCP clients, you can run the server in HTTP mode:

When running in HTTP mode, the server will be available at:

• Server URL: http://localhost:3000/mcp (or your custom host:port)
• MCP Inspector: Use npx @modelcontextprotocol/inspector http://localhost:3000/mcp to debug and test

The MCP Inspector is a powerful tool for debugging and testing MCP servers. When running in HTTP mode, you can use it to:

• Inspect available tools and their schemas
• Test tool calls interactively
• Debug resource access and prompts
• Monitor real-time notifications

The inspector will open in your browser and provide a full interface for exploring and testing your MCP server.

Note: The npm run inspector command uses mcp-test.json which includes 8 MCP servers (67 tools total) from the official examples, including both TypeScript (npx) and Python (uvx) based servers.

Create an mcp.json file that defines which child MCP servers to connect to. This follows the standard MCP client configuration format:

Each server entry supports:

For stdio transport:

• command (required) - The command to execute (e.g., "node", "python", "npx")
• args (optional) - Array of arguments to pass to the command
• env (optional) - Environment variables for the child process

For HTTP/SSE transport:

• url (required) - The HTTP endpoint URL
• transport - Set to "sse" for Server-Sent Events

Configure mcpcodeserver in your MCP client (like Claude Desktop, Claude Code, Cline, etc.):

With npx (recommended - no installation needed):

From GitHub (works immediately):

With other package managers:

See examples/ for more configuration examples and MCP client-specific setups.

This tool returns TypeScript type definitions for all discovered tools from child servers.

Input:

• include_examples (optional boolean) - Whether to include usage examples

Example:

Output: Returns TypeScript code with interfaces and function declarations:

This tool executes TypeScript code in a sandbox with access to all discovered tool functions.

Input:

• code (required string) - TypeScript/JavaScript code to execute
• timeout (optional number) - Max execution time in milliseconds (default: 30000, max: 300000)

Example:

Output:

The TypeScript execution sandbox provides:

Available:

• All discovered tool functions (as async functions)
• Console methods: console.log(), console.error(), console.warn(), console.info()
• Basic JavaScript globals: Math, JSON, Date, Array, Object, String, Number, Boolean
• Promise and async/await support
• Error handling with try/catch
• Timers: setTimeout, setInterval, clearTimeout, clearInterval

Not Available:

• Node.js modules (fs, http, child_process, etc.)
• File system access (except via MCP tools)
• Network access (except via MCP tools)
• Process information

Security Note: This is not a fully secure sandbox. The VM context provides isolation but is not bulletproof. Only execute trusted code.

Errors in the sandbox are caught and returned with stack traces:

Want to try mcpcodeserver with Claude Code? Use the one-command setup:

This will build the project, install test dependencies, and show you exactly what to add to your Claude Code configuration. See TESTING_WITH_CLAUDE.md for detailed instructions.

See AGENTS.md for detailed project structure and component documentation.

Instead of making multiple tool calls through the LLM, write code:

Process data between tool calls without LLM intervention:

Make decisions based on tool results:

Handle errors gracefully without aborting the entire workflow:

mcpcodeserver can integrate with official upstream MCP servers from the Model Context Protocol servers repository. This allows you to use real, production-ready MCP servers alongside your custom tools.

• filesystem: File system operations (read, write, list directories)
• memory: In-memory key-value storage
• sqlite: SQLite database operations
• github: GitHub API integration
• brave-search: Web search capabilities
• fetch: HTTP request capabilities

The project includes comprehensive tests for upstream server integration:

With upstream servers, you can create powerful cross-server workflows:

• Execution timeout: Maximum 5 minutes (configurable, default 30 seconds)
• Memory: Limited by Node.js VM context
• No persistent state between executions
• Cannot require/import external modules
• Not a security sandbox - don't run untrusted code

Contributions welcome! This project is built with:

• TypeScript 5.7+
• Node.js 18+
• MCP TypeScript SDK 1.20+
• Zod for validation

See CONTRIBUTING.md for detailed contribution guidelines.

If you find this project helpful, consider buying me a coffee!

MIT

• Model Context Protocol Specification
• MCP TypeScript SDK
• MCP Servers List