MCP vs CLI: A Resilient Hybrid Architecture for AI Agents
When a plugin crashed, why did the MCP servers survive? A hybrid AI agent architecture combining MCP and CLI, with token cost tradeoffs and lifecycle lessons.
When an OpenCode agent's plugin-registered MCP bridge crashed alongside a daemon restart, six other MCP servers managing memory, search, and GitHub operations kept running untouched — because systemd supervised them as independent processes rather than embedding them inside the agent's own process. The incident crystallized a key architectural lesson: a plugin inherits its host's mortality, while a properly run MCP server manages its own lifecycle and survives client disconnects.
The team's response was a three-tier hybrid design. Frequently used, structured operations (memory lookups, semantic search, CRUD) run through six narrow MCP servers with just 3-8 tools each, keeping total schema overhead below what a single monolithic GitHub MCP server would cost alone. Ad-hoc commands and side-effecting actions route through a CLI bridge (server-commands-rtk) that adds token-reducing filtering and append-only audit logging. The governing rule is straightforward: build an MCP tool when output has a known schema, run raw CLI when the command is a small-output action.
Measured traces back this up — a structured package-download query costs 2-12x fewer tokens via MCP than raw or RTK-filtered CLI, while a simple action like git push is cheaper as raw CLI with zero schema overhead. Notably, audit logging lives at the CLI bridge layer, not the MCP protocol layer, meaning compliance doesn't actually require MCP. The takeaway reframes the ongoing MCP-vs-CLI debate: the real divide isn't about the protocol, it's single-process versus independent-process architecture — and lifecycle independence is what lets an agent recover state instead of leaking it.