Current Status & Roadmap

Relevant source files

The following files were used as context for generating this wiki page:

• STATUS.md
• HISTORY.md
• README.md
• ARCHITECTURE.md
• mcp_server_code_execution_mode.py

The MCP Server Code Execution Mode project is currently a functional implementation of the "Code Execution with MCP" pattern. It serves as a secure, containerized bridge that allows Large Language Models (LLMs) to execute Python code while proxying tools from other Model Context Protocol (MCP) servers. The system has evolved from failed in-process prototypes to a robust, rootless container-based architecture designed for high security and significant context window reduction.

While the core functionality is delivered, the project is currently in a phase of operational refinement. Development is focused on enhancing production readiness through better observability, automated testing, and fine-grained policy controls. The roadmap outlines a transition from a functional tool for development and testing toward a "production-grade" system suitable for enterprise-scale agentic workflows.

Sources: STATUS.md:3-9, HISTORY.md:5-9, README.md:144-153

Current Implementation Status

The project has achieved a stable core architecture featuring a single run_python tool that manages the lifecycle of sandboxed executions.

✅ Delivered Features

Feature Category	Description
Core Execution	Single run_python tool, rootless container sandbox, and host-mediated MCP proxying.
Persistence	Persistent MCP client sessions and a JSON-based memory system (save_memory, load_memory) stored in /projects/memory/.
Security	Network disabled, read-only rootfs, dropped capabilities, and unprivileged user (UID 65534).
Discovery	Two-stage discovery using discovered_servers() and query_tool_docs() to keep context overhead constant (~200 tokens).
Performance	95%+ context reduction vs traditional MCP and warm client sessions to avoid cold starts.

Sources: STATUS.md:14-41, README.md:183-201, mcp_server_code_execution_mode.py:100-115

Architectural Evolution

The project moved through two distinct phases to arrive at its current state. The transition was driven by the failure of host-side sandboxing techniques (RLIMIT-based isolation and in-process execution) which were found to be vulnerable to escapes.

Roadmap and Planned Enhancements

The roadmap is categorized by priority levels focusing on moving from functional stability to production hardening.

🔄 Priority 1: Operational Readiness

These items are actively being worked on to provide the necessary infrastructure for reliable deployments.

• Automated Testing Expansion: Broadening coverage for container command generation and discovery logic, including stress cases for RPC error handling.
• Observability: Implementing structured logging with request IDs and tracking metrics/traces for container launches, exits, and tool call latency.
• Agent-Visible Discovery: Developing host-proxied mcp-find and mcp-add tools to allow agents to curate servers dynamically.

Sources: STATUS.md:46-60, README.md:543-550

🔄 Priority 2: Production Hardening

These features focus on administrative controls and system diagnostics.

• Policy Controls: Implementing allow/deny lists for MCP servers and per-request resource limits or concurrency caps.
• Runtime Diagnostics: Enhancing detection for Podman/Docker environments and implementing self-health checks.

Sources: STATUS.md:62-69, ARCHITECTURE.md:143-148

📋 Future Enhancements ("Nice to Have")

Longer-term goals for the project include:

• Multi-language Support: Expanding execution beyond Python.
• Workflow Orchestration: Features to support complex, multi-step agent tasks.
• Connection Pooling: Further optimizing MCP client resource usage.
• Web UI: A dedicated interface for monitoring and debugging active sandboxes.

Sources: STATUS.md:71-79, README.md:551-555

Security and Performance Metrics

The project currently enforces strict resource constraints to maintain system integrity during execution.

Sandbox Constraint Matrix

Parameter	Current Default	Config Variable
Timeout	30s	MCP_BRIDGE_TIMEOUT
Max Timeout	120s	MCP_BRIDGE_MAX_TIMEOUT
Memory Limit	512m	MCP_BRIDGE_MEMORY
PID Limit	128	MCP_BRIDGE_PIDS
Idle Timeout	300s	MCP_BRIDGE_RUNTIME_IDLE_TIMEOUT

Sources: STATUS.md:32-38, README.md:434-444, ARCHITECTURE.md:118-129, mcp_server_code_execution_mode.py:118-130

Technical Summary

The current status of the MCP Server Code Execution Mode project is "Functional and Secure," though it is not yet "Production-Grade" due to gaps in operational observability and policy management. The core architecture—relying on rootless containers and host-mediated JSON framing—is stable and provides a significant performance advantage for LLM agents by drastically reducing context overhead. Future development is strictly oriented toward filling these operational gaps to support high-scale deployments.

Sources: STATUS.md:83-93, HISTORY.md:95-102