DEV Community: Ev3lynx727

The Hybrid Agent: A Retrospective

Ev3lynx727 — Mon, 13 Jul 2026 14:40:45 +0000

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.

The Integration Decision Tree: Plugin vs MCP Server vs CLI Bridge

Ev3lynx727 — Mon, 13 Jul 2026 14:21:29 +0000

Hook

When building local-first architectures, the instinct is often to tightly couple everything. If a system needs a new shell execution tool or a data filter, the default move is to drop it in as an in-memory plugin. It feels like the cleanest path: it runs in the same process, shares the same lifecycle, and requires zero initial configuration.

But that tight coupling is exactly where local systems fracture.

As the environment grows, the plugin model starts exposing its limits. You lose process ancestry when a local daemon restarts. You hit cold caches on reconnections. You lose your audit trail because plugins can't log independently from the host process, burying critical observability.

What starts as a simple 20-line feature turns into an architectural bottleneck.

The problem isn't the code itself — it is the execution boundaries. The difference between a fragile monolithic local setup and a resilient, modular ecosystem comes down to the architectural decision made before the first line of code is written: Should this be a Plugin, a standalone MCP Server, or a CLI Bridge?

The Wrong Assumption

The pattern we followed at first was: new capability equals new plugin. It was the obvious path — OpenCode's plugin system is well-documented, auto-discovered from ~/.config/opencode/plugins/, zero deployment. Drop a .ts file, restart, it works.

The first plugin was fine. The second was fine. By the sixth, we had the same two bugs across three different frameworks:

Process ancestry loss. Every plugin inherits OpenCode's process table. When the daemon restarts (config change, crash, update), every plugin restarts with it — cold cache, empty connection pools, every in-flight task evaporated.
Silent death. A plugin crash doesn't surface. The parent process catches the exception, logs it to its own log, and continues. The plugin is gone. No one knows until the next session fails to find the tool.

The first time I noticed was when ark-delegator stopped routing tasks. No error. No alert. Just a silent gap in the process table. The plugin had died with the daemon restart three hours earlier.

The Decision Tree

Four layers. Each layer is one decision, not a configuration. The wrong choice at any layer compounds through every later choice.

Layer 1: Plugin or MCP Server?

Plugin?
→ Same process: zero config, zero network, zero deployment
→ Same mortality: daemon restart = plugin restart
→ Same visibility: plugin crash = silent death
→ No independent logging: must use parent's logger

MCP Server?
→ Own process: survives client death, restarts independently
→ Own logs: stdout/stderr captured by supervisor
→ Network boundary: SSE port, reachable from any client
→ +58ms overhead: stdio establishment per request

Answer: If the tool must survive a daemon restart — and every production tool should — it's an MCP server. The plugin is for prototyping, not production.

We discovered this ordering wrong. We started with plugins because they were easier. We should have started with servers because they survive.

Layer 2: Stdio or SSE?

Stdio (child process)?
→ Zero network: works offline, no latency
→ No auth: stdin/stdout within same machine
→ Version-controlled: pin exact npm version
→ Process isolation: crash doesn't cascade
→ 2.7GB RAM per session — 45 processes for 6 servers

SSE (remote endpoint)?
→ Shareable: one server, N clients
→ Survives sessions: client disconnects, server stays
→ Port-based: numbered allocation, no collision
→ Docker-compatible: map ports, exec from any container
→ ~3 seconds startup per server (supergateway)

Answer: Stdio for single-machine, single-session dev. SSE for anything shared between clients, sessions, or machines.

Our first approach was npx-based stdio for everything: npx @ev3lynx/oh-my-mcp spawned three processes (sh → npx → node), each server consumed ~450MB, and every new WSL instance needed the same install. We ran out of RAM at 6 servers. The switch to SSE via supergateway cut per-server overhead in half and made them shareable.

Layer 3: Focused or Monolith?

Focused (3-8 tools)?
→ 8,000-10,000 tokens total schema for all 6 servers
→ Agent loads only what it needs for current operation
→ Independent versioning: update one without touching others
→ Easy to replace: swap one server, not the catalog

