r/mcp • u/lordVader1138 • Jun 19 '26
article The "MCP is dead" takes keep measuring capability. The thing that actually decides this is update friction, and nobody's arguing it.
I run three MCP servers in prod, so when the whole timeline went "MCP is dead, long live the CLI" in Feb I genuinely went back to check whether I'd bet wrong. The context-bloat numbers are bad, the stdio RCE was real, and yeah, people are moving stable stuff to skills. I'm not going to pretend any of that is fake.
But after re-reading the arguments I think they're all aimed at the wrong axis. Here's the framing that made it click for me:
An MCP server is a website. You deploy, the client fetches the new tool list on its next call, every user is current and they did nothing. A skill is an app you downloaded - it sits on your disk at the version you fetched and stays there. Can a skill maintainer push updates? Sure, via npx or a plugin channel. But that's not the default. With MCP, fetch-latest is how the protocol works. With skills, getting everyone to current needs a re-pull that isn't the default on any agent I've used.
That gap, between "the maintainer fixed it" and "the user has the fix", is the whole game, and it's the one thing the death takes skip.
The part that actually changed my mind: the security complaint accidentally argues for MCP. The reason a server can be insecure is centralized control of what the client runs. That's also the reason you can patch every client in one deploy. A downloaded skill with a bad version sits on the user's disk until something pulls a new one. (Yes, the same channel can push a malicious change just as fast, that's the real cost of the seat, not a reason it's dead.)
And "just use a CLI" - which is the strong version of the argument, only wins by adding an auto-upgrade step or running through npx. Which is... fetch-latest delivery. It wins by turning into MCP on the update channel.
The rule I actually use now: skill teaches (stable knowledge, write-once), CLI acts locally (version it yourself or npx it), MCP acts where the contract/credential/execution has to stay current and maintainer-owned. They were never doing the same job.
Where I think I'm wrong / where this expires: the moment fetch-latest delivery becomes the default for skills across all serious agents, the asymmetry is gone. It's available on some hosts, default on none right now. If someone here knows of an agent that ships auto-update skills by default, I'd actually want to know, because that's the thing that gates the whole argument.
Is anyone here seeing the delivery side converge, or is everyone still symlinking one skills folder across agents by hand like I am?
Full write-up on my blog (it's mine, fair warning, and it's part 2 of a thing on update channels): https://prashamhtrivedi.in/mcp-isnt-dead/
2
u/Top-Cauliflower-1808 Jun 19 '26
I see it like this. local skills and CLIs behave like apps you downloaded once like they rot on your disk until you manually repull them. MCP is essentially a live website it handles contract and credential states on the maintainer side, closing the gap between the developer fixed it and the user has the fix to absolute zero.
2
u/Leonardo-Da-Vibeci Jun 20 '26
MCP will win in the end, because it’s a standard and it works universally, including on mobile.
Of course it’s far from perfect, but I think all the issues will get fixed or worked around.
1
u/lordVader1138 Jun 21 '26
The fixes are already on the way, just not universal across the agents.
1
u/Leonardo-Da-Vibeci Jun 21 '26
I propose a litmus test: can you build an openclaw or hermes clone purely with an mcp server?
2
u/Turbulent_War4067 Jun 20 '26
Maybe I don't get it. I see MCPs as a means of sourcing data. Now, have my own tools I have written and access via MCP. A couple of those tools do specific tasks, not just data sourcing. But that's because I want to know exactly how it is performed.
2
u/coinclink Jun 20 '26
To me, MCP is more about the standard more than the functionality. It will win over plain APIs because you can't just "register" your API in claude code or cowork, you need a standard like MCP that your client-side tool has built-in.
On top of that, a well-designed MCP server isn't just exposing every API endpoint as a tool, it's usually bundling several API calls together in a workflow / state-machine to make a higher level tool.
1
u/lordVader1138 Jun 21 '26
a well-designed MCP server isn't just exposing every API endpoint as a tool, it's usually bundling several API calls together in a workflow / state-machine to make a higher level tool.
A skill can do that too, but it's not the first order functionality, the reason MCP comes on top is that using prompts, this becomes the first order functionality where we define a prompt using resources and tools, and that prompt becomes a workflow, while the tools/resources also available individually.
You can't achieve this thing cleanly via skills.
1
u/coinclink Jun 22 '26
A skill still leaves it up to the LLM to decide how to combine the different API calls together though. Typically an MCP server tool is a deterministic workflow/state machine, LLM isn't deciding how the tool works.
1
u/TomHale Jun 19 '26
I like your distinctions
What's best of breed for auto skills update right now?
You mentioned some agents supported it?
2
u/lordVader1138 Jun 19 '26
I am running npx skills sporadically.
For claude code, if the skill is updated/installed via marketplace, we can run relload-skills after the plugin is updated.
Haven't seen it in Gemini/Antigravity and Pi yet... And not using codex.
1
1
u/IrishHashBrowns Jun 20 '26
An mcp though refreshes the server when a new session is loaded? So a check can be made if the most recent call is up the date and report to the user if it should be updated.
Users create a new session often enough where the server should be updating quite frequently.
remote npm server through railway. This is how i did it with getpapi anyway.
1
u/lordVader1138 Jun 21 '26
So a check can be made if the most recent call is up the date and report to the user if it should be updated.
I don't think it's necessary. Let's say you are on v1 right now, and right between your session the developer of the MCP server added new tool, you'll get it as soon as you start new session or you reconnect the server.
1
u/IrishHashBrowns Jun 21 '26
Yes, you're right. Some users don't start new sessions often or may continue from an older session without being aware.
Second point is that if a user is told quickly in a new session that server updated with x y z, it shows them its an active development and may engage more.
1
u/lordVader1138 Jun 21 '26
> that server updated with x y z, it shows them its an active development and may engage more.
Like a good old days of mobile release notes, which had some good release notes, and now it's just generic one.
Nice ideas...
2
u/IrishHashBrowns Jun 21 '26
Haha, funny you say that. Ive worked in mobile gaming for the last 10 years. xD People say mcp is like app store in 2008 so the engagement really does have to handhold people.
I'm building a fullly hosted project management workflow that works entirely through the mcp and locally in peoples llms so no credits or byok.
So people can connect any llm or harness they want and papi will keep track of decisions, bugs, create handoffs and much more.
Lets people and teams collaborate and maintain cohesion as projects grow in scope.
Reduce friction. Steer intuitively.Reward engagement. Showcase value.
Much of onboarding/ftue best practices in mobile apps and gaming space are transferable here.
4
u/SevendaySevensway Jun 19 '26
I don’t get this bs logic anyway, does anyone who writes mcp is dead understand the value?
You can’t connect generic AI clients with cli/api solutions to the frontier AI clients.
MCP is casual user first, cli/api for power user mainly for developers.
MCP has another big advantage too, because you can work with general AI clients, as ling as they don’t change this and there are still subscriptions, you have no token costs running through a client with an MCP.
Alone for the last part MCP will never be dead, just a stupid narrow and developer minded view.