MCP isn't dead
Six easy pieces on why protocols win, and how to think about the MCP debate — and every tech debate that comes after it.
The internet says MCP is dead.
MCP is the Model Context Protocol: the standardised way an AI model finds out what external tools exist and talks to them. In late February 2026, a bunch of smart developers wrote blog posts about how AI agents don’t need it because they can just use the command line. Eric Holmes published his on 28 February 2026, arguing that large language models are already good at figuring things out, and that giving them a command-line interface and some docs is sufficient — ship a good API, ship a good CLI, and the agents will figure it out. Peter Steinberger, the creator of OpenClaw, had earlier declared that MCPs were a mistake and bash is better. Hacker News loved it. Twitter amplified it. Garry Tan agreed. The echo chamber echoed.
I’m not going to tell you they’re wrong. I’m going to teach you something more useful: how to figure out the answer yourself. Because next month it’ll be something else that’s “dead,” and the month after that something else, and you can’t afford to update your entire worldview every time a blog post goes viral.
This essay has six pieces. Each one builds on the last. By the end, you’ll have a way of thinking that works not just for MCP, but for every technology debate you’ll encounter in your career.
Let’s go.
Piece 1: Start with the problem, not the solution
Here’s the mistake almost everyone in this debate is making: they’re arguing about solutions (MCP vs CLI) without first agreeing on what problem they’re solving.
This is like two people arguing about whether you need a car or a bicycle without first asking: “Where are you going?”
So let’s ask the right question first: what actually needs to happen for an AI model to use an external tool?
Think about it. A large language model, by itself, can only do one thing — predict the next word. That’s it. It can’t check the weather. It can’t query a database. It can’t send a Slack message. To do any of that, it needs to talk to software that lives outside itself.
For that to work, five things must happen. Not optionally. Not “it would be nice.” These are non-negotiable requirements — like how a phone call requires both phones to be turned on, connected to a network, and speaking the same language.
The five requirements:
1. Finding — The AI must know the tool exists. You can’t use what you don’t know about.
2. Understanding — The AI must know how the tool works. What inputs does it need? What does it give back?
3. Permission — The system must verify: are you allowed to use this tool? With whose credentials? With what limits?
4. Calling — The AI must actually invoke the tool and get a result back.
5. Fitting — The result must fit into the AI’s working memory (its “context window”) without overwhelming everything else it’s thinking about.
These five aren’t my opinion. They’re logical necessities. Any system that connects AI to tools — MCP, CLI, raw API calls, carrier pigeons — must solve all five. If it fails on even one, the whole thing breaks.
I want you to memorise these five, because they’re your filter for every argument you’ll hear. Whenever someone says “X is better than Y for AI tool integration,” your first question should be: “Which of the five does it solve, and which does it break?”
Piece 2: The honest scorecard
Now that we have the five requirements, let’s honestly score both sides.
How CLI does it
The CLI argument goes like this: LLMs have already been trained on millions of command-line examples. They know git. They know docker. They know kubectl. Just give them a terminal and they’ll figure it out. No new protocol needed.
Let’s check this against our five requirements:
Finding — For famous tools like git and docker? Great. The LLM knows them from training. For your company’s internal API? For a niche SaaS tool? For anything built after the training cutoff? It has no idea these exist. Score: works sometimes.
Understanding — CLI outputs are just text. There’s no guarantee of format. The output of git log can look completely different depending on your config. When things change between versions, the LLM has no contract to rely on — it’s guessing. Score: fragile.
Permission — CLI inherits whatever credentials are on your machine. If you’ve already run aws sso login, great. But what if you’re building a product where someone else’s users need to access their company’s tools through your AI? You can’t just hand them your SSH keys. Score: works for you, breaks for your users.
Calling — Running a shell command is simple and reliable. Score: excellent.
Fitting — CLI output is often massive and unstructured. A full Terraform plan, a verbose API response, a long git log — all of it dumps straight into the context window as raw text. Score: wasteful.
How MCP does it
Finding — MCP servers declare what tools they offer. There’s a typed catalogue. The new Tool Search feature lets the AI find relevant tools without loading everything. Score: better architecture, still maturing.
Understanding — Every tool comes with a typed schema — defined inputs, defined outputs. When something changes, there’s a contract to check against. Score: better architecture, but those schemas currently waste a lot of tokens (~55,000 for GitHub’s 43 tools).
Permission — MCP is building OAuth 2.1 support, scoped permissions, token revocation. It’s designed for the case where your product’s users need to access their own tools safely. Score: right architecture, painful implementation today.
Calling — Structured RPC calls with typed responses. Works. A bit more overhead than a shell command. Score: good.
Fitting — Programmatic Tool Calling (PTC) lets the AI write code that processes tool results in a sandbox, only sending the final answer back to the context window. This is a major improvement. Score: actively getting better.
What the scorecard tells us
CLI wins on simplicity for a single developer using well-known tools. MCP wins on architecture for everything else. And MCP’s weaknesses are all in the current implementation, not in the design.
This distinction matters enormously. And to understand why, we need Piece 3.
Piece 3: The most important distinction in engineering
Here’s an idea that will serve you for your entire career. It comes from the philosophy of science, but don’t let that scare you — the idea itself is simple.
Every technology has two parts: the core idea and the current implementation.
The core idea is the fundamental bet. The reason the thing exists. The problem it’s trying to solve.
The current implementation is all the messy details: the bugs, the awkward APIs, the flaky auth, the things that make you curse at your screen at 2 AM.
The single biggest mistake you can make as an engineer is killing a good idea because of a bad implementation.
Let me make this concrete with a story you already know.
In 2015, Apple released a MacBook with exactly one USB-C port. One. If you wanted to charge your laptop and plug in a monitor and connect a USB drive, you needed a pile of dongles. The experience was miserable. People mocked it relentlessly.
Was USB-C a bad idea? Obviously not. Today, every phone, laptop, and tablet uses it. The EU mandated it. The core idea — one universal connector for data, video, and power — was brilliant. The early implementation — one port, confusing cables, inconsistent capabilities — was terrible.
The people who said “USB-C is a disaster” in 2016 were right about the experience. They were wrong about the trajectory. They confused implementation pain with design failure.
Now apply this to MCP.
When someone says “MCP servers are flaky and crash,” they’re pointing at the implementation.
When someone says “auth is painful and breaks constantly,” they’re pointing at the implementation.
When someone says “schema injection wastes 55,000 tokens,” they’re pointing at the implementation.
All of these are real problems. None of them mean the core idea is wrong.
The core idea of MCP is: connecting M AI models to N tools requires a shared protocol, because building custom integrations for every model-tool pair doesn’t scale.
Attack that and you have a real argument. Attack the flaky servers and you have a bug report.
How to use this in practice
Whenever you encounter a “Technology X is dead” take, ask yourself:
“Is this person attacking the core idea or the current implementation?”
If they’re attacking the implementation, the right response isn’t “abandon the technology.” It’s “fix the implementation.” Because bad implementations get better. Bad ideas don’t.
This isn’t just philosophy. It’s literally how every major technology you use today survived its early critics: USB-C survived the dongle era. Kubernetes survived being “too complex” compared to Docker Swarm. REST survived being called “too simple” compared to SOAP. The core ideas were right. The implementations matured.
Piece 4: The counting argument
There’s a mathematical argument at the centre of this debate that’s so simple most people miss it. But once you see it, you can’t unsee it.
Imagine you have 5 AI models (Claude, GPT, Gemini, Llama, Mistral) and 10 tools (GitHub, Slack, Gmail, Jira, your database, your CRM, etc.).
Without a shared protocol: each model needs its own custom connector for each tool. That’s 5 × 10 = 50 custom integrations. Each one has its own auth flow, its own data format, its own quirks. When a tool updates its API, you update 5 connectors. When a new model comes out, you build 10 connectors.
With a shared protocol: each model implements the protocol once. Each tool implements the protocol once. That’s 5 + 10 = 15 implementations. When a tool updates, it updates 1 thing. When a new model arrives, it implements 1 thing.
50 vs 15. And that’s with tiny numbers. In reality, M (models) is growing to dozens and N (tools) is growing to thousands. The gap between M × N and M + N becomes enormous.
This is not a new insight. It’s the exact same math that drove the creation of:
- USB (one port instead of separate ports for printers, mice, keyboards, and game controllers)
- HTTP (one protocol for all web communication instead of proprietary protocols per service)
- TCP/IP (one network protocol instead of custom networking for each application)
- OpenAPI (one API description format instead of custom documentation per API)
Every time M × N gets too expensive, a protocol emerges to convert it to M + N. Every time. Without exception. This is not a trend or a fashion. It’s a mathematical inevitability.
So the question was never “do we need a protocol for AI-tool integration?” We do. The math demands it.
The real question is: “Is MCP a good enough candidate to become that protocol?”
Piece 5: How to tell if something is winning or dying
Now here’s where it gets interesting. How do you actually tell whether a technology is on its way up or its way out? You can’t just look at adoption numbers (MySpace had great numbers right before it collapsed). You can’t just look at corporate backing (Google kills projects all the time).
There’s a better test, and it has three parts:
Test 1: Is it solving new problems or just defending old claims?
A healthy technology keeps unlocking capabilities that weren’t possible before. A dying technology only makes excuses for why its existing approach is “good enough.”
MCP’s trajectory: Anthropic shipped Programmatic Tool Calling, which lets AI agents orchestrate dozens of tool calls through code while keeping the context window clean. They shipped Tool Search, which lets agents find relevant tools without loading all schemas upfront. These are new capabilities that solve real problems, not patches for old ones.
CLI’s trajectory: the CLI argument has stayed the same since January 2026. “Bash is better. LLMs already know CLI tools.” No new capabilities. No novel solutions. It’s a static position.
Test 2: Are the modifications fixing the right layer?
When MCP’s critics point out context bloat, Anthropic doesn’t redesign the entire protocol. They add Tool Search (a schema discovery mechanism) and PTC (a context management mechanism). The core protocol stays the same. The fixes target specific problems at specific layers.
This is like how USB-C added better cables and clearer labelling without redesigning the port itself. Fix the accessories. Keep the connector.
A bad sign would be if every fix required changing the fundamental design. That would mean the design was wrong. MCP’s fixes all work within the existing architecture, which means the architecture is sound.
Test 3: Is it being adopted by organisations that lose money if it fails?
Anyone can write a blog post. The real signal is who’s building production systems on top of it.
In December 2025, Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation. The co-founders: OpenAI, Block (Square, Cash App). Platinum members: AWS, Google, Microsoft, Cloudflare, Bloomberg.
These are competitors. They fight each other for market share every day. They agreed to co-govern this protocol because they all need it to work. That’s not marketing. That’s infrastructure investment.
Think about it: when was the last time OpenAI, Google, Microsoft, and Anthropic agreed on anything? They agreed on MCP.
Applying the three tests
MCP passes all three. CLI passes zero — it’s not getting better, it’s not evolving, and no one is investing in it as infrastructure.
This doesn’t mean CLI is useless. It means CLI is a tool, not a platform. It’s great at what it does. It’s not going to become the foundation for AI-tool integration at scale.
Piece 6: The question behind the question
Now for the deepest piece. There’s a question lurking behind the entire MCP debate that most people haven’t noticed:
“If AI gets smart enough to write code, does it still need interfaces?”
This is the existential version of the argument. If Claude can write Python to call any API, why does it need MCP? Why does it need anything?
This is a seductive argument. It’s also wrong. Here’s why.
Intelligence doesn’t solve coordination problems.
Imagine the smartest person in the world. Genius-level IQ. Can solve any problem. Now drop them in a country where they don’t speak the language, don’t have a passport, and don’t have any local currency.
Can they figure things out eventually? Probably. But a translation app, a valid passport, and a working credit card would make them 100x more productive. Not because they’re not smart enough — because intelligence isn’t the bottleneck. Access is.
A protocol isn’t a crutch for dumb AI. It’s infrastructure that makes smart AI productive. The smarter the AI gets, the more value it extracts from having standardised access to thousands of tools, because it can compose them in increasingly sophisticated ways.
Think about it from the other direction: humans are pretty smart. We can figure out almost any tool. But do we type raw HTTP requests to check our email? Do we write custom socket code to browse the web? No. We use protocols (SMTP, HTTP) that give us standardised access. Not because we’re not smart enough — because protocols make smart agents faster.
Programmatic Tool Calling proves this point, not the opposite.
PTC is Anthropic’s feature that lets Claude write code inside a sandbox to orchestrate tool calls. The LLM writes a Python script, the script calls tools in a loop, processes the data, and only the final result enters the context window.
Critics say: “See? The LLM can write code! It doesn’t need MCP!”
But look at what PTC actually does. Claude writes code that calls MCP tools programmatically. PTC is an orchestration layer that sits on top of the protocol layer. It’s like saying “this engine is so good, we don’t need a road.” You need both. The engine is how you move. The road is what you move on.
Here’s the three-layer picture:
What you're building for | What solves it
------------------------------------------|---------------------------
"What tools exist? How do I connect | MCP
to them?" | (the road)
|
"How do I call 20 tools efficiently | PTC / code execution
without blowing up my context window?" | (the engine)
|
"Who's allowed to do what? What's the | Auth + governance
audit trail?" | (the traffic rules)CLI is a great engine for certain roads (local tools, well-known commands). MCP is the road system itself. PTC is a turbocharger for whatever engine you’re using. They’re not competing. They’re different layers.
The products that are actually winning in the market — Claude Code, Cursor, Microsoft Copilot — already use all three. They didn’t pick sides. They picked the right tool for each layer.
Now you have the toolkit
Let me give you the six ideas as a compact checklist you can carry with you:
1. Start with the problem. Before arguing about solutions, define what the problem actually requires. Break it into non-negotiable pieces.
2. Score honestly. Test every proposed solution against those requirements. Where does it shine? Where does it break? For whom?
3. Separate idea from implementation. Is the critic attacking the core design or the current bugs? Bad implementations get better. Bad ideas don’t.
4. Do the math. If the problem has M × N structure, a protocol will emerge. This has happened every single time in the history of computing. It’s not a trend. It’s arithmetic.
5. Watch what’s growing. Is the technology producing new capabilities? Is it attracting real investment from organisations that lose money if it fails? Or is it just defending its existing position?
6. Intelligence doesn’t replace infrastructure. Smart AI needs good roads, not fewer roads. Protocols make smart agents faster, not dumber.
For the curious: the philosophy underneath
Everything I just laid out has a name in the philosophy of science. You don’t need to know the names to use the ideas — that’s the whole point of this essay. But if you want to go deeper, here’s the map:
Piece 1 (start with the problem) is called first-principles decomposition. It goes back to Aristotle: “The person who understands the nature of the whole understands the things of which the whole is made.” Feynman practised this obsessively. So did every great engineer.
Piece 3 (separate idea from implementation) comes from Imre Lakatos’s Methodology of Scientific Research Programmes (1970). Lakatos observed that every scientific theory has a “hard core” (the central idea) and a “protective belt” (the auxiliary hypotheses and details). Smart scientists modify the protective belt when anomalies arise. They only abandon the hard core when a better theory replaces it. The MCP critics are attacking the protective belt and claiming the hard core is dead. Lakatos would call this “naive falsificationism.”
Piece 4 (the counting argument) is deductive reasoning from mathematical premises. If you accept that M and N are growing, M × N > M + N follows necessarily. No opinion required.
Piece 5 (how to tell what’s winning) maps to Lakatos’s distinction between progressive and degenerating research programmes. A progressive programme generates novel predictions that come true. A degenerating one only makes ad hoc excuses. MCP is progressive. “Just use CLI” is static.
Piece 6 (intelligence doesn’t replace infrastructure) is a Socratic refutation — taking the strongest form of the opposing argument and showing that it leads to a conclusion the arguer themselves would reject. If “smart enough agents don’t need protocols,” then smart enough humans shouldn’t need programming languages. The argument defeats itself.
And the meta-method — “state what evidence would prove you wrong” — comes from Karl Popper’s falsifiability criterion. A theory that can’t be proven wrong isn’t a theory. It’s a belief. For MCP, the falsification conditions are clear: if LLMs can reliably interact with arbitrary unknown tools without any schema or protocol, or if a better protocol eclipses MCP’s adoption, then this analysis is wrong. Neither has happened. But now you know what to watch for.
The bottom line
MCP is 16 months old. It’s buggy. Auth is painful. Context bloat is real.
It also has 97 million monthly SDK downloads, 10,000+ servers, backing from every major tech company, governance under the Linux Foundation, and a research trajectory that keeps producing new capabilities.
Every protocol that became infrastructure went through a phase where smart people declared it dead. USB-C survived the dongle era. Kubernetes survived being “too complex.” The core ideas were right. The implementations matured.
You’re going to see a lot of “X is dead” posts in your career. Now you have the tools to figure out — on your own, without needing anyone else’s opinion — whether the death certificate is real or premature.
Think clearly. Build deliberately. Ship the thing.