Skip to content

Did CLI Really Beat MCP? Deconstructing the Debate's Premises

Who this is for:

  • Engineers who want to understand the context behind the "CLI vs MCP" debate
  • Practitioners deciding on tool integration strategies for agent design
  • Anyone looking for a decision framework that holds up a year from now

Key Takeaways

  • The CLI superiority argument holds for shell-native development, but falls apart as a general theory
  • What actually lost isn't "the MCP protocol" — it's "the eager-loaded execution pattern that pre-loads massive tool surfaces"
  • To make sense of this debate, you need to think in three layers: execution, connectivity, and governance

What's Happening

In late February 2026, Eric Holmes published "MCP is dead. Long live the CLI." It generated significant traction on Hacker News and accelerated the CLI superiority narrative. Mario Zechner's benchmark (~52,000 tokens for MCP vs ~1,200 for CLI), Y Combinator's Garry Tan weighing in with criticism, and Perplexity's CTO signaling a move away from MCP all contributed to a growing sense that "the MCP era is over"123.

Meanwhile, the pro-MCP side produced systematic counterarguments. Charles Chen's "MCP is Dead; Long Live MCP!" drew an important distinction between stdio and HTTP transports, while Permit.io argued for MCP's value as enterprise infrastructure45.

Who's right? Before rushing to a conclusion, let's examine why the two sides are talking past each other.

The Roadmap: A Three-Layer Model

Let me present the analytical framework this article uses. This is not an official taxonomy — it's a lens for explaining the differences in implementation and design philosophy across vendors. The CLI vs MCP debate becomes much clearer when you separate tool integration into three layers.

Execution layer: Repo operations, builds, tests, file manipulation — the part where agents "do the work." Shell/CLI dominates here. Both Anthropic and OpenAI continue to strengthen native shell support, and model improvements translate directly into better performance in this layer.

Connectivity layer: External SaaS, remote data sources, internal knowledge bases — the part where agents "connect to the outside world." Many services here have no CLI at all, or only rudimentary ones. MCP, or a similar connector standard, is likely to persist in this space. OpenAI offers remote MCP as an extension surface across ChatGPT apps, deep research, company knowledge, and more6.

Governance layer: Authentication, authorization, auditing, distribution — the part where agents are "managed." Model intelligence alone can't substitute for this, and demand actually increases as agents become more capable. The MCP spec's authorization features and Claude Code's managed-mcp.json belong to this layer.

When you discuss "CLI vs MCP" without separating these layers, execution concerns bleed into governance concerns. The sections below evaluate both sides through this framework.

Why the Debate Doesn't Connect: MCP's Three Faces

Part of the confusion is that "MCP" simultaneously refers to at least three different things.

First, MCP as a protocol. An open protocol standardizing connections between LLMs and external services, donated to the Agentic AI Foundation (AAIF) under the Linux Foundation, and adopted by OpenAI, Google, Microsoft, and AWS7. The JSON-RPC-based specification itself.

Second, MCP as an execution pattern. The practice of pre-loading all tool definitions, letting the model select via direct tool calling, and feeding intermediate results back into context as-is.

Third, MCP as operational governance. MCP servers functioning as a control plane that centralizes authentication, authorization, auditing, and distribution.

Most CLI superiority arguments target the second meaning. Most MCP defense arguments assert the value of the first and third. Once you make this distinction, the two positions are largely compatible.

Examining the Case for CLI Superiority

Let me evaluate the main arguments for CLI superiority, grouped into efficiency, operations, and governance.

Efficiency: Token Consumption and Model Familiarity

Zechner's benchmark showed MCP's accessibility tree consuming ~52,000 tokens versus ~1,200 for CLI's selective queries. The GitHub MCP server burns ~55,000 tokens on 93 tool definitions, while an equivalent CLI tool's README fits in 225 tokens2. One reason for CLI's token efficiency is that model training data contains a massive volume of Bash command examples. Models already know how to use git, gh, jq, curl, and similar tools, reducing exploration cost to near zero.

When this holds: When using the direct tool calling pattern with eager-loaded tool definitions against mature, well-known CLIs, the efficiency gap is real.

Where it breaks down: These numbers reflect the problem with "a common eager-load operational pattern," not an inherent limitation of the MCP protocol. Anthropic's Tool Search Tool achieves an 85% reduction, and Programmatic Tool Calling delivers an average 37% reduction8. CLI's training data advantage in token efficiency may also diminish as the MCP ecosystem expands. As context windows grow and token costs decline, the weight this difference carries in decision-making may decrease as well.

Operations: Authentication and Process Management

