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

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 — 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.

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.

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 covers the mechanics.

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.

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.

The Numbers Behind "Dead"

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

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.

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.

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.

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.

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 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.