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?
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 — every schema into every prompt regardless of need.
Add a gateway. Filter schemas by actual usage. Then MCP's per-call cost becomes negligible.
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."
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.
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.
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.
Before this series, our MCP strategy was: build a tool for everything, deploy it however, optimize later.
After this series, the strategy is:
The stack that survived: oh-my-mcp gateway for lifecycle management.
commands-rtk
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.