Monolith (93 tools)?
→ 55,000 tokens of schema — $51,000/month at scale
→ Everything in every prompt, used or not
→ One bad tool update breaks the whole server
→ Hard to audit: 93 tools, who uses which?

Answer: If a tool group fits in 3-8 operations, it's a focused server. If it exceeds 8, split. The constraint isn't technical — it's cognitive. 8 tools is the number of items the human brain can hold in working memory.

We made this mistake once: a single GitHub server with 93 tools. The schema tax was 55K tokens. We never used 80 of those tools. The fix was replacing it with 3 focused servers (repo ops, issue tracking, code search).

Layer 4: MCP Tool or CLI Bridge?

MCP Tool?
→ Structured output: known schema, capped response
→ 170 tokens per call, schema overhead per session
→ Best for: query, search, read operations

CLI Bridge?
→ Unstructured: whatever the command returns (RTK-filtered)
→ 50 tokens per call, zero schema overhead
→ Best for: execute, push, write operations
→ Audit trail: JSONL logger, exit codes, duration

Answer: Read through MCP, write through CLI. Queries need structure. Actions need speed.

We spent a week building an MCP tool for git push. It returned "done" in JSON. We deleted it and went back to git push origin main — 50 tokens, same result, fewer lines of code to maintain.

The Rule That Handles 95% of Decisions

After four layers of mistakes, one rule covers almost everything:

Is the operation a query?         → MCP tool (structured, typed)
Is it a side effect with small output? → CLI bridge (fast, audited)
Does it need to survive a restart? → MCP server (own process)
Is it a prototype?                → Plugin (fast, temporary)
Does it run on more than one machine? → Container (one image, many clients)

This isn't theory. These are the rules we extracted from production failures. Every wrong choice is documented in a closed PR, a deleted file, or a systemd restart that wiped a session.

The Closing

The PR that took 77 days wasn't slow because the code was hard. It was slow because we were solving the wrong problem — fitting a server-shaped capability into a plugin-shaped hole. The moment we admitted the architecture was wrong, the implementation took three days.

The stack: oh-my-mcp + commands-rtk. The decision tree: four layers, one rule. The lesson: the architectural decision before the first line of code determines whether delivery takes 77 days or three.

An MCP server isn't a plugin you run differently. It's a process that survives its client.

Hybrid Container Governance: Scaling Patterns That Work

Ev3lynx727 — Fri, 10 Jul 2026 16:26:44 +0000

Hook

The third WSL instance didn't need a reinstall. That's when I knew the pattern worked.

WSL 1 had the full stack — six ark-* MCP servers, oh-my-mcp gateway, server-commands-rtk, all configured, tested, running. WSL 2 was planned for the same setup. So was WSL 3. Each one would need npx @ev3lynx/oh-my-mcp, the npm dependencies, the config files, the supergateway wrappers, the port allocations, the CLI bridge, the permission schema in opencode.jsonc.

I started scripting the install. Halfway through, I stopped and deleted the script.

Installing the same stack N times is the wrong answer. The right answer is one installation, served.

The Container Decision

The architecture we'd built was already multi-process — oh-my-mcp managing six child servers, each with its own port, its own lifecycle, its own restart budget. The step from "multi-process on one machine" to "multi-WSL via one container" was smaller than expected:

FROM ghcr.io/anomalyco/opencode:dev-debian

# oh-my-mcp gateway
RUN npm install -g @ev3lynx/oh-my-mcp

COPY supervisord.conf /etc/supervisor/conf.d/opencode-stack.conf

CMD ["supervisord", "-c", "/etc/supervisor/conf.d/opencode-stack.conf"]

The container runs two supervised processes:

opencode serve --hostname 0.0.0.0 --port 4096
oh-my-mcp --port 8090 (management API on 8080)

Ports exposed: 4096 (OpenCode SSE), 8080 (management), 8090 (MCP gateway).

Volume mounts for persistence:

