No, MCP is definitely not dead. The NSA agrees.

The Technical Executive

SubscribeSign in

No, MCP is definitely not dead. The NSA agrees.<br>The hype of MCP may have died but the enterprise value and growth is clearly there.

Stephane Derosiaux<br>Jun 01, 2026

Share

Every week, I see another post or comment "MCP is dead". I hope it’s just to get views. The arguments:<br>“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.<br>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.<br>Which is to say: MCP was never for you .

They're right (about themselves)

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

MCP is not for power users

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

It's governance, not ergonomics.

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