The Closing
Every series earns its final paragraph. This one earned a full article.
The question I started with was: MCP or CLI — which is cheaper? The answer, after 10 sources, 6 MCP servers, a CLI bridge, a container stack, four layers of wrong assumptions, and five articles, is: it's the wrong question.
The real question is: What survives?
Part 1: The Token Cost Theory
The numbers held up. External benchmarks matched our measurements: MCP at ~170 tokens per call, raw CLI at ~460 (with filtering) or ~3,100 (without). Schema overhead for a 93-tool monolith hit 55,000 tokens — $51,000/month at scale.
The insight that survived wasn't the cost numbers. It was the G/N ratio: for a tool used on 2 of 20 prompts, 99.3% of MCP tokens are wasted on schema descriptions the agent never needed. The problem isn't MCP's per-call cost. It's the injection pattern — loading every schema into every prompt regardless of need.
Add a gateway. Filter schemas by actual usage. Then MCP's per-call cost becomes negligible.
Part 2: The Hybrid Architecture
The plugin died with the daemon. The MCP servers didn't. That frozen moment — checking the process table and seeing ark-memory still running on 8102 — is the single insight that shaped everything after.
Lifecycle independence isn't architectural theory. It's the difference between a system that recovers its own state and one that leaks it, session by session.
The quote that survived: "A plugin inherits its parent's mortality. An MCP server manages its own."
Part 3: The Container Stack
The container decision looked like overhead on day one. Looked like the obvious choice by WSL instance three. The insight that holds across every deployment conversation since: the cost of environment-specific setup scripts compounds with every new target. The cost of the container is paid once.
The pattern that survived: one image, many clients, zero per-target configuration. From any WSL instance, from Windows, from CI — the same stack, the same servers, the same behavior.
Part 4: The Decision Tree
PR #1372's 77-day lifecycle taught me more than any benchmark. The four-layer decision tree (plugin vs server, stdio vs SSE, focused vs monolith, MCP vs CLI) was extracted from production failures, not architecture theory. Every wrong choice is documented in a closed PR, a deleted file, or a systemd restart that wiped a session.
The rule that survived: An MCP server isn't a plugin you run differently. It's a process that survives its client.
What Didn't
Not everything from this series survived contact with production.
The 93-tool GitHub monolith didn't survive. Replaced by 3 focused servers.
The per-WSL install scripts didn't survive. Replaced by one container.
The git-push MCP tool didn't survive. Replaced by a 50-token shell command.
The assumption that better benchmarks lead to better architecture didn't survive either. The numbers helped us find the problem. The failures helped us understand it.
What Changed
Before this series, our MCP strategy was: build a tool for everything, deploy it however, optimize later.
After this series, the strategy is:
- MCP for structure, CLI for execution. Queries need typed schemas. Actions need zero overhead.
- Focused servers win. 3-8 tools. One domain. ~1,500 tokens per server. Independently deployable.
- Containers are the default deployment. One image, any client. WSL, Windows, CI — same stack.
- The decision tree runs before the first line of code. The wrong architectural choice at layer 1 compounds through every later layer.
The Closing
The stack that survived: oh-my-mcp gateway for lifecycle management. commands-rtk CLI bridge for everything else. Six MCP servers, each with 3-8 tools, each a standalone process with its own port and its own logs.
Build processes that survive client death. Route schemas that match actual usage. Make the architectural decision before the first line of code — and when you get it wrong, close the PR and rewrite it. It'll take three days, not seventy-seven.
Top comments (0)