# Is MCP Dead? What the CLI Backlash Gets Right — and Wrong

> A post called "MCP is dead. Long live the CLI" hit the top of Hacker News and the argument still has not settled. Three of its five complaints are fair. Two were fixed by the 2026-07-28 spec. Here is how to tell which side your project is on.

**Source:** https://mcpplaygroundonline.com/blog/is-mcp-dead-cli-debate  
**Author:** Nikhil Tiwari  
**Published:** 2026-09-07  
**Updated:** 2026-09-07  
**Category:** Comparison  
**Reading time:** 13 min read

---

📖 TL;DR

-   The backlash started with Eric Holmes' post **"MCP is dead. Long live the CLI"**, which hit the top of Hacker News with 400+ points.
-   His five complaints: **context cost, debuggability, composability, auth friction, operational overhead**. Three still land. Two were addressed in the **2026-07-28** spec.
-   Thoughtworks put **naive API-to-MCP conversion** in the Hold ring of their Technology Radar. That is the real target — thin REST wrappers, not the protocol.
-   **CLI wins** when three things are all true: the agent has a shell, a good CLI already exists, and the user is a developer on their own machine.
-   **MCP wins** the moment any one of those is false — remote users, non-shell runtimes, enterprise audit, or more than one client.
-   The ecosystem is not shrinking. PulseMCP listed **22,311 servers** in July 2026, and Tier 1 SDKs are near **half a billion downloads a month**.

Table of Contents

