Muneeb Hussain - Backend Systems Engineer

A structured debate that settles the 2026's hottest AI agent architecture argument.

In late February 2026, Eric Holmes published "MCP is dead. Long live the CLI" and it hit the Hacker News front page like a grenade. Garry Tan, YC's CEO, followed up on X with a blunt "MCP sucks honestly." The AI agent community split into two camps overnight.

One side says MCP (Model Context Protocol) is unnecessary abstraction. The other says every major tech company has already committed to it. Benchmarks got thrown around. Blog posts multiplied. Everybody had an opinion.

So we debated it — properly. Point by point, claim by claim, until there was nothing left to argue. Here's how it went down, and where we landed.

The Numbers That Started the War

Before opinions, the data. Recent benchmarks paint a clear picture:

Metric	CLI	MCP
Tokens for a simple repo query	1,365	44,026 (32x more)
Reliability	100%	~72%
GitHub tool context cost	~0 (pre-trained)	~55,000 tokens (93 tools)
Context burn (real-world team)	Minimal	143,000 / 200,000 tokens (72%)

Perplexity publicly dropped MCP from its agent architecture. Internal benchmarks showed 15-20x token overhead for equivalent tasks. That's not a rounding error. That's a fundamentally different cost structure.

Round 1: The Safety Argument

The MCP claim: Giving an agent raw database access is dangerous. A read-only MCP server is inherently safer than handing the agent a psql connection.

The CLI response: Build a CLI wrapper.

#!/bin/bash
# mydb — a read-only CLI wrapper
psql -h $DB_HOST -U readonly_user --set=ON_ERROR_STOP=on -c "$1"

Same safety. Fraction of the tokens. Took 30 seconds to write. The MCP server solving this problem is a JSON-RPC transport layer, schema definitions, capability negotiation, and a long-running process — all wrapping the exact same psql call underneath.

Verdict: CLI wins. The wrapper is trivially simple and strictly cheaper to build and run.

Round 2: Multi-Tenant Authentication

The MCP claim: CLI is single-user. MCP handles OAuth, dynamic auth across multiple users, enterprise SSO. You need MCP for multi-tenancy.

The CLI response: We've had multi-tenant CLI auth for years.

aws sts assume-role — cross-account, scoped credentials
gcloud auth login --account — multi-identity
docker context use — switch between environments
terraform workspace select — isolated state per tenant
kubectl config use-context — cluster switching

These tools serve millions of users across thousands of organizations. The multi-tenant problem is solved at the OS and credential level, not the protocol level.

Verdict: CLI wins. Battle-tested auth infrastructure already exists. MCP reinvents it with less maturity.

Round 3: Complex Workflows

The MCP claim: CLI falls apart for complex, multi-step workflows. MCP's structured protocol handles orchestration better.

The CLI response: What is more complex than ffmpeg?

ffmpeg -i input.mp4 -filter_complex \
  "[0:v]split=2[v1][v2]; \
   [v1]crop=iw/2:ih:0:0[left]; \
   [v2]crop=iw/2:ih:iw/2:0[right]; \
   [left][right]hstack" \
  -c:v libx264 -crf 23 output.mp4

If an AI agent can compose ffmpeg pipelines with filters, codecs, stream mapping, and complex filter graphs — one of the most notoriously complex CLIs ever built — then "CLI can't handle complex workflows" is dead on arrival.

Unix pipes and composition (|, &&, >, <()) have been orchestrating complex workflows since before most of us were born.

Verdict: CLI wins decisively. Complexity is CLI's home turf.

Round 4: Tool Discovery

The MCP claim: Agents can't discover unknown CLI tools. MCP's tools/list gives structured schema at runtime. CLI has no equivalent.

The CLI response: --help has been the universal discovery mechanism for decades. It worked for humans. It works for agents.

$ gh --help
Work seamlessly with GitHub from the command line.

USAGE
  gh <command> <subcommand> [flags]

CORE COMMANDS
  pr:       Manage pull requests
  issue:    Manage issues
  repo:     Manage repositories
  ...

Agent-friendly CLIs are now emerging that optimize --help output for token efficiency — compact descriptions, structured flag listings, minimal noise. The new generation of CLIs is built with agents as first-class users.

And here's the kicker: --help output is wildly inconsistent across tools, yes. But MCP schemas are also inconsistent — just consistently verbose. A bloated schema is not better than a concise --help.