volumes:
  - ~/.config/opencode:/home/ev3lynx/.config/opencode
  - ~/.local/share/opencode:/home/ev3lynx/.local/share/opencode
  - ~/server:/home/ev3lynx/server
  - ~/.ssh:/home/ev3lynx/.ssh
  - /var/run/docker.sock:/var/run/docker.sock

From any WSL instance: docker exec -it opencode-stack opencode. Same env, same config, same servers. Zero npm installs per distro.

The Poorly-Designed Alternative

But I didn't start with a container. I started the wrong way.

The first WSL instance got the full manual setup: npx @ev3lynx/oh-my-mcp install, fnm multishell resolution, port allocation for each ark server, supergateway wrappers for every stdio→SSE bridge, systemd user service registration, and a fire-and-forget shell script that was already one edit away from breaking silently.

When WSL 2 needed the same thing, I ran the script again. It failed because systemctl --user doesn't behave the same across WSL instances — Debian's systemd vs Alpine's OpenRC vs Ubuntu's snap-wrapped systemd. The paths were different. The fnm node version was different. The /run/user/1000/ socket path was absent on the second instance because the user ID was 1001.

I spent an afternoon fixing environmental drift between two WSL instances that were supposed to be identical. I caught myself debugging the wrong thing: not the architecture, not the code — but the installation path.

That was the moment the container decision made itself. Not because containers are trendy. Because I was debugging installation scripts instead of shipping features.

The Conflict

The tension isn't technical. The container is trivially simple — a Dockerfile, a docker-compose.yml, a volume mapping. The tension is architectural: we had built an MCP server ecosystem without a deployment story. Every server in the ark-* family was designed as a standalone process with clear boundaries (focused tools, independent lifecycle). But standalone doesn't mean deployable. A process without a reproducible environment is a test that passes on your machine.

Here's the voice that argues against it:

"It's three WSL instances. You can script the install. Docker adds overhead, a learning curve for the next person, another moving part. A Makefile and a README note is cheaper."

This voice isn't wrong — it's looking at the right cost but the wrong time horizon. At WSL 3, the Makefile is still fine. At WSL 5, when they're different distros (Debian, Ubuntu, Alpine, Fedora, Arch), each with different systemd quirks, different package managers, different default shells — the Makefile becomes a liability audit. At a CI runner and a team member's machine and a deployment target, it's a full-time maintenance job.

The cost of the container is paid once. The cost of environment-specific setup scripts compounds with every new target.

The Governance

Six servers is a manageable number. Sixteen is not — unless you have a pattern that makes each one predictable.

Every ark-* server follows the same template:

A focused tool set — 3-8 tools, one domain (memory, gists, exec, resolve, delegation)
Supergateway stdin→SSE wrapper — port 8100-series, registered in oh-my-mcp
Standalone process — systemd or supervised, never a plugin
cacache or sqlite storage — disk-backed, survives restart
Cache stats + prune tools — self-maintaining, no cron needed

Adding a new server is five files, not five hours:

server/ark-<name>/
├── package.json         # @ev3lynx/ark-<name>
├── tsconfig.json        # extends base
├── src/server.ts        # tool handlers
└── .github/workflows/   # CI (ci.yml, publish.yml)

Build → oh-my-mcp add --path server/ark-<name> → registered. No config file edit. No port conflict check. The gateway discovers it, assigns a port, and routes traffic.

The governance rule that handles 90% of decisions:

Would this tool be used on most sessions? → Add it to an existing focused server (3→8 tools)
Would this tool be used rarely or by a specific client? → New ark-* server (1 domain, 3-8 tools)
Is this a write-once-read-never operation? → CLI bridge, no server needed

What the Container Makes Possible

The container stack isn't just about deployment repeatability. It changes the capability surface entirely:

From any WSL instance: docker exec -it opencode-stack opencode — same servers, same config, same memory graph. Sessions are portable across distros. Switch from Debian to Alpine to Arch without losing connection state.