1.  [Where the Argument Came From](#where-it-came-from)
2.  [The Five Complaints, Scored](#five-complaints)
3.  [What the 2026-07-28 Spec Fixed](#what-changed)
4.  [Where the CLI Genuinely Wins](#cli-wins)
5.  [Four Places a CLI Cannot Go](#cli-cannot)
6.  [The Numbers Behind "Dead"](#numbers)
7.  [Which One Should You Ship?](#decision)
8.  [Does Your Server Deserve to Exist?](#deserves)
9.  [FAQ](#faq)

Someone asks me **"is MCP dead"** roughly once a week now. Usually right after they read a thread telling them to delete their servers.

The short answer: no. The longer answer is more useful, because **the critics are right about a specific failure mode** that a lot of teams shipped in 2025.

I run a tool that connects to other people's MCP servers all day. I see the good ones and the ones that should have been a shell script.

If the protocol itself is new to you, start with my [guide to the Model Context Protocol](/blog/what-is-model-context-protocol) — this post assumes you already know what a tool call is.

This post walks the actual argument, scores each complaint honestly, and gives you a table for deciding which layer your next integration belongs on.

I am not going to defend the protocol on principle. Some of the servers I connect to genuinely should not exist.

## Where the "MCP Is Dead" Argument Came From

On 28 February 2026, Eric Holmes published _"MCP is dead. Long live the CLI."_ It went straight to the top of Hacker News.

His thesis was not that agents should stop using tools. **It was that LLMs are already excellent at using the command line.**

Models know `git`. They know `kubectl`, `docker`, `aws`, `jq`. That knowledge came free with pretraining.

So when you wrap an existing CLI in an MCP server, he argues, you pay protocol cost to re-teach the model something it already knew.

The thread hit 400+ points and nearly 300 comments. Pieter Levels called MCP "just as useless of an idea as llms.txt."

Then Thoughtworks put **naive API-to-MCP conversion** in the Hold ring of their Technology Radar. That is the sharpest version of the critique.

⚠️ Read the Hold ring carefully

Thoughtworks did not put _MCP_ in Hold. They put _naive API-to-MCP conversion_ in Hold — auto-generating one tool per REST endpoint and calling it an integration. That is a design failure, not a protocol failure.

## The Five Complaints, Scored Honestly

Holmes made five distinct arguments. They do not all age the same way, so I scored each one against the current spec.

Complaint

Still fair in Sept 2026?

Why

**Context cost**

**Yes**

Most clients still load every tool schema up front. Progressive discovery is roadmap, not spec.

**Composability**

**Yes**

You cannot pipe a tool result into `jq`. Filtering has to be built into the server.

**Debuggability**

**Partly**

Stateless requests are now replayable with `curl`. Tooling closed most of this gap.

**Auth friction**

**Largely fixed**

CIMD replaced Dynamic Client Registration as the preferred path, plus issuer validation.

**Operational overhead**

**Largely fixed**

The stateless core removed sessions. A server is now a normal HTTP workload.

### Context cost is the one that still hurts

This is the strongest complaint and nobody has solved it yet. **Connect eight servers with fifteen tools each and your context is gone before the first message.**

Clients load names, descriptions and full input schemas into the system prompt at session start. Whether the agent uses them or not.

The August roadmap lists _progressive tool discovery_ as a priority. It is not in a shipped spec revision yet.

Until it is, the fix is discipline. Fewer tools, tighter descriptions, and measuring what you actually send.

### Composability is a real architectural loss

A CLI returns text you can pipe. `terraform state list | grep aws_instance` costs you nothing in context.

An MCP tool returns a result that lands whole in the conversation. **Either you dump 40KB of Terraform state into the window, or you build filtering into the server.**

Holmes is right that this is a genuine tradeoff. Structured results buy you schema safety and cost you Unix pipes.

## What the 2026-07-28 Spec Actually Fixed

Two of the five complaints were about operations, and the July 2026 revision went straight at them.

The **stateless protocol core** removed the `initialize` handshake and the `Mcp-Session-Id` header entirely.

Each request now carries its own protocol version, client identity and capabilities in `_meta`. No shared state between requests.

That kills the "MCP servers are stateful things you have to babysit" argument. **A 2026-spec server is a stateless HTTP workload behind any load balancer.**

Auth got the same treatment. RFC 9207 issuer validation landed as SEP-2468, issuer-bound client credentials as SEP-2352.

Dynamic Client Registration was formally deprecated in favour of _Client ID Metadata Documents_. Fewer registration round trips, less token churn.

There is also **Multi Round-Trip Requests** (SEP-2322), which replaced server-initiated requests. A server returns `resultType: "input_required"` and the client retries with answers.

That is how elicitation and mid-call confirmation now work without a persistent stream. If you are still on the old revision, my [stateless migration guide](/blog/migrate-mcp-server-2026-07-28-stateless) covers the mechanics.

**Worth noting:** a lot of the "MCP is bloated" takes are describing the 2025-03-26 or 2025-11-25 revision. The complaints about sessions, sticky routing and SSE streams are accurate — for a spec that is no longer current.

## Where the CLI Genuinely Wins

I want to be blunt here, because pretending otherwise is how you end up shipping a server nobody uses.

**If a good CLI already exists and your agent has a shell, use the CLI.** Wrapping `gh` in an MCP server is usually a waste of everyone's time.

Three conditions have to hold for the CLI to be the better answer:

1.  **The agent has shell access.** Claude Code, Codex and Cursor do. A web chat app does not.
2.  **A mature CLI already exists** with stable flags and machine-readable output.
3.  **The user is a developer on their own machine**, already authenticated through their normal profile.

When all three are true the CLI wins on every axis. Zero context cost, real pipes, existing credentials, trivial debugging.

The model already knows the tool. You add nothing by putting JSON-RPC in front of it.

## Four Places a CLI Cannot Go

Now the other direction. **Break any one of those three conditions and the CLI stops being an option at all.**

### 1\. The client has no shell

Claude's web and desktop apps, ChatGPT, and every consumer agent connect over HTTP. There is no terminal to run `kubectl` in.

This is the case Holmes' post does not cover, and it is most of the market. **Remote MCP exists precisely because the caller is not sitting at a shell.**

### 2\. Enterprise auth and audit

Giving an agent your AWS profile means giving it everything your profile can do. There is no scope in between.

MCP puts a server between the agent and the system. You get per-tool scopes, an audit trail, and a place to deny a call.

As one rebuttal put it: not giving an AI agent unrestricted root on enterprise systems is not obstruction, it is a CISO doing their job.

### 3\. More than one client needs the same tools

A CLI wrapper is per-agent glue. **An MCP server is written once and consumed by every client that speaks the protocol.**

This is the same argument that beat per-provider function calling. I unpacked it in [MCP vs function calling vs REST APIs](/blog/mcp-vs-function-calling-vs-api-comparison).

### 4\. There is no CLI

Your internal ticketing system does not ship a CLI. Neither does your warehouse, your feature flag service, or that 2014 SOAP endpoint.

"Just write a good CLI first" is real advice, but it is a second project. **Sometimes the MCP server is the cheapest honest interface you can build.**

Not sure whether your server earns its context budget?

Connect it in the browser, see every tool schema a model actually receives, and count the tokens before you ship.

[Test any MCP server free →](https://mcpplaygroundonline.com/mcp-test-server) [Count your tool-schema tokens](https://mcpplaygroundonline.com/mcp-token-counter)

## The Numbers Behind "Dead"

Declarations of death should survive contact with a download counter. These do not.

22,311

Servers listed on PulseMCP as of July 2026

~500M

Monthly downloads across Tier 1 SDKs

1B+

All-time downloads, TypeScript and Python SDKs each

Dec 2025

Donated to the Linux Foundation's Agentic AI Foundation

Governance is the part people skip. MCP is no longer an Anthropic project — **it sits under the Agentic AI Foundation with Anthropic, OpenAI, Google, Microsoft and AWS at the table.**

Protocols with that shape of backing do not die from a Hacker News thread. They get boring, which is the goal.

## Which One Should You Ship?

Here is the table I actually use. Find your row, ship that thing, stop reading threads.

Your situation

Ship this

Coding agent, mature CLI exists, dev's own machine

**CLI** — plus a Skill if the agent needs process knowledge

Web or desktop chat client, no shell

**Remote MCP server**, Streamable HTTP, 2026-07-28

Internal system, needs scoped access and audit

**MCP server** with OAuth and per-tool scopes

Three or more clients need the same tools

**MCP server** — write once, reuse everywhere

One app, one provider, you own every tool

**Plain function calling** — MCP is pure overhead here

Agent knows the tools, just not your process

**Agent Skill** — no server needed at all

Notice that two of six rows say "not MCP". **That is the honest read of the backlash** — not that the protocol failed, but that it got applied to rows it never fit.

If the Skills row is new to you, I compared all four layers in [Agent Skills vs MCP vs function calling vs A2A](/blog/agent-skills-vs-mcp).

## Does Your MCP Server Deserve to Exist?

Five questions. If you answer no to the first three, delete the server and write a CLI.

1.  **Can a client without a shell reach this?** If every consumer has a terminal, you may not need a server.
2.  **Does it enforce a scope the raw credentials do not?** A pass-through wrapper adds risk, not safety.
3.  **Will more than one client use it?** One consumer means you built glue, not an integration.
4.  **Are the tools task-shaped, not endpoint-shaped?** One tool per REST route is the Hold-ring anti-pattern.
5.  **Do you know its token cost?** If you cannot state the schema size, you cannot defend it.

Question four is where most servers fail. **Forty CRUD tools is a generated API client, not an agent interface.**

Collapse them into the handful of tasks a user actually asks for. Tool descriptions matter more than tool count — see [why tool description quality decides tool selection](/blog/mcp-tool-description-quality).

Question five is measurable in about a minute. Connect the server, look at the schemas the model receives, and count them.

Then run the same prompt against a real model and watch which tool it picks. That is the only test that settles the argument for your server.

Settle the argument with evidence, not threads

Run your server against a real model, see every tool call, and check it for tool poisoning and over-broad scopes while you are there.

[Run it in MCP Agent Studio →](https://mcpplaygroundonline.com/mcp-agent-studio) [Scan your MCP server →](https://mcpplaygroundonline.com/mcp-security-scanner)

## The Verdict

MCP is not dead. **It got sorted.**

The use cases that never needed it are moving to CLIs and Skills, which is healthy. The use cases that genuinely need a protocol are quietly shipping one.

What died is the 2025 reflex of wrapping every API in a server because the tooling made it easy.

If your server survives the five questions above, ignore the thread. If it does not, the thread did you a favour.

And if it survives, make it findable. Publishing a [.well-known Server Card](/blog/mcp-server-cards-well-known-discovery) is the cheapest way to get listed by registries and client install dialogs.

## FAQ

**Is MCP dead in 2026?+**

No. PulseMCP listed 22,311 servers in July 2026, Tier 1 SDKs are near half a billion downloads a month, and the protocol has been under the Linux Foundation's Agentic AI Foundation since December 2025 with Anthropic, OpenAI, Google, Microsoft and AWS involved. What faded is the practice of wrapping every REST API in an MCP server.

**Should I use a CLI instead of an MCP server?+**

Use the CLI when all three of these hold: the agent has shell access, a mature CLI already exists, and the user is a developer on their own machine with existing credentials. Break any one of those and you need MCP — a web client has no shell, enterprise access needs scoped auth, and internal systems often have no CLI at all.

**What did Thoughtworks actually put in the Hold ring?+**

Naive API-to-MCP conversion, not MCP itself. The anti-pattern is auto-generating one tool per REST endpoint, which produces dozens of CRUD tools that burn context and confuse tool selection. The fix is designing task-shaped tools that match what a user asks for, rather than mirroring your API surface.

**Did the 2026-07-28 spec answer the MCP criticism?+**

Partly. The stateless core removed the initialize handshake and Mcp-Session-Id header, so a server is now a plain HTTP workload behind any load balancer, which answers the operational overhead complaint. Authorization hardening with RFC 9207 issuer validation and Client ID Metadata Documents answered the auth friction complaint. Context cost and composability were not addressed and remain valid criticisms.

**Why do MCP servers use so much context?+**

Most clients load every connected server's full tool list into the system prompt at session start, including names, descriptions and complete JSON input schemas, whether the agent uses them or not. Eight servers with fifteen tools each can consume a significant slice of the window before the first user message. Progressive tool discovery is listed as a priority in the August 2026 roadmap but is not in a shipped spec revision yet.

**Can I pipe MCP tool output like CLI output?+**

No, and this is the strongest surviving criticism. A CLI lets you chain through grep or jq before anything reaches the model, at zero context cost. An MCP tool result lands whole in the conversation, so filtering and pagination have to be built into the server as tool parameters. Structured, schema-validated results are what you buy in exchange.

## Frequently asked questions

### Is MCP dead in 2026?

No. PulseMCP listed 22,311 servers in July 2026, Tier 1 SDKs are near half a billion downloads a month, and the protocol has been under the Linux Foundation Agentic AI Foundation since December 2025 with Anthropic, OpenAI, Google, Microsoft and AWS involved. What faded is the practice of wrapping every REST API in an MCP server.

### Should I use a CLI instead of an MCP server?

Use the CLI when all three of these hold: the agent has shell access, a mature CLI already exists, and the user is a developer on their own machine with existing credentials. Break any one of those and you need MCP, because a web client has no shell, enterprise access needs scoped auth, and internal systems often have no CLI at all.

### What did Thoughtworks actually put in the Hold ring?

Naive API-to-MCP conversion, not MCP itself. The anti-pattern is auto-generating one tool per REST endpoint, which produces dozens of CRUD tools that burn context and confuse tool selection. The fix is designing task-shaped tools that match what a user asks for rather than mirroring your API surface.

### Did the 2026-07-28 spec answer the MCP criticism?

Partly. The stateless core removed the initialize handshake and the Mcp-Session-Id header, so a server is now a plain HTTP workload behind any load balancer, which answers the operational overhead complaint. Authorization hardening with RFC 9207 issuer validation and Client ID Metadata Documents answered the auth friction complaint. Context cost and composability were not addressed and remain valid criticisms.

### Why do MCP servers use so much context?

Most clients load every connected server full tool list into the system prompt at session start, including names, descriptions and complete JSON input schemas, whether the agent uses them or not. Eight servers with fifteen tools each can consume a significant slice of the window before the first user message. Progressive tool discovery is a priority in the August 2026 roadmap but is not in a shipped spec revision yet.

### Can I pipe MCP tool output like CLI output?

No, and this is the strongest surviving criticism. A CLI lets you chain through grep or jq before anything reaches the model, at zero context cost. An MCP tool result lands whole in the conversation, so filtering and pagination have to be built into the server as tool parameters. Structured, schema-validated results are what you buy in exchange.


---

_Canonical page: https://mcpplaygroundonline.com/blog/is-mcp-dead-cli-debate — MCP Playground (mcpplaygroundonline.com), the free browser-based tool for testing MCP servers and building AI agents._