Code Execution Mode

The Code Execution Mode MCP Server is a bridge implementation designed to solve the “context bankruptcy” problem inherent in heavy Model Context Protocol usage.

When you connect an LLM to multiple MCP servers, for example, 10 servers with 100 combined tools, the schema definitions alone can consume upwards of 30,000 tokens per query.

This server implements Anthropic’s “Code Execution with MCP” pattern to reduce that overhead to a constant ~200 tokens, regardless of how many tools you have available.

The Code Execution MCP Server allows the LLM to “discover” tools on demand, read their documentation only when needed, and then execute Python code to interact with those tools inside a secure, rootless container.

It essentially gives Claude (or other clients) a Python sandbox where it can import and use your other MCP servers (like Filesystem, GitHub, or specialized data tools) programmatically, without the massive token cost of pre-loading schemas.

Features

• 🔒 Rootless Security: Containers run with dropped capabilities, read-only filesystems, and no network access.
• ⚡ 95% Context Reduction: Drops from 30,000 tokens to just 200 tokens constant overhead.
• 🔧 Universal MCP Proxying: Works with any stdio MCP server through containerized execution.
• 🔍 Zero-Context Discovery: Automatic server discovery without preloading tool schemas.
• 📊 Multiple Access Patterns: Dynamic lookup, attribute access, or module import styles.
• 🛡️ Production Hardened: Resource limits, capability dropping, and security isolation.
• 🔄 Persistent Clients: MCP servers stay warm between executions.
• 📝 Flexible Output Formats: Compact plain text or TOON blocks for deterministic tokenization.

Use Cases

Cost-Efficient “Power User” Setups

Developers running double-digit MCP servers often hit context limits or massive API bills ($0.09+ per query just for context). This server allows you to keep 50+ servers “connected” but dormant, hydrating only the specific tool schemas needed for the current task.

Complex Logic & Orchestration

Standard MCP requires an LLM to call a tool, wait for a response, then call another. With this server, an LLM can write a single Python script to perform loops, conditionals, and data processing (e.g., “Search Jira for bugs, filter for ‘critical’, and create GitHub issues for each”) in one execution cycle.

Secure Code Execution for Agents

For organizations hesitant to let LLMs run code on local machines, this provides a hardened layer. The code runs as an unprivileged user (UID 65534) with no network access and no ability to escalate privileges, making it safer for handling untrusted model outputs.

🚀 How to Use It

Installation and Setup

Prerequisites

• macOS or Linux system
• Python 3.14 or newer
• Podman or Docker runtime
• UV package manager

System Preparation

# Install Python 3.14 if needed
python3 --version
# Install container runtime
brew install podman  # macOS
# or
sudo apt-get install -y podman  # Ubuntu/Debian
# Install UV package manager
curl -LsSf https://astral.sh/uv/install.sh | sh
# Pull container image
podman pull python:3.14-slim

Python 3.14 Compatibility Note

If using Python 3.14, ensure you have modern Pydantic installed:

pip install -U pydantic
pip uninstall typing  # Remove if present, use stdlib typing

Launch the Bridge

uvx --from git+https://github.com/elusznik/mcp-server-code-execution-mode mcp-server-code-execution-mode run

Claude Code Configuration

Create the configuration file at ~/.config/mcp/servers/mcp-server-code-execution-mode.json:

{
  "mcpServers": {
    "mcp-server-code-execution-mode": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/elusznik/mcp-server-code-execution-mode",
        "mcp-server-code-execution-mode",
        "run"
      ],
      "env": {
        "MCP_BRIDGE_RUNTIME": "podman"
      }
    }
  }
}

Restart Claude Code after creating this configuration.

OpenCode Configuration

For OpenCode users, add the same server configuration to ~/.opencode.json or ~/Library/Application Support/OpenCode/opencode_config.json:

{
  "mcpServers": {
    "mcp-server-code-execution-mode": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/elusznik/mcp-server-code-execution-mode",
        "mcp-server-code-execution-mode",
        "run"
      ],
      "env": {
        "MCP_BRIDGE_RUNTIME": "podman"
      }
    }
  }
}

Basic Code Execution

# Simple file operations
files = await mcp_filesystem.list_directory(path='/tmp')
for file in files:
    content = await mcp_filesystem.read_file(path=file)
    if 'TODO' in content:
        print(f"TODO found in {file}")
# Multi-system workflow example
data = await mcp_search.search(query="pending tasks")
await mcp_github.create_issue(repo='owner/repo', title=data.title, body=data.content)

Server Discovery and Tool Exploration