From Windows: ark-delegator resolves via http://localhost:8106 — the port is mapped through Docker and accessible from the Windows host. The Windows OpenCode client sees the same MCP servers as every WSL instance. No network bridging. No WSL path translation.

From CI: The same container image. docker run opencode-stack opencode eval "run tests" — CI gets the exact same tool set as interactive sessions. No drift between development and pipeline environments.

This is the pattern that survives: one image, many clients, zero per-target configuration.

The Closing

The Makefile argument was right about the cost — just wrong about which cost compounds. The container is heavier on setup day. It's lighter on every subsequent day. And on the day WSL 5 shows up with a package manager you've never heard of, the container costs nothing at all.

The stack: oh-my-mcp gateway + commands-rtk CLI bridge. The template: five files per ark-* server. The rule: one image, many clients — install once, exec everywhere.

Build tools that survive restarts. Build processes that survive machine boundaries. Build stacks that don't care which WSL distro the terminal opened today.

How We Use MCP and CLI Together for Dynamic AI Agent Workflows

Ev3lynx727 — Thu, 09 Jul 2026 11:50:48 +0000

Hook

The Windows agent went silent mid-session. It had been routing tasks through ark-delegator — a cross-environment bridge that lives in WSL. But the MCP server behind it had crashed with OpenCode's last daemon restart, because it was registered as a plugin. Same process. Same failure. Same data loss.

I checked the process table. ark-memory was still running on port 8102. ark-exec was healthy on 8101. Every MCP server was alive — because they were managed by systemd, not by OpenCode. The plugin was dead because plugins live inside the agent's process. The MCP servers were fine because MCP servers are independent.

That was the day I stopped treating MCP servers as plugins.

The Stack

oh-my-mcp (systemd user service)
  ├── port 8080: Management API
  ├── port 8090: Gateway (MCP proxy)
  └── child processes (supervised):
        ├── 8101  ark-exec        → exec MCP tools
        ├── 8102  ark-memory      → memory knowledge graph
        ├── 8103  ark-resolve     → URI resolution
        ├── 8104  mempalace       → vector semantic search
        ├── 8105  ark-gist        → GitHub Gist operations
        └── 8106  ark-delegator   → cross-agent task routing

server-commands-rtk (the CLI bridge)
  ├── stdin/stdout → spawns processes
  ├── RTK filter   → ~90% token reduction on large output
  └── audit logger → append-only JSONL with rotation

Six MCP servers, each with 3-8 focused tools. One CLI bridge for everything else. Total schema overhead: ~8,000-10,000 tokens across all six — less than a single GitHub MCP server alone.

Every server is a standalone process. Every one can restart independently. Every one is reachable from any client on the network via SSE on its port. The plugin model gives you in-process speed. The MCP server model gives you survival.

The Architecture Decision

# 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

All MCP. All focused. No monolithic 93-tool server. The decision was deliberate: six narrow servers mean the agent loads only the schemas it needs for the current operation, not a catalog of everything it might ever do.

For raw commands, we route through server-commands-rtk:

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

This is the hybrid in practice. Structured operations through MCP (memory, search, CRUD). Everything else through a CLI wrapper that happens to look like an MCP tool.

The Numbers

Package downloads check — a real trace from running both paths through our commands-rtk CLI bridge:

npmPackageDownloads("md-analyzer")
→ 170 tokens, 3 fields

npm view @ev3lynx/md-analyzer | grep -A5 downloads
→ 2,000+ tokens unfiltered, ~400 with RTK

MCP tool wins: 2.4x cheaper than raw+RTK, 12x cheaper than unfiltered.

Over a thousand such checks per week — that token difference adds up. Not enough to matter on one call. Enough to matter across a team's collective session hours at $3-15/M tokens depending on your model tier.

Git push:

git push origin main
→ ~50 tokens command + ~50 tokens output

Raw CLI wins: zero schema overhead, same result.

The rule: if the output has a known schema, build a tool. If the command is an action with small output, run it raw.

The audit logger

server-commands-rtk logs every command:

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

