Every week, I see another post or comment "MCP is dead". I hope it’s just to get views. The arguments:
“MCP is crap and CLIs are amazing. Look, I built two new CLIs this week-end with Claude and I wrote a few skills to use them. Easy to install and set up. It’s cheaper, faster, and more composable than any MCP tools. MCP is bloated. MCP is overkill. MCP is dead.”
Who’s making such argument? A developer, with their terminal. Using git, GitHub, doing Go, Python, Typescript, and having full access to their machine.
I wrote so many CLIs I’ve stopped counting. I half-agree with every post, but only from a dev’s point of view, which is exactly the trap. They're all making the same mistake: they're right about their setup and wrong about whose problem MCP was built to solve.
Which is to say: MCP was never for you.
For one developer, or a team of five, CLIs and skills are great. You share knowledge and a git repo full of scripts with skills. It’s a perfectly good way to manage all of it.
CLIs are wrappers over APIs and they help manage the control boundary: you authenticate your CLI locally and you can switch context to switch env (kubectl, gcloud, aws, etc.). As it’s written against an API (CRUD), you get full parity with the API surface.
Also, MCP gives us a new surface to expose, the mistake being to fill it with CRUD (converting an OpenAPI spec to MCP tools is missing the point). Its caller is a model reasoning inside a conversation, not a human coding with if/then/else against endpoints. The contract is different: it has to carry what the model is trying to do, not just create/read/update/delete.
CLI (CRUD) : gh issue list → gh issue view 42 → gh issue edit --add-label → gh issue comment.
MCP (CRUD): create_issue, get_issue, list_issues
MCP (intent) : *_web_search, suggest_time (Google Calendar MCP).
Running an agent isn’t a developer thing anymore, far from it. And there are way more non-developers than developers in the world. Which means way more non-CLI people than CLI people.
These people will never git clone anything or set up a local config file (they often barely know how to open Finder and explore their hard drive - not a joke, and that’s okay). And even when you know because you are techy, sometimes you just don’t want to be bothered by having to do it.
My salespeople live in Claude Desktop, set up and use agents, and are always on their phone. The data analysts live in a browser tab on Snowflake or Databricks. The ops managers work from Claude and Hubspot and want the assistant to pull a report.
They have never opened a terminal in their life. Ask them to open one to set up a CLI, they look at you like you’re speaking an alien language. And they represent most of the people who will use agents to do their non-developer job. Developers are a rounding error in that population.
And yet they use MCP tools all day. Why? Because IT pushes them to the org, or the LLM vendor ships them as a one-click connector (under “Integration” or “Connectors”). That’s the whole difference: a CLI asks the user to set it up, an MCP gets set up for them. They open Claude Desktop and the tools are already there.
Large companies need tooling governance, pushed centrally, same capabilities for everyone, updated everywhere at once. There is no “Copy this into your setup / Deploy on your machine”.
Do you think security teams enjoy everyone having AI agents running on behalf of all users with production credentials? A human was slow and checked what they were doing, that was fine. Local agents using a CLI on behalf of a human are undetectable and hard to audit. It’s not about “permission delegation”, it’s because AI is opening a new can of worms: far more operations, and unknown, probabilistic, behaviors.
MCP is a front door for agents activities: who’s allowed in, which permissions, what they did, in which order, how many tools it took.
MCP's actual value is not developer experience. It's that it sits between agents and the things they're allowed to touch, as an identity- and policy-aware proxy.
When we take the shortcut of letting our agent use our local CLI (authenticated as us), the human, the governance is missing this whole layer. It’s not “AI makes me faster, why do you care it’s using my CLIs?”, it’s “AI has emergent behaviors and will do things that even you have no idea and no control over, so here is the front door for agents with more controls”.
One place where a platform team exposes only the tools they've vetted. The credentials live there, the permissions, the keys. It hands out short-lived tokens, allowlists what's permitted, runs inside the network and may not even reach the open internet.
One thing that matters: it differentiates human actions from agent actions.
Give an agent a CLI authenticated against remote resources, and the blast radius is your entire shell: everything that the agent can reach, every command that binary can run, other binaries on your laptop, every typo and every prompt injection. Give it an MCP endpoint, and the blast radius is a vetted, logged surface someone chose on purpose.
The power user does not want to see this: you can't see the trust boundary when you are the trust boundary. You don't need a policy-aware proxy between you and your own tools. The thing MCP replaces is the thing you happen to be, which is exactly why it looks pointless from where you're standing.
The strongest technical objection, in 2025. Since then, agents are using multiple strategies:
MCP tools lazy loading: schemas are not loaded at all, loaded on-demand only. Only names are loaded.
Progressive disclosure: not for MCP, but good to know: skills metadata are always loaded but their body is not
The LLM to write a script to call tools: the model can write code that calls the tools instead of invoking them one by one to avoid in-between data to even enter the LLM context.
Execute /context from Claude and see for yourself, MCP tools are not loaded at all:
And plugins load only their metadata:
A setup with 50-plus tools went from roughly 72K tokens of definitions down to about 8.7K: 85% cut, and tool-selection accuracy went up, not down, because a bloated catalog of tools gives the model decision paralysis. Fewer options in context, fewer wrong picks. (anthropic.com/engineering/advanced-tool-use).
Anthropic pushed another trick: let the model write code that calls the tools instead of invoking them one by one. In their example that took a task from 150l tokens to 2k = 98.7% reduction, because intermediate results never enter the context. Code execution is how the agent uses the tools; MCP is how it finds them and how you govern them.
Metadata are the counterpart of what the LLM needs with your CLI: if the model doesn't already know your tool because it’s not well-known / not part of its training, something has to teach it: your SKILLS.md or your --help output. Those are tokens too.
Hand a model raw primitives via an API or a CLI (same thing, as it’s a wrapper) and it will call many endpoints generating lots of tokens and may find pathological ways to use them, generating even more traffic.
MCP is a tool shaped for the job. MCP is not a “CRUD”, it should be deliberately built in an “intent-based” knowing the interactions is coming from a discussion with an LLM.
MCP is designed for conversations with LLMs and agents, not to CRUD a database / a state.
An MCP server is a thing to attack: like a classic API, it’s a fat target sitting in front of everything it can reach, fed by tool results an attacker can poison via prompt injection to extract sensitive data.
The UX is quite poor in general. Cryptic tool names that mean nothing. Tools that change. Confusion about which tool to use. Too specific micro-tools VS mega-tools.
The spec itself https://modelcontextprotocol.io/specification/2025-11-25 keeps evolving. Already mature (nothing new yet in 2026)? Or dead, making this whole post a sham? Look at the timeline:
Nov 2024: MCP launches with resources, prompts, tools.
Mar 2025: OAuth 2.1 authorization, finally
Mar 2025: Streamable HTTP replaces HTTP+SSE
Jun 2025: Structured tool outputs make responses easier to parse and trust.
Jun 2025: Elicitation lets servers ask users for missing information.
Jun 2025: Stronger OAuth rules improve token and resource separation.
Nov 2025: Sampling with tools enables more agentic server-driven flows.
While I was writing this, the NSA put out a security playbook for MCP. TLDR: The protocol can’t enforce security by itself. That depends on the people running it, not the spec.