BoxAgnts Runtime (5) — MCP Is Just the Beginning, the Runtime Layer Is What Matters

BoxAgnts has released a runtime architecture that separates the Model Context Protocol (MCP) layer from a dedicated execution runtime, arguing that protocol standardization alone is insufficient for safe AI tool execution. The implementation places MCP tool communication in a distinct interface layer while routing actual execution through a WASM sandbox runtime that handles isolation, resource constraints, and permission boundaries. This design reveals that MCP tools, which execute on remote servers outside the sandbox, introduce a security gap that depends entirely on the MCP server provider's implementation quality.

The emergence of MCP Model Context Protocol marks a major milestone for the AI ecosystem. For the first time, the industry is converging around a shared interface for tool interaction—standardizing how models discover tools, invoke capabilities, exchange context, and communicate with external systems. But MCP also reveals a larger architectural gap: it solves the protocol problem, not the runtime problem. And the runtime problem is becoming increasingly critical. MCP standardizes communication—defining tool discovery, invocation, and resource management. This is valuable. But protocols only define "how systems communicate," not "how systems safely execute." To analogize: HTTP standardized web communication, but it didn't solve application isolation, runtime governance, resource scheduling, or execution security. Those are the responsibilities of operating systems and runtimes. BoxAgnts' MCP implementation embodies this layering. boxagnts/mcp/src/lib.rs handles all protocol-level logic—JSON-RPC 2.0 message format, initialize/initialized handshake, tools/list discovery, tools/call execution, stdio and HTTP/SSE transport: php // MCP client connection pub async fn connect stdio config: &McpServerConfig - anyhow::Result<Self { let backend = RmcpClientBackend::connect stdio config .await?; Ok Self::from backend Arc::new backend } // Tool invocation pub async fn call tool &self, name: &str, arguments: Option<Value - anyhow::Result<CallToolResult { self.backend ?.call tool name, arguments .await } But note—the MCP client is only responsible for "calling the tool and getting the result." It is not responsible for "whether this tool should be called" or "under what constraints the call should execute." That responsibility belongs to the runtime layer. Most AI system architectures look like: LLM → Prompt Framework → Tool Calling Protocol → Host Execution A layer is missing in the middle: runtime infrastructure. This layer is responsible for execution isolation, capability boundaries, resource constraints, state persistence, and execution observability. BoxAgnts' complete stack clearly shows this layering: LLM api/ layer ↓ Gateway / Query gateway/ + query/ ↓ Tool Interface tools/ + wasm-tools/ ↓ WASM Sandbox wasm-sandbox/ layer ← This is the real runtime ↓ Host Resources MCP sits alongside the Tool Interface layer—it brings external tools into the agent's toolkit but doesn't alter the underlying execution isolation. In BoxAgnts, MCP tools are registered via McpToolWrapper : // boxagnts/gateway/src/api/mcp.rs pub struct McpToolWrapper { pub tool def: ToolDefinition, pub server name: String, pub manager: Arc<boxagnts mcp::McpManager , } impl Tool for McpToolWrapper { fn permission level &self - PermissionLevel { PermissionLevel::Execute // MCP tools default to Execute level } // execute delegates the call to the remote MCP server } Once MCP tools are plugged in, they use the same Tool trait interface as native tools—but their execution happens on the remote MCP server, outside BoxAgnts' WASM sandbox protection. This is a security boundary difference that requires clear awareness. MCP standardizes tool calling—the model selects a tool name, structured arguments, and an execution request. But the harder problems come after invocation: what permissions does the tool receive? What files can it access? Which network endpoints are allowed? How are resources constrained? How is execution isolated? How is behavior audited? These are runtime concerns. MCP cannot answer them. BoxAgnts places MCP tools and native WASM tools under the same interface layer but distinguishes their execution paths: RunOption McpToolWrapper ; trust boundary is the MCP server itselfThis means the security of MCP tools depends on the implementation quality of the MCP server provider. If an MCP server doesn't sandbox—its tool calls are equivalent to direct host execution. Traditional software already assumes applications may fail, dependencies may be compromised, and processes may behave unexpectedly. That's why containers, VMs, and process boundaries exist. AI agents face more severe problems: LLM-driven systems are exposed to prompt injection, adversarial documents, and manipulated context. BoxAgnts' Connection Manager boxagnts/mcp/src/connection manager.rs demonstrates that even MCP connections need governance: php pub async fn connect all &self - anyhow::Result< { for name in names { if let Err e = self.connect &name .await { error server = %name, error = %e, "MCP server failed to connect during startup" ; } } Ok } Connection failures are handled in isolation—one MCP server going down doesn't affect others. This seems obvious, but many agent frameworks don't have even this layer. The current ecosystem invests heavily in standardizing model interfaces, tool protocols, prompt formats, and orchestration frameworks. These are useful, but history shows infrastructure ultimately gets constrained by execution, not interfaces. The web didn't scale purely because of HTTP—it scaled because of operating systems, process isolation, container orchestration, runtime environments, and scheduling systems. AI infrastructure is no different: tool protocols are necessary but not sufficient. Ultimately, the key differentiator is runtime reliability, not tool invocation syntax. BoxAgnts' architecture foresaw this: the protocol layer MCP sits above, the runtime layer WASM Sandbox sits below. New tools can be discovered via protocol, but execution constraints are uniformly controlled by the runtime. Reliable AI systems require deterministic execution, explicit permissions, sandboxed tooling, governed orchestration, bounded side effects, resource accounting, and execution observability—these extend far beyond prompt engineering. BoxAgnts embodies this direction across several key modules: boxagnts/wasm-sandbox/ : Execution isolation and capability constraints boxagnts/tools/ : Tool interface and permission model boxagnts/gateway/cron/ : Scheduled task execution governance boxagnts/workspace/ : State persistence and managementThe future AI stack should be: LLM ↓ Protocol Layer MCP ↓ Runtime Layer ← This layer needs massive engineering investment ↓ Capability Sandbox WASM ↓ Execution Infrastructure None of the above diminishes MCP's value. Quite the opposite—standardized protocols make runtime innovation easier. A shared tool interface enables portable runtimes, interchangeable orchestration systems, and standardized capability injection. Protocols simplify integration. Runtimes enforce behavior. Both layers matter, but they must not be conflated. MCP standardizes how models communicate with external systems—an important milestone. But communication is only half the problem. The harder challenge is execution safety. As agents gain operational authority, production systems need runtime isolation, capability governance, deterministic execution, and sandboxed tooling. The critical question is no longer "Can the model invoke tools?"—it's "Can the system execute safely?"