{"slug": "boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters", "title": "BoxAgnts Runtime (5) — MCP Is Just the Beginning, the Runtime Layer Is What Matters", "summary": "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.", "body_md": "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.\n\nBut MCP also reveals a larger architectural gap: **it solves the protocol problem, not the runtime problem.** And the runtime problem is becoming increasingly critical.\n\nMCP standardizes communication—defining tool discovery, invocation, and resource management. This is valuable. But protocols only define \"how systems communicate,\" not \"how systems safely execute.\"\n\nTo 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.\n\nBoxAgnts' MCP implementation embodies this layering. `boxagnts/mcp/src/lib.rs`\n\nhandles all protocol-level logic—JSON-RPC 2.0 message format, initialize/initialized handshake, tools/list discovery, tools/call execution, stdio and HTTP/SSE transport:\n\n``` php\n// MCP client connection\npub async fn connect_stdio(config: &McpServerConfig) -> anyhow::Result<Self> {\n    let backend = RmcpClientBackend::connect_stdio(config).await?;\n    Ok(Self::from_backend(Arc::new(backend)))\n}\n\n// Tool invocation\npub async fn call_tool(&self, name: &str, arguments: Option<Value>) \n    -> anyhow::Result<CallToolResult> {\n    self.backend()?.call_tool(name, arguments).await\n}\n```\n\nBut 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.**\n\nMost AI system architectures look like:\n\n```\nLLM → Prompt Framework → Tool Calling Protocol → Host Execution\n```\n\nA layer is missing in the middle: **runtime infrastructure.** This layer is responsible for execution isolation, capability boundaries, resource constraints, state persistence, and execution observability.\n\nBoxAgnts' complete stack clearly shows this layering:\n\n```\nLLM (api/ layer)\n  ↓\nGateway / Query (gateway/ + query/)\n  ↓\nTool Interface (tools/ + wasm-tools/)\n  ↓\nWASM Sandbox (wasm-sandbox/ layer)  ← This is the real runtime\n  ↓\nHost Resources\n```\n\nMCP 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`\n\n:\n\n```\n// boxagnts/gateway/src/api/mcp.rs\npub struct McpToolWrapper {\n    pub tool_def: ToolDefinition,\n    pub server_name: String,\n    pub manager: Arc<boxagnts_mcp::McpManager>,\n}\n\nimpl Tool for McpToolWrapper {\n    fn permission_level(&self) -> PermissionLevel {\n        PermissionLevel::Execute  // MCP tools default to Execute level\n    }\n    // execute delegates the call to the remote MCP server\n}\n```\n\nOnce MCP tools are plugged in, they use the same `Tool`\n\ntrait 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.**\n\nMCP 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?\n\nThese 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:\n\n`RunOption`\n\n`McpToolWrapper`\n\n; 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.\n\nTraditional 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.\n\nBoxAgnts' Connection Manager (`boxagnts/mcp/src/connection_manager.rs`\n\n) demonstrates that even MCP connections need governance:\n\n``` php\npub async fn connect_all(&self) -> anyhow::Result<()> {\n    for name in names {\n        if let Err(e) = self.connect(&name).await {\n            error!(server = %name, error = %e, \n                   \"MCP server failed to connect during startup\");\n        }\n    }\n    Ok(())\n}\n```\n\nConnection 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.\n\nThe 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.\n\nThe 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.\n\nBoxAgnts' 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.\n\nReliable 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.\n\nBoxAgnts embodies this direction across several key modules:\n\n`boxagnts/wasm-sandbox/`\n\n: Execution isolation and capability constraints`boxagnts/tools/`\n\n: Tool interface and permission model`boxagnts/gateway/cron/`\n\n: Scheduled task execution governance`boxagnts/workspace/`\n\n: State persistence and managementThe future AI stack should be:\n\n```\nLLM\n  ↓\nProtocol Layer (MCP)\n  ↓\nRuntime Layer ← This layer needs massive engineering investment\n  ↓\nCapability Sandbox (WASM)\n  ↓\nExecution Infrastructure\n```\n\nNone 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.\n\nProtocols simplify integration. Runtimes enforce behavior. Both layers matter, but they must not be conflated.\n\nMCP 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.\n\nThe critical question is no longer \"Can the model invoke tools?\"—it's \"Can the system execute safely?\"", "url": "https://wpnews.pro/news/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters", "canonical_source": "https://dev.to/guyoung/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters-2mh3", "published_at": "2026-06-05 04:21:08+00:00", "updated_at": "2026-06-05 05:11:27.094095+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-tools", "large-language-models", "artificial-intelligence"], "entities": ["BoxAgnts", "MCP", "Model Context Protocol", "HTTP", "JSON-RPC"], "alternates": {"html": "https://wpnews.pro/news/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters", "markdown": "https://wpnews.pro/news/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters.md", "text": "https://wpnews.pro/news/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters.txt", "jsonld": "https://wpnews.pro/news/boxagnts-runtime-5-mcp-is-just-the-beginning-the-runtime-layer-is-what-matters.jsonld"}}