This is the insight that MCP-vs-CLI debates miss: audit trails don't require MCP. A CLI wrapper with structured logging gives you the same compliance surface as MCP's structured I/O. The difference is architectural — logging at the bridge layer, not the protocol layer.

The Conflict

The next morning I ran systemctl --user status oh-my-mcp. Every service was green. ark-exec, ark-memory, ark-gist — all running, all within their restart budgets. The plugin had died. The MCP servers had not.

It's not MCP vs CLI. It's single-process vs independent-process.

The failing plugin shared OpenCode's process table. When the daemon restarted, the plugin restarted with it — but it surfaced with empty connection pools, a cold cache, and every in-flight task evaporated. The MCP server on port 8106 had never noticed the restart. Its client had disconnected. It kept receiving. It was still there when the next session connected.

Lifecycle independence. A plugin inherits its parent's mortality. An MCP server manages its own.

This sounds architectural-theoretical until you run a 24-hour agent managing stateful connections across six backends. Then it reveals itself as the difference between a system that recovers its own state and one that leaks it, session by session.

The Resolution

The pattern we settled on is three-tier:

MCP server (focused, 3-8 tools)
  → structured operations the agent uses every session
  → independent lifecycle, restart survives client death

CLI bridge (server-commands-rtk with RTK + audit)
  → ad-hoc commands, small output, side effects
  → audit logging without MCP schema overhead

Hybrid dispatch (decision at the agent level)
  → Query/search/read? MCP tool
  → Execute/write/push? Raw CLI
  → Audit required? CLI bridge with structured logger

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

This runs in production for every session. The gateway routes, the MCP servers serve, and the CLI bridge handles everything else with logging.

What We Learned

Six focused MCP servers beat one general one. Our ~8K total schema overhead is less than a single GitHub MCP server at ~14K. Fewer tools per server means the agent carries less dead weight on every request.

The gateway pattern is the right default. Near-zero overhead (~20 tokens/prompt). MCP-quality outputs. Linear scaling. No single-server blob.

And the rule that handles 95% of decisions: MCP for structure, CLI for execution. Build tools that return answers, not documents. Run commands that do things, not queries that return everything.

The Closing

The MCP backlash is real, but the target is wrong. The problem isn't the protocol — it's installing everything into one process. A plugin crashes with its host. An MCP server survives, restarts, and waits for the next client.

Lifecycle independence isn't a nice-to-have. It's the feature that makes the rest possible.

Stack details: Lifecycle managed via the oh-my-mcp (port 8080); CLI wrapping, RTK filtering, and audit logging handled by commands-rtk. Core `ark- services run in server/` as standalone MCP servers, not plugins.*

Tools vs Raw Commands - The Token Cost Theory - Part 1

Ev3lynx727 — Wed, 08 Jul 2026 10:52:09 +0000

The Hook

Scalekit ran 75 benchmark runs comparing CLI and MCP agents on identical GitHub tasks. CLI was 10 to 32x cheaper and 100% reliable. MCP hit only 72% — failing on more than a quarter of tasks (source).

Perplexity's CTO reported that MCP tool descriptions consumed 72% of the available context window before the agent performed any actual work (source).

The narrative is everywhere: MCP is the future, CLI is legacy. But the numbers tell a different story — and one where the real answer isn't "pick one."

The Token Cost Theory

Every interaction an AI agent makes has a token price — input tokens (the instruction) + output tokens (the response). Multiply by the token rate, and you get the real cost of a single operation.

But there's a hidden variable: schema overhead. Every MCP server exposes tool definitions — names, descriptions, JSON input schemas. These get injected into the LLM context on every single request, whether you call the tool or not.

PolicyLayer measured 3,875 MCP servers and found a median of 2,064 tokens per server in tool definition overhead (source). A GitHub MCP server alone clocks 14,406 tokens. Connect GitHub + Linear + Supabase: 24,116 tokens — 12% of a 200K context window, before the first message.

The numbers, in my agent

I measured three modes across common operations:

Tool Call:

