Why MCP Servers Outperform Plugins for AI Workflow Resilience

Mid-session failures often trace back to a single critical flaw: treating MCP servers as plugins. That assumption quietly undermines system stability, especially when agents manage stateful connections across multiple backends. When a plugin crashes, it drags down its entire host process, wiping out in-flight tasks and cold caches. But when an MCP server runs as an independent process, it survives restarts, maintains its state, and keeps functioning even if its client disconnects.

The Architectural Shift That Prevents Silent Failures

MCP servers are designed to run independently, unlike plugins that live inside the agent’s process space. This distinction became clear during a critical Windows agent session routed through ark-delegator, a cross-environment bridge operating in WSL. The MCP server behind it crashed—not because the server itself failed, but because it was registered as a plugin tied to the agent’s daemon. Meanwhile, sibling servers like ark-exec on port 8101 and ark-memory on 8102 remained operational because they were managed by systemd, not the agent. The plugin died; the servers lived.

A Modular Stack Built for Survival

The setup revolves around a lightweight management layer called oh-my-mcp, deployed as a systemd user service. It exposes three key endpoints: a management API on port 8080, a gateway proxy on 8090, and supervised child processes handling specialized tasks. These include:

• ark-exec (port 8101): Executes MCP tools for command execution
• ark-memory (port 8102): Maintains a knowledge graph for memory operations
• ark-resolve (port 8103): Handles URI resolution across environments
• mempalace (port 8104): Provides vector semantic search capabilities
• ark-gist (port 8105): Manages operations on GitHub Gist repositories
• ark-delegator (port 8106): Routes tasks across different agents

Accompanying this is server-commands-rtk, a CLI bridge that routes unstructured commands through a filtered, audit-ready pipeline. It reduces token output by nearly 90% for large payloads while maintaining structured logging in JSONL format with automatic rotation.

Total schema overhead across all six MCP servers ranges from 8,000 to 10,000 tokens—less than half the overhead of a single GitHub MCP server, which can exceed 14,000 tokens. Each server can restart independently, ensuring that a failure in one component doesn’t cascade into the entire system.

Strategic Decision: Narrow Tools Over Monolithic Servers

The configuration file reflects this modular approach. Every MCP server uses stdio transport, emphasizing focus over breadth:

# oh-my-mcp config.yaml
servers:
  ark-exec:
    transport: stdio
  ark-memory:
    transport: stdio
  ark-resolve:
    transport: stdio
  mempalace:
    transport: stdio
  ark-gist:
    transport: stdio
  ark-delegator:
    transport: stdio

No single server hosts 93 tools. Instead, each runs 3 to 8 tightly scoped tools, ensuring the agent loads only the schemas necessary for the current operation. For operations requiring raw command execution—like checking package versions or pushing code—the system routes through server-commands-rtk:

server-commands-rtk_run_process({
  command: "npm view @ev3lynx/md-analyzer",
  cwd: "/home/ev3lynx",
  description: "check latest version"
})

This returns structured output including exit codes, duration, and error types without schema overhead. The result is a hybrid workflow: structured operations through MCP for memory, search, and CRUD, and raw CLI execution for commands with small outputs or side effects.

Quantifying the Benefits: Token Efficiency and Reliability

Real-world traces from production usage show significant token savings. For example, checking npm package downloads via an MCP tool returns only 170 tokens with three fields. The same operation via raw CLI with unfiltered output can exceed 2,000 tokens, dropping to around 400 with RTK filtering.

• MCP tool: 170 tokens
• Raw CLI unfiltered: over 2,000 tokens
• Raw CLI with RTK: ~400 tokens

Over a thousand weekly checks, the cumulative token difference becomes substantial. While a single call may not seem impactful, across a team’s collective session hours—especially at higher model tiers priced between $3 and $15 per million tokens—the savings are meaningful.

Conversely, operations like git push show the opposite advantage. With ~50 tokens for command and output, raw CLI execution wins due to zero schema overhead while delivering identical results.

The guiding principle: if the output has a known schema, build an MCP tool. If the command produces minimal output or triggers side effects, run it raw through the CLI bridge.

Logging Without Protocols: Audit Trails via CLI

A common misconception is that structured I/O in MCP is required for audit compliance. In reality, server-commands-rtk logs every command independently:

{
  "timestamp": "2026-07-08T10:01:27Z",
  "command": "git push origin main",
  "exitCode": 0,
  "duration_ms": 3240,
  "rtk_filtered": true
}

This structured logging occurs at the bridge layer, not the protocol layer. It provides the same compliance surface as MCP’s structured I/O but with greater architectural flexibility. The key insight: audit trails don’t require MCP. They require discipline in logging—something a CLI wrapper can achieve without adding schema complexity.

The Core Conflict: Process Independence vs Monolithic Dependence

The turning point came during a routine system check. Running systemctl --user status oh-my-mcp revealed all services green—ark-exec, ark-memory, ark-gist—all within their restart budgets. The plugin tied to the agent’s daemon had failed, but the MCP servers had not.

This isn’t a debate about MCP versus CLI. It’s about lifecycle independence. A plugin shares its parent’s mortality. An MCP server manages its own. In a 24-hour agent managing stateful connections across six backends, this difference is existential. A plugin cannot recover its state after a crash. An MCP server not only survives but continues serving clients that reconnect later.

The Final Pattern: Three-Tier Dispatch for Production Workflows

The production system now operates on a three-tier dispatch model:

• MCP Server Tier: Focused, 3–8 tools per server for structured operations the agent uses every session. These servers run as independent processes with lifecycle independence.
• CLI Bridge Tier: server-commands-rtk handles ad-hoc commands, small outputs, and side effects. It includes RTK filtering and structured audit logging.
• Hybrid Dispatch Logic: The agent decides at runtime—query, search, or read? Use an MCP tool. Execute, write, or push? Use raw CLI. Need audit trails? Route through the CLI bridge.

The logic is encapsulated in a dispatch function:

def dispatch(operation):
  if operation.type in ("query", "search", "read"):
    return call_mcp(operation)
  elif has_tool(operation):
    return run_raw(operation)
  else:
    return run_raw_rtk(operation)  # CLI with audit logging

This pattern ensures operational resilience, token efficiency, and compliance without architectural rigidity. It treats the agent not as a monolith, but as a network of specialized, survivable components—each with its own heartbeat and recovery mechanism.

The Lesson: Architecture Dictates Resilience

Six focused MCP servers outperform one general server in both performance and reliability. Total schema overhead remains under 10,000 tokens, a fraction of what a single broad server demands. The agent carries less dead weight on every request, and when something fails, only one node falls—not the entire system.

This approach isn’t about technology for technology’s sake. It’s about building systems that don’t just work—they endure. In AI workflows where state, cost, and uptime matter, independence isn’t optional. It’s essential.