from mcp import runtime
# Discover available servers
servers = await runtime.discovered_servers()
print("Available servers:", servers)
# Get tool documentation for specific server
tool_docs = await runtime.query_tool_docs("serena")
print("Serena tools:", tool_docs)
# Search across all servers
results = await runtime.search_tool_docs("calendar events", limit=5)
for result in results:
    print(f"{result['server']}.{result['tool']}: {result.get('description', '')}")
# Quick capability overview
print(runtime.capability_summary())

Explicit Server Loading

The run_python tool requires explicit server specification. Provide the servers array when invoking the tool:

{
  "code": "result = await mcp_serena.search(query='latest research papers')\nprint(result)",
  "servers": ["serena", "filesystem"]
}

Omitting the servers array means discovery helpers work, but RPC calls to unloaded servers will fail with “Server ” is not available” errors.

Configuration Options

Environment Variables

• MCP_BRIDGE_RUNTIME=podman – Container runtime (podman/docker)
• MCP_BRIDGE_IMAGE=python:3.14-slim – Container image
• MCP_BRIDGE_TIMEOUT=30s – Default execution timeout
• MCP_BRIDGE_MAX_TIMEOUT=120s – Maximum allowed timeout
• MCP_BRIDGE_MEMORY=512m – Memory limit per execution
• MCP_BRIDGE_PIDS=128 – Maximum process count
• MCP_BRIDGE_OUTPUT_MODE=compact – Response format (compact/toon)
• MCP_BRIDGE_STATE_DIR=./.mcp-bridge – IPC and state directory

Server Discovery Locations

The bridge automatically scans these locations for MCP server configurations:

• ~/.claude.json
• ~/.config/mcp/servers/*.json
• ~/Library/Application Support/Claude Code/claude_code_config.json
• Project-local claude_code_config.json and claude_desktop_config.json
• ./mcp-servers/*.json

Advanced Multi-System Workflow

# Jira to GitHub issue migration
issues = await mcp_jira.search_issues(project='API', status='Open')
for issue in issues:
    details = await mcp_jira.get_issue(id=issue.id)
    if 'critical' in details.priority.lower():
        # Create GitHub issue with Jira context
        await mcp_github.create_issue(
            repo='owner/repo',
            title=f"[CRITICAL] {issue.title}",
            body=f"**Jira Issue:** {issue.key}\n\n{details.description}\n\n**Priority:** {details.priority}"
        )
        # Update Jira with tracking link
        await mcp_jira.add_comment(
            id=issue.id,
            comment=f"GitHub issue created for tracking"
        )

Docker MCP Gateway Integration

When using Docker MCP Gateway for third-party servers:

# Login to required registries
docker login
docker login ghcr.io
# Set required secrets
docker mcp secret set github.personal_access_token "your-token-here"

The bridge executes the gateway binary, which handles pulling tool images and wiring stdio transports.

State Directory and Volume Sharing

For Podman runtimes, the bridge automatically configures volume sharing:

podman machine set --rootful --now --volume $(pwd)/.mcp-bridge:$(pwd)/.mcp-bridge

Docker Desktop users must manually add the state directory to Docker Desktop → Settings → Resources → File Sharing.

Verify sharing works with:

docker run --rm -v $PWD/.mcp-bridge:/ipc alpine ls /ipc

FAQs

Q: How does this differ from Docker MCP Gateway?
A: Docker MCP Gateway manages containers well but still streams all tool schemas into Claude’s context. This bridge implements zero-context discovery, keeping system prompts at ~200 tokens regardless of server count.

Q: Can I use my existing MCP server configurations?
A: Yes, the bridge automatically discovers servers from standard MCP configuration locations, including Claude Desktop, OpenCode, and local project configurations.

Q: What security measures are in place for code execution?
A: Containers run rootless with all capabilities dropped, read-only filesystems, no network access, and strict resource limits (memory, PIDs, CPU). The security model prevents system calls and privilege escalation.

Q: Why do I need to specify servers explicitly in run_python?
A: Explicit server loading ensures only authorized tools are available in the execution environment and prevents accidental context pollution from unused tool schemas.

Q: What happens when network access is attempted?
A: All containers run with --network none, so any network calls immediately fail. This is a security feature, not a limitation.

Q: Can I use this with Claude Code and OpenCode simultaneously?
A: Yes, configure the bridge in both applications’ MCP server configurations. The bridge manages persistent connections independently per client.

Q: How do I troubleshoot server connection issues?
A: Check that required secrets are set for gateway-based servers, verify container images are pulled, and ensure volume sharing is configured correctly for your runtime.

Q: What’s the performance impact of the discovery pattern?
A: Minimal. Servers stay warm between calls, and tool schema hydration happens on-demand rather than preloading everything. Most users see improved performance due to reduced context processing.