Input:  50 tokens (tool name + args)
Output: 100 tokens (structured JSON response)
Framing: 20 tokens
Total:  ~170 tokens

Raw Command (with RTK filtering):

Input:  30 tokens (command string)
Output: 350 tokens (RTK-filtered stdout)
Wrapper: 80 tokens (exit code, error type)
Total:  ~460 tokens

Raw Command (unfiltered):

Input:  30 tokens
Output: 3,000 tokens (raw terminal output)
Wrapper: 80 tokens
Total:  ~3,110 tokens

The spread: 1x, 2.7x, 18x — same intent, different delivery.

The real numbers from benchmarks

Independent research paints a wider gap. Afroze Amjad benchmarked graph-cli as both CLI and MCP, finding MCP's per-turn cost was consistently higher — the schema catalog ships with every request (source). When tools hold 50+ schemas, that overhead compounds.

The worst case: a 93-tool GitHub MCP server at 55,000 tokens of schema alone. At $3/M input tokens (Claude Sonnet), that's $0.17 per request for schema the agent doesn't use. At 10,000 requests/day: $51,000/month in schema tax (source).

Why This Matters at Scale

Per-operation costs are academic until you stack them. Here's 100 operations:

Pattern	100 ops	Token cost	Relative
Tool calls	17,000	~$0.17	Baseline
Raw + RTK	46,000	~$0.46	2.7x
Raw unfiltered	311,000	~$3.11	18x

The difference between a tool-oriented agent and a raw-command-oriented one over 100 retrievals: $0.29 vs $2.94. At 1,000 operations, that's $2.90 vs $29.40.

But these numbers assume one MCP server. Most agents run 5+ servers (GitHub, Slack, Postgres, Sentry, Filesystem). At 5 servers averaging 2,064 tokens each, that's 10,320 tokens per request just to keep tool descriptions warm — whether the agent runs one operation or zero.

The G/N ratio is the missing variable

The cost structure flips based on how often you actually use a tool (source):

Tool frequency	Session cost (20 prompts, 2 GitHub ops)	vs. CLI baseline
Low (G/N < 5%)	61,654 tokens (Native MCP)	137x
Medium (G/N 5-40%)	892 tokens (Gateway MCP)	2x
High (G/N > 40%)	892-1,492 tokens	Negligible

For a tool used on 2 of 20 prompts (10% frequency), 99.3% of MCP tokens are wasted on schema descriptions the agent never needed (source).

The Conflict

But here's the catch: tools aren't free to build. Every dedicated tool must be written, tested, maintained, and updated when the upstream API changes. npmPackageDownloads is 20 lines of TypeScript. The npm view CLI command it replaces was written by npm's team.

The CEO voice in me asks: Why am I duplicating infrastructure that already exists?

Here's the scene that answers that. I'm sitting in WSL, my agent wants to check a package version. It calls npm view — a raw shell command. The output comes back: 2,140 lines of package metadata, README, maintainer list, dependency tree, signature hashes. What I wanted was one field. What I got was a firehose.

The tool call: 170 tokens. The raw command: 2,500+ tokens. The tool was 15x cheaper on that single operation.

Afroze Amjad found the same pattern with graph-cli: CLI saves on cost, MCP saves on latency and discovery. The right answer depends on which dimension your workload optimizes for (source).

Estimation without measurement is anxiety wearing arithmetic as a disguise. So I measured.

The Resolution

Three patterns cut MCP's token cost dramatically:

1. Schema filtering. Instead of injecting all 93 GitHub tool schemas, a routing layer returns only the 2-3 tools relevant to the current request. This alone cuts MCP token usage by ~90% (source).

2. Gateway pattern. Near-zero fixed overhead (~20 tokens/prompt), MCP-quality structured outputs, linear scaling regardless of backend services (source).

3. Hybrid dispatch. The most practical setup (source):

┌─ Query / retrieval?      → MCP tool (structured, typed, fast)
├─ Execute / side effect?  → Raw CLI (small output, no schema needed)
├─ Large output expected?  → MCP tool (schema caps response size)
└─ Filter / pipe needed?   → Raw CLI (jq, grep, UNIX pipes work)