Holmes criticized MCP for not leveraging existing authentication infrastructure (SSO, gh auth login, etc.) that CLI already uses, and for the instability of maintaining MCP server background processes1.

When this holds: On a personal dev machine where a single engineer runs a single agent, piggybacking on existing credentials is the simplest approach. For stdio-based local MCP servers, process management friction is real.

Where it breaks down: With HTTP-based remote MCP servers, the picture changes. Server operations are handled by infrastructure teams, and clients simply point to an HTTP endpoint — operational complexity shifts from client to server (it doesn't disappear, but the locus of responsibility moves). For authentication, remote MCP servers make it easier to design systems where users authenticate via OAuth/SSO without ever touching downstream API keys9. That said, CLI can achieve comparable designs with OAuth + short-lived tokens + revocation, so this is less a "CLI vs MCP" issue and more an authentication architecture design question.

Governance: Permission Granularity and the Wrapper Problem

In Claude Code, CLI allows command-level control (gh pr view is allowed, gh pr merge requires approval), while MCP tools can only be permitted at the tool-name level. Holmes also pointed out that "the GitHub MCP server is a reimplementation of the gh CLI, and adding the abstraction layer only increases cost and complicates debugging"1.

When this holds: As of March 2026 in Claude Code's implementation, shell-level control naturally provides finer granularity. For mature CLIs like GitHub, filesystem tools, and Docker, the wrapper criticism hits close to home.

Where it breaks down: On permission granularity, the MCP spec does include per-tool annotations (readOnlyHint, destructiveHint, etc.), providing raw material for more granular policy implementation in the future. However, the spec explicitly notes that these are hints and should not be the sole basis for decisions about untrusted servers. For now, shell control over mature CLIs offers finer granularity more naturally. On the wrapper problem, SaaS platforms without CLIs or with weak ones (Notion, Jira, Slack, etc., which expose REST APIs) have no "CLI to wrap" in the first place. In these cases, MCP serves as a viable connectivity surface for agents.

The Overlooked Dividing Line: stdio vs HTTP

The most critical gap in the CLI vs MCP debate is the failure to distinguish between MCP's transport modes. Chen's article addresses this systematically4.

MCP over stdio (local execution) runs the MCP server co-located with the agent on the same machine. In this mode, the criticism that CLI is simpler is largely valid. Chen himself acknowledges that "in stdio mode, MCP is unnecessary — CLI is better."

MCP over HTTP (remote execution) runs the MCP server as a centralized service that multiple clients connect to over HTTP. This mode reduces credential sprawl, makes it easier to centralize telemetry and operational responsibility, and supports designs where IT administrators distribute and control servers. In ephemeral execution environments like GitHub Actions, you simply point to an HTTP endpoint to leverage complex backends.

Most CLI superiority arguments compare CLI against MCP in stdio mode. The problems that HTTP-mode MCP solves exist in an entirely different dimension.

"Stronger Models Will Make MCP Unnecessary" — Really?

A key claim in a prominent Zenn article was that "MCP's design premise — that models can't understand CLIs — has been invalidated by model evolution"10. Let's examine this through the three-layer model.

At the execution layer, CLI/shell superiority is likely to grow. Stronger models mean better ability to read help pages and man pages, better error recovery, and better trial-and-error with multiple commands. The CLI camp's read is solid here.

At the governance layer, however, stronger models increase the need for governance. More capable agents can do more, which means the blast radius of mistakes grows too. Demand for identity, authorization, audit, and observability scales proportionally with agent capability.

At the connectivity layer, the value of standardization persists. Imagine a world where you can say "build me X" and it just happens. That agent needs to connect to dozens of services, authenticate, and execute operations. What's needed isn't "the ability to run Bash commands" — it's "a protocol for connecting to, authenticating with, and operating across many services in a standardized way."

In other words, model evolution is not zero-sum. At the execution layer, CLI covers more ground. At the connectivity and governance layers, MCP's center of gravity shifts from "model assistance" to "connectivity, governance, and reuse." The accurate framing isn't "stronger models make MCP unnecessary" — it's "the rationale for MCP changes."

What Actually Lost

To compress everything so far into a single sentence: what lost isn't MCP in general — it's the eager-loaded implementation pattern.

Specifically, what was refuted is one thing:

The eager-loaded execution pattern: pre-loading massive tool definitions, having the model select from all of them via direct tool calling, and feeding intermediate results back into context as-is.

This isn't unique to MCP. Even in non-MCP environments, any design that eager-loads a large tool surface is at a disadvantage. Both Anthropic (Tool Search, Programmatic Tool Calling) and OpenAI (tool_search) are moving toward deferred loading8.

Meanwhile, the following remain unrefuted:

MCP's value as a protocol specification (a standardized connectivity surface). The operational value of HTTP-based remote MCP servers (a structure that makes it easier to centralize authentication design, telemetry, and distribution). Primitives beyond Tools — Resources, Prompts, Sampling, and Elicitation. The ecosystem's accumulated adoption (AAIF governance, adoption by OpenAI, Google, Microsoft, and AWS)567.

Decision Map by Condition

Here's how decisions branch along the three-layer model. As a concrete example, imagine a dev team delegating tasks to an agent: repo editing, test execution, and PR creation go CLI-first. Cross-searching Notion, Jira, and internal knowledge bases goes MCP-first. When auditing is scoped to service connections and IT needs to govern which services agents can access, route through managed/remote MCP.

Conditions Favoring CLI-First

  • The agent's execution responsibility is local (everything completes on the local machine)
  • Mature CLIs exist for the target operations (gh, git, docker, kubectl, jq, etc.)
  • Authentication can be handled via per-environment credentials
  • Auditing focuses on "which commands were executed"
  • A single client uses the integration exclusively

Conditions Favoring MCP-First

  • Execution responsibility needs to be centralized (IT-governed)
  • Targets are remote SaaS/HTTP APIs with no CLI or weak CLIs
  • Authentication should be centrally managed, without distributing keys to individual agents
  • Auditing focuses on "which service connections were used and how"
  • The same integration needs to be reused across multiple clients

Hybrid (the Default for Most Teams)

  • Execution layer (repo operations, builds, tests): CLI
  • Connectivity layer (external SaaS integration, internal knowledge access): MCP
  • Route only the connections requiring governance through MCP servers

Conclusion

"CLI beat MCP" holds true at the execution layer for shell-native development. But generalizing that to the death of the MCP protocol runs into counterevidence at the connectivity and governance layers.

What's actually happening, more precisely:

  • Eager-loaded direct tool calling lost its edge in shell-native development workflows
  • MCP's center of gravity is shifting from "model assistance" to "connectivity, governance, and reuse"
  • As models grow stronger, CLI expands at the execution layer while MCP becomes more necessary at the governance layer

The practical takeaway compresses to one line:

Don't add MCP where CLI suffices. But don't hesitate to use MCP for integration surfaces it handles cleanly.

Appendix: The Shelf Life of This Debate

The "token efficiency" and "benchmark numbers" discussed in this article are heavily dependent on March 2026 constraints. As context windows expand, token costs decline, and Tool Search and Programmatic Tool Calling mature, the case for choosing CLI on token efficiency grounds will weaken.

What's likely to endure a year from now is the division of labor across execution, connectivity, and governance layers. The design decision of which tool to place at which layer holds up even as token pricing changes.

For a discussion of MCP vs Skills as a separate axis, see the related articles below. This article adds the CLI dimension and re-examines the debate as a whole.

  1. Eric Holmes "MCP is dead. Long live the CLI" (2026/2) https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html ↩↩↩

  2. Mario Zechner "MCP vs CLI: Benchmarking Tools for Coding Agents" (2025/8) https://mariozechner.at/posts/2025-08-15-mcp-vs-cli/ ↩↩

  3. Perplexity CTOのMCP離れについては Versalence AI "Long Live MCP" (2026/3) を参照 https://blogs.versalence.ai/mcp-model-context-protocol-evolution-2026 ↩

  4. Charles Chen "MCP is Dead; Long Live MCP!" (2026/3) https://itnext.io/mcp-is-dead-long-live-mcp-a67bd74a6576 ↩↩

  5. Permit.io "MCP Isn't Dead. It's Becoming Enterprise Infrastructure." (2026/3) https://permit.substack.com/p/mcp-isnt-dead-its-becoming-enterprise ↩↩

  6. OpenAI Developers "Building MCP servers for ChatGPT Apps and API integrations" https://developers.openai.com/api/docs/mcp/ ↩↩

  7. Anthropic "Donating the Model Context Protocol and establishing the Agentic AI Foundation" (2025/12) https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation ↩↩

  8. Anthropic "Advanced tool use" (2026) https://www.anthropic.com/engineering/advanced-tool-use ↩↩

  9. DEV Community "Missing from the MCP debate: Who holds the keys when 50 agents access 50 APIs?" (2026/3) https://dev.to/aws/missing-from-the-mcp-debate-who-holds-the-keys-when-50-agents-access-50-apis-mb3 ↩

  10. ひらりー「MCPはなぜCLIに負けたのか」(2026/3) https://zenn.dev/hiraly/articles/3409b886607274 ↩