Verdict: Roughly even, but CLI gets the edge on token cost. Discovery via --help is "good enough" and costs tokens only when needed, not upfront.

Round 5: Who Builds the Integration?

The MCP claim: Someone builds an MCP server once, publishes it, and any MCP-compatible agent can use it. It's a standard interface. Build once, use everywhere.

The CLI response: This argument contains its own refutation.

"Someone builds an MCP server" — yes, a human developer. That same developer could build a CLI in less time with less complexity. An MCP server is strictly more work: it's a CLI plus a JSON-RPC transport, schema definitions, capability negotiation, and a long-running server process.

And "any MCP-compatible agent" is actually a narrower audience than "any agent with shell access." Every agent on earth can shell out to a binary. Not every agent speaks MCP.

	CLI	MCP
Who can build it	Any developer	Developer who knows MCP spec
Who can use it	Any agent with shell access	Only MCP-compatible agents
Runtime requirement	Stateless binary	Long-running server process
Failure mode	Command fails, retry	Server crashes, everything dies

Verdict: CLI wins. Bash is the actual universal protocol. It has been since 1971.

Round 6: The Trust Boundary — MCP's Last Stand

The MCP claim: CLI requires the agent to have shell access. For customer-facing AI products, you would never give an agent bash on production infrastructure. One prompt injection and it's ; rm -rf /. MCP's value is process isolation — the agent talks JSON over a socket, it cannot escape the sandbox.

The CLI response: That's why sandboxing exists.

Restricted shells (rbash)
Container isolation (Docker, gVisor)
seccomp / AppArmor profiles
Custom sandbox layers

The MCP rebuttal: But look at what sandboxing actually is:

MCP:     Agent → JSON-RPC → Server → (allowed ops) → System
Sandbox: Agent → bash → Sandbox Policy → (allowed ops) → System

The topology is identical. Agent, permission boundary, system. A sandboxed shell with curated CLIs is topologically equivalent to an MCP server. You've built the same thing with different packaging.

The CLI counter: If they're topologically the same, use the simpler one.

Verdict: Draw — but it reveals something important. MCP isn't a protocol innovation. It's a pre-packaged sandbox+interface bundle. A convenience, not a necessity.

The Final Scoreboard

Claim	Winner
Token efficiency	CLI (10-32x cheaper)
Universal compatibility	CLI (bash > MCP adoption)
Builder effort	CLI (less work for same result)
Tool discovery	CLI (--help + agent-friendly CLIs)
Complex workflows	CLI (Unix composition is unmatched)
Multi-tenant auth	CLI (AWS, GCP, Docker prove it)
Safety / Trust boundaries	Draw (topologically equivalent)
Pre-packaged convenience	MCP (for teams that don't want to build)

Final score: CLI 6 — MCP 1 — Draw 1

So What Is MCP Actually?

After going through every argument, here's the honest conclusion:

MCP is a reasonable default for teams that don't want to think about tool integration. It's a convenience layer — a pre-built sandbox-plus-interface bundle — not a paradigm shift.

It's the difference between Rails and Rack. Some teams want the framework. Some teams want the library. Some teams just want to write a shell script and move on.

MCP's remaining value:

Pre-built, standardized bundle — for teams that want plug-and-play without building wrappers
The long tail of services without CLIs — your internal HR system probably doesn't have a CLI, but someone might write an MCP server for it (though they could also just... write a CLI)
Non-technical users — if the person connecting tools isn't a developer, a GUI-configurable MCP server is friendlier than bash

That's it. That's the list.

The Real Lesson

The industry positioned MCP as a revolution — "USB-C for AI agents." The reality is more mundane. MCP is a fine abstraction that got overhyped, over-adopted, and is now getting right-sized.

The 97 million monthly SDK downloads and 10,000+ servers aren't going away. MCP will continue to exist and serve its niche. But the smart money is on CLI-first architecture with MCP as an optional convenience layer, not the other way around.

The debate isn't really about protocols. It's about a deeper principle:

Don't build abstraction layers over things that already work.

Bash works. --help works. Unix pipes work. They've worked for 50 years. They'll work for 50 more. The burden of proof is on the new thing to justify its existence, and for the general case, MCP hasn't met that burden.

Build CLI-first. Reach for MCP when you genuinely need it. You'll know when that is — and it's less often than the hype suggests.

Based on a live debate conducted with an AI that started pro-MCP and got argued into conceding. The CLI side didn't need 55,000 tokens to make its case.