This dispatch matrix cut one practitioner's token usage by 60% — $8.64/day to $3.45/day (source).

The Closing

The MCP backlash is real, but the target is wrong. The problem isn't the protocol. It's the native injection pattern — loading every schema into every prompt, whether the agent needs it or not. The schema tax dominates until you actively manage it.

MCP's per-call cost is a deployment problem, not a protocol problem. Good tool design means routing the tool surface to match actual usage patterns, not defaulting to everything for everyone.

Build tools that return answers, not documents. Route schemas that match actual usage, not every possibility. And when the task is a one-shot retrieval with a CLI you already know: run the command. The token market thanks you either way.

Sources: Scalekit MCP vs CLI Benchmark · Afroze Amjad graph-cli comparison · OnlyCLI token cost benchmark · Mornati MCP vs CLI deep-dive · PolicyLayer MCP cost calculator · Dev.to hybrid dispatch case study · Tyk enterprise comparison guide

The Architecture That Almost Shipped: A Builder Reflection on Deadlines, Cost Anxiety, and What Survives Both

Ev3lynx727 — Fri, 12 Jun 2026 19:37:58 +0000

By Ev3lynx · CTO · Builder · AI Systems Architect

The competition closed at midnight. My build was green at 11:47. I never hit submit.

That terminal window is still in my session history. The cursor blinking at a prompt I walked away from. The browser tabs: YouTube Music on lo-fi, the RSVP page for #JuaraVibeCoding's kick-off — 5,183 people signed up — and a pyproject.toml I'd been polishing for three weeks.

I closed the laptop. I'd submit in the morning.

By morning, the deadline had passed.

This is the story of Ghostclaw — a hybrid Python/TypeScript systems architecture built for Google Indonesia's #JuaraVibeCoding 2026. Designed, built, production-tested. Never submitted. Ships every day.

This is not a postmortem. It's a reminder that what survives the deadline is often more valuable than what meets it.

The Context

In May 2026, Google Indonesia launched #JuaraVibeCoding — a nationwide study jam promoting vibe coding with Google AI Studio, Gemini, and Cloud Run. The engineering track on May 20 drew 768 RSVPs. Campus events at IPB, Airlangga, and Brawijaya followed through end of May. Top entries received swag and e-wallet rewards.

We saw it as the perfect proving ground for an architecture pattern we had been refining across multiple projects — the hybrid module: a single package that ships as a CLI tool, an importable library, and an MCP server for AI agents, all sharing one service layer.

The project: Ghostclaw — a code analysis engine, a pluggable plugin system, and an MCP server, rolled into one pip install.

What Ghostclaw Actually Is

## Four entry points, one codebase
ghostclaw             # CLI — analyze, review, report
ghostclaw-watcher     # Continuous file watcher
ghostclaw-compare     # Diff-based regression analysis
ghostclaw-mcp         # MCP server — 14 tools for AI agents

Four binaries from a single hatchling build. Each entry point is a click.Group subclass registered via project.scripts. The base Command ABC handles argument parsing, error formatting, and output serialization. Adding a subcommand means writing one class and one line in pyproject.toml.

The plugin system uses pluggy with entry-point discovery. Third-party developers extend Ghostclaw without forking — install a separate PyPI package that registers a ghostclaw.plugins entry point:

[project.entry-points."ghostclaw.plugins"]
my_analyzer = "my_package.plugin"

The MCP server exposes 14 tools — code analysis, NTP calibration, IMF economic data, DNS dig, currency conversion. Every tool is a pure function decorated with @mcp.tool().

The TypeScript counterpart ships as a dual ESM/CJS package with submodule exports:

{
  "exports": {
    ".": { "import": "./dist/index.mjs", "require": "./dist/index.cjs" },
    "./mcp": { "import": "./dist/mcp/index.mjs" },
    "./watcher": { "import": "./dist/watcher/index.mjs" }
  }
}

Every subpath individually typed, individually importable, individually tree-shakeable.

This was the architecture we wanted to submit as our competition entry. Not as a demo, but as a reference implementation of the hybrid module pattern at production scale.

The Conversation That Killed the Submission

I remember the exact moment. Wednesday night, 1 AM. I was staring at the environment variables I'd wired into the config loader — every one prefixed with GHOSTCLAW_. The CLI was passing integration tests. The MCP server was responding to tool calls. linter was clean.

And I was calculating.

"Okay — Cloud Run, one always-on instance, memory overhead for MCP... maybe 20 dollars a month. Plus Rust build in CI, that's GitHub Actions minutes. Dashboard if I add one..."

I reached for a calculator.

The voice in my head that plays CFO when the real one is sleeping pushed back: "We don't even know if we'll place. Is this worth the time?"

The answer should have been obvious. The MCP server doesn't bind a port. It reads stdin and writes stdout. The CLI runs and exits. Zero database, zero always-on services, zero infrastructure.

No database? ✅ Zero
No server to keep alive? ✅ Zero
MCP runs on stdio? ✅ Zero
CI on GitHub Actions? ✅ Zero

But I didn't check. I estimated. And estimation without data is just anxiety wearing arithmetic as a disguise.

I closed the calculator. I told myself I'd figure it out tomorrow.

Tomorrow was June 1. The deadline had passed.

That's the part I don't talk about in standups. Not that the code was hard — it wasn't. The architecture was sound. The deploy cost was zero.

The thing that killed the submission was a conversation I had with myself at a desk, with a calculator, at 1 AM.

The Pattern That Outlived the Deadline

The submission window closed. The workshops ended.

The architecture settled into daily production use.

Within two weeks, we extracted Ghostclaw's structural patterns into reusable skills — documented blueprints that scaffold new projects with the same architecture:

hybrid-bot-server-builder — CLI + Telegram/Discord bot, one service layer
hybrid-module-esm-builder — TypeScript dual ESM/CJS + submodule exports
hybrid-module-py-builder — Python src layout, pluggy plugins, maturin addons

Each is a complete project template. Run it, get a working hybrid module with CI, tests, docs, and publish config. No manual wiring.

Ghostclaw continues as the reference implementation — the project where all three patterns converge: Python hybrid package, TypeScript dual-ship module, and MCP server, sharing one service layer through protocol-agnostic interfaces.

Two downstream projects now use this architecture:

snapx-app — hybrid CLI + Telegram bot with provider fallback chains
wristworks — TypeScript dual-ship with native Rust via napi-rs

The submission never happened. The pattern is in production.

There's No Numbered Advice Here

Three weeks after the deadline, I needed to scaffold a new Python project — a bot server with a CLI interface, Telegram integration, and provider fallback chains. The old me would have started from scratch, copied files from an old project, and spent two hours wiring everything together.

Instead, I ran a skill I'd extracted from Ghostclaw's architecture. It generated the full project structure in three seconds.

That skill exists because Ghostclaw's architecture was built to be extracted. The src/ layout. The Command ABC. The pluggy hooks. The try/except ImportError fallback chains that let it degrade gracefully from full-featured to minimal. Every pattern was written with extraction in mind — even when I didn't know what I was extracting for.

That's the takeaway, without bullet points: Build what outlives you. Not the demo. Not the submission. The architecture. The patterns. The reusable thing that makes the next project faster, cleaner, and more likely to ship.

Because deadlines come and go. A well-abstracted project template ships every week.

The Part That Matters

A few people have asked: was it worth it? Building an entire architecture for a competition we never entered?

Yes. Because the architecture is still here. The competition is over. Ghostclaw ships on every pip install. The skills scaffold new projects every week. The pattern propagates.

That's the part that matters: not whether you hit a deadline, but whether what you built survives the deadlines you miss.

Ghostclaw: github.com/Ev3lynx727/ghostclaw

Built for #JuaraVibeCoding 2026 — submitted late, shipping daily.