I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP.
The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant.
The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers.
And that's why MCP is not only not dead, but more important than ever.
Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search.
All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to.[0] That's what matters.
So, is MCP dead as a direct communication layer for models to speak to? Maybe, maybe not. Is MCP dead as a protocol? Hell no, couldn't be further from the truth.
[0]: Although I will say the Codex app's computer & browser use features have made this statement a lot weaker than it used to be. If you haven't tried them yet—they're mindblowing.
show comments
wolttam
MCP and shell/bash tool calling serve totally different use-cases, this discussion is... odd.
fireant
Besides points already mentioned,
- remote mcps are server driven, meaning the producer can introduce new functionality without requiring all clients to update their skills and clis
- remote mcps are safe as they don't require literal code execution privileges on your system. Many times skills even bundle scripts with `npx`/`uvx` which is basically just `curl npm.com | bash` level of unsafe
CSMastermind
Was this written by AI?
MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with.
It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with.
Whatever you replace MCP with will be in a similar shape even if you specify a different communication protocol or different fields for tool discovery.
show comments
rixed
> Problem 1: It Devours the Context Window
Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command.
> Problem 2: Low Operational Reliability
If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol.
> Problem 3: Overlaps with Existing CLI/API
Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP?
But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean).
> Provide CLI -> API -> docs, in that order
Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.
show comments
olup
Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.
Also the calling of the Mcp is nicer in the chat UI, clearer for users.
rgbrenner
The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use
So these numbers are at least 7 months out of date. Why is this being posted now?
show comments
0907
I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
show comments
customguy
(zero value comment following)
Every time I read MCP, I think it means "master control program".
And I know I will forget again. "Model Context Protocol" is so bland I already forgot half of it by the time I'm at the third word, so that even some old Amiga stuff instantly overrides it.
solarkraft
It's such a dumb discussion.
MCP is an API with some description. It adds tools to your agent, along with some context.
The (common) complaint is that the principle of progressive disclosure isn't working because all tools, with all their descriptions, are loaded into context right at the start. This is a somewhat reasonable complaint, as the structure makes it hard for the harness to progressively disclose the tools.
This is a fundamental issue with anything that just adds a bunch of tools, whether it be via MCP or HTTP (still sad that MCP won over OpenAI's HTTP based approach).
How might it be solved? Well, we could work with sets of tools. That's pretty much what the CLI approach does: Wait until you need it, then invoke the help command to discover what to do exactly. The caveat of the CLI being that it's a nightmare to secure.
At the end of the day, every capability eats some amount of context because the LLM needs to know when to invoke it.
IFC_LLC
I love those "A coring drill is dead?" article.
"We've done extensive renovations in our apartment and while the coring drill was essential to install electrical conduits it's pretty useless in making furniture installations".
In the world of AI development we are jumping from tech to tech every 20 minutes. I'm in shivers every time when I see "A new claude version was released, do you want to update now?"
The moment you kinda automate something with the AI, the process breaks and you have to build the new thing.
So don't blame a coring drill.
ericyd
> Restaurant analogy:
> You sit down and 10 menus (MCP tool definitions) are spread across the table
> There's no room left for actual food (your work)
> Every time you order, the menus have to be pulled out again
This is a bad analogy. Ordering repeatedly is uncommon except for tapas restaurants. You could easily put food on top of menus, but more commonly, menus are removed after ordering, thereby freeing the table (context??) for the food. If you're going to try to explain things by analogy, it's worth putting effort into making it more relevant.
miki123211
Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH.
SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (through public keys), streaming output, interactive I/O, even file transfers (through scp / rsync) if that's something you want.
If your users link their accounts to Github or GitLab, you can even scrape their ssh keys and pre-configure authentication for them, so they just connect and they're in.
osigurdson
>> MCP consumes ~65x more tokens than the CLI approach.
For this example, there seems to be no explanation for the LLM to know when to use this curl command, etc. Is the idea that the linear API is known in the LLM weights already and therefore there is no need to include "the manual" in the context window? If so, it's a pretty narrow win.
show comments
big-chungus4
Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have agents without it.
The problems listed on the article are problems with specific tools that have large tool descriptions. This has nothing to do with MCP. There is nothing in MCP that would cause the tool descriptions to use more context than they would otherwise.
show comments
tanin
If you build connectors for yourself or your team, you probably can skip MCP because you can tell your friends to install CLI or whatever and provide extra prompts for your CLI.
If you have external users, then you have to use MCP, which comes with how to use each endpoint and etc. MCP is what their current apps e.g. Cowork, Cursor support out-of-the-box.
In that sense, MCP is very much not dead
show comments
jaynate
Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.
show comments
Spiritus
CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.
It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.
OpenWaygate
I used to compare MCP and Skill in my post (AI-assisted [1]) and also maintain a CLI/MCP/Skill for YouTube.
In my opinion, MCP is not dead. "MCP Belongs to Software Engineering", it ships existing concepts from software engineering into AI. CLI, MCP-tools, and OpenAPI are interchangeable to some degree, but MCP is more than tools; there are mcp-apps[2], lazy load in context[3].
My mental model for MCPs is that it's like a Swagger/OpenAPI spec for LLMs. Point 2 doesn't make much sense in that context as it's describing MCP as a Swagger endpoint that's unstable.
Chrome/Ghidra MCP does have a tendency of crashing, but I'm not sure why this is. Is my way of thinking of MCP incorrect? If it really is a descriptor of how to talk to another tool, then why do they seem fragile at times? I feel like there's a gap in my knowledge somewhere.
show comments
thecopy
Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/) - it circumvents all the arguments.
In the end MCP is just a protocol for discovering tools. And agents _need_ to do stuff with tools.
c0rruptbytes
is this post old? MCP context poisoning was fixed like months ago
i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
show comments
tyingq
The pro-MCP arguments sound a lot like the same ones for SOAP, J2EE, "Enterprise Service Bus" and other "once-dominant, now dead in favor of dev driven simpler solutions" tech.
menacingly
I don't understand how anyone is still primarily thinking about single-user scenarios in 2026
xurenwu
I think it is on the way to death because of security .
show comments
madrox
MCP is still great if you're running AI in an environment that precludes a shell while needing dynamic tool discovery, but that's a narrow set. People are learning how useful it is to give AI access to a shell. If you're giving them a shell, may as well give them a CLI.
However, I don't think that's what is really hurting MCP, because it could evolve. What really killed it was the standards process and enterprise groups getting ahold of it. It went into spec writing and got adjudicated into uselessness all while enterprise authentication groups were figuring out the best angle to make money on it. I listened to a pitch from Okta on MCP and they wanted to charge out the nose for it for no good reason.
sprakhya
I think mcp will become more important than ever.
king_zee
Besides people with positions relevant to the field I'm weirded out by most of the replies, isn't MCP effectively just a communication standard? Like the only difference between an MCP server and my Express webserver is the supposed logic on how it needs to communicate with the AI, why are we making such a big deal out of it? Eventually we'll all converge into some form of standard to link things to our LLMs and it's probably going to be based in some form on MCP, but I genuinely don't get what the big deal is
crazytweek
A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing.
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
show comments
miguelspizza
I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
kstenerud
> Alternative 1: CLI-First Strategy
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.
_puk
2024. Oh woe, I have to scrape everything, why don't companies just give me an API to consume what I need.
2026. Oh woe, the MCP that all the companies are giving me isn't ideal.
2028? oh woe, the CLI that calls the REST API, that calls the MCP that all the companies are giving me..
extr
The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:
- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.
- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.
- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.
Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?
I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).
woodylondon
I prefer the skill/CLI approach, but with Claude, I have found that building skills or plugins using CLI tools or bespoke code connected to external APIs runs into a problem with what Claude allows in its locked-down sandbox, particularly in Co-Work. The only way out of the sandbox seems to be MCP, and even then, there are timeout issues.
ashm1104
Well, I am not sure why everything is declared dead nowadays, I am actually trying to find the thing that actually die when people claim "x" is dead. Everyone is riding the wave, and so am I tbh...but the dead thing...I mean.. invite me to the funeral then
Alifatisk
There is no publishing date on the article.
zvoque
I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.
show comments
david_shi
A bit off topic, but I think Google's A2A protocol could be a sleeper hit vs. the MCP protocol.
Not because it's better, but with one switch a significant portion of web traffic can be directed to A2A servers through Google's new search box.
cowlby
I use all three (MCP/CLI/API) based on what Claude excels at:
* CLI: GitHub & AWS it already knows how to operate the CLIs well. Even learned about a few new CLIs like 1Password's op which it volunteered one day.
* MCP: Supabase, Shopify etc. where the CLI would be non-obvious and the affordances from the tools/descriptions helps Claude maneuver.
* API: Sometimes it just knows an API exists and is able to call it directly with python/curl. I discovered from Claude the Pokemon ecosystem has a free API out there for example.
show comments
konart
IDK, in my company we are qwen code base agent with quite a few MCP's:
Jira
Confluence
Gitlab
Logs & Metrics platform (inhouse solution)
QA (not sure what this one does)
Context7
mattermost
I have no idea about modern trands etc, but I wouldn't say that MCP is dead. Not the hottest new thing, sure.
robertclaus
A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?
est
MCP is based on a lie: Machines are good at read/generate machine-parsable procotols.
Turns LLMs are shit with JSON. Especially those JSON str embeded inside another JSON key-value pairs.
Why do smart ppl design a schema like escape JSON into str embeded into another?
It's based on another lie: AIs favor static typed languages.
dnnddidiej
I think those are solvable problems. E.g. wrap mcp in skill or seperate forked (non context eating) call to smaller model to ask which mcps are applicable. Iet probably does this. Honestly I have not had issues with MCPs where I felt compelled to debug them.
MCPs are very useful when you don't have a CLI or you do but the MCP can handle auth like a proxy to something (e.g. Splunk). Or just for the USB-C analogy she gave.
etoxin
People who say MCPs are dead don’t understand how MCPs work or when to use them.
bb88
I was writing MCP servers, now I just write tools for agents to consume. It's often easier to simply write the tool you need and suggest to it to look at the tool to do that thing.
I was also surprised to find out Claude knew how to use the gitlab api with pointing it at the token var in the environment. But for corporations it might make more sense to use a cli to keep the secrets separate from the agent.
show comments
TurdF3rguson
I just don't see how she missed in her example that the post to linear graphql endpoint needs the model to load the graphql definitions, there's no way it's 65x the tokens. Whatever overage it actually is, it's well worth not having to muck around with graphql.
willio58
> Using existing CLI directly: No context wasted on tool definitions
Can someone explain this to me? I've seen claude code try to run a not-well-known package and it basically shot in the dark a command, noticed that failed, then ran the help command for the cli tool to get a list of commands and what they do.
How is that different than passing the tools with an MCP? Like how are we saving context?
show comments
krissvai
We can't generalize, it depends on the case, and it's not a XOR. I personally go CLI first, and if not possible MCP.
rbanffy
I’m sure Unisys will still support it for decades to come.
Oh. You mean that new thing also named MCP?
bestony
It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?
tiffanyh
What comes after CLI?
In the early days of computing, desktop apps and later webapps provided richer human experiences.
What will provide richer experiences for agents, after CLIs?
helloansh
mcp will consolidate, its all stdio fragile and stateless
Voblit
good to hear!
pmontra
Meta: there is no question mark in the title of the original post.
fg137
I never understand the "eats context" argument. Why do you have so many MCP enabled in the first place? Do you actually use them in every project?
show comments
comrade1234
So what's this saying? Rather than trust the llm to query external tools via mcp you should handle the external queries yourself? Otherwise the llm wastes a bunch of queries?
0xbadcafebee
Man I wish I could downvote stories. There needs to be some way to push back against dark patterns in writing, like clickbait.
Clearly MCP is not dead, as the article itself says. But the article lies in order to play on human sentiment/heuristics and steal your attention. It's like shouting fire in order to get people to run over to see your business.
show comments
onesingleblast
I swear something is dead every week for yall.
adi_kurian
The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.
vonneumannstan
MCP will die for the same reason RAG died and why prompt engineering is dying. The models get better at understanding what you want and where to find the right tool or context to solve the problem on their own.
827a
The idea that MCP tool definitions take up a certain number of tokens is laughable. That's an implementation detail of the agent harness. MCP is just an API specification. Hell, there's nothing in it that makes it much of any different than OpenAPI, except that its a bit more local-dev focused. There's a thousand things harnesses can and do do to optimize MCP beyond just "spit out the raw MCP output into the context window and pray".
binyu
MCP is what XML dreamed of becoming.
_pdp_
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
show comments
dannypdx
MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.
show comments
jedisct1
When agents don’t encrypt secrets, MCP servers help prevent users from handing their API tokens to AI providers or intermediaries such as Cloudflare and Akamai.
xlii
Is Betteridge's law of headlines irrelevant today?
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer
2) On a laptop
3) With a shell open
Inside an agentic coding harness (Claude Code, Codex CLI, Cursor)
4) Working on a software project
5) That's like... maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
msukkarieh
> MCP is dead
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
hendersoon
Claude code basically fixes MCP context usage with tool search, so MCPs are only loaded into context when actually used. Unfortunately codex doesn't support that functionality.
Until that happy day arrives I run every required MCP with mcpc.
Claude context window is now 1M, not 200K, which significantly weakens the first argument.
show comments
thenewnewguy
These AI slop articles about AI are getting especially boring to read.
> Problem 1: It Devours the Context Window
Don't harnesses support progressive discovery these days?
Claude (200K).... GPT-4o..........?
> every MCP server adds a process layer between the LLM and the underlying API
But a CLI doesn't?
------------------
> Measurement: Tool Definition Sizes
> MCP Server: Linear, Notion, Slack, Postgres
Oh, so these are the MCP servers that are examples of context bloat we're going to replace! Later in the article:
> At Quandri we use all three approaches side by side...
> MCP for services without a strong CLI (Slack, Linear, Notion)
show comments
joeyguerra
Wait. it was alive?
iJohnDoe
MCP is dead. AI bubble. Windows is dead. Linux is dead.
The only thing worse than the people saying it are the people that repeat it.
show comments
ActorNightly
Everyone is sort of missing the point here.
While the title is quite obnoxious, the author is right.
I don't think that anyone would argue against standardizing training for any model on ways of invoking tools through specific output templates (with MCP being an extension of that). However, the question is what is the best way of having the model use those tools? There are 2 options
1 - Encode actual functionality during training, let the model figure out how to use available tools to do what it needs to. Latest Claude models are a good example of this, when editing files if it encounters issues with the under the hood tool, it will write a bash python command to edit the file
2 - Describe functionality in instruction context. This allows you to define complex sequences of things to do, but at the risk of the model losing context as the conversation continues.
3 - Use tool calling, where every request gets an available tools section appended to it, and define the complex functionality in the static code (whether its local tools or MCP servers)
Ideally, if we are pushing towards smarter models, the answer is between 1 and 2, where you have a model that only has access to be able to run shell commands, and some memory that it can reference on sequences of shell commands to run. An MCP invocation is then a simple echo jsonrpc pipe to local executable or a curl command. Eventually, its probably worthwhile to have your LLM run in a CPU like sandbox where it can execute arbitrary assembly commands from sequences stored in memory to do what it needs to do.
Until then, 2 and 3 are really what we have for adapting with current frameworks.
show comments
figmert
I don't know about it being dead, but i certainly stopped using it because it kills the context. A huge amount of tokens are wasted to mcp when in use. Skills use far fewer tokens. From my experience anyway. I'm also not advanced enough so maybe I'm not using it right.
I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP.
The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant.
The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers.
And that's why MCP is not only not dead, but more important than ever.
Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search.
All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to.[0] That's what matters.
So, is MCP dead as a direct communication layer for models to speak to? Maybe, maybe not. Is MCP dead as a protocol? Hell no, couldn't be further from the truth.
[0]: Although I will say the Codex app's computer & browser use features have made this statement a lot weaker than it used to be. If you haven't tried them yet—they're mindblowing.
MCP and shell/bash tool calling serve totally different use-cases, this discussion is... odd.
Besides points already mentioned,
- remote mcps are server driven, meaning the producer can introduce new functionality without requiring all clients to update their skills and clis
- remote mcps are safe as they don't require literal code execution privileges on your system. Many times skills even bundle scripts with `npx`/`uvx` which is basically just `curl npm.com | bash` level of unsafe
Was this written by AI?
MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with.
It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with.
Whatever you replace MCP with will be in a similar shape even if you specify a different communication protocol or different fields for tool discovery.
Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.
Also the calling of the Mcp is nicer in the chat UI, clearer for users.
The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use
So these numbers are at least 7 months out of date. Why is this being posted now?
I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
(zero value comment following)
Every time I read MCP, I think it means "master control program".
http://mcp.a1k.org/indexe.html
And I know I will forget again. "Model Context Protocol" is so bland I already forgot half of it by the time I'm at the third word, so that even some old Amiga stuff instantly overrides it.
It's such a dumb discussion.
MCP is an API with some description. It adds tools to your agent, along with some context.
The (common) complaint is that the principle of progressive disclosure isn't working because all tools, with all their descriptions, are loaded into context right at the start. This is a somewhat reasonable complaint, as the structure makes it hard for the harness to progressively disclose the tools.
This is a fundamental issue with anything that just adds a bunch of tools, whether it be via MCP or HTTP (still sad that MCP won over OpenAI's HTTP based approach).
How might it be solved? Well, we could work with sets of tools. That's pretty much what the CLI approach does: Wait until you need it, then invoke the help command to discover what to do exactly. The caveat of the CLI being that it's a nightmare to secure.
At the end of the day, every capability eats some amount of context because the LLM needs to know when to invoke it.
I love those "A coring drill is dead?" article.
"We've done extensive renovations in our apartment and while the coring drill was essential to install electrical conduits it's pretty useless in making furniture installations".
In the world of AI development we are jumping from tech to tech every 20 minutes. I'm in shivers every time when I see "A new claude version was released, do you want to update now?"
The moment you kinda automate something with the AI, the process breaks and you have to build the new thing.
So don't blame a coring drill.
> Restaurant analogy:
> You sit down and 10 menus (MCP tool definitions) are spread across the table
> There's no room left for actual food (your work)
> Every time you order, the menus have to be pulled out again
This is a bad analogy. Ordering repeatedly is uncommon except for tapas restaurants. You could easily put food on top of menus, but more commonly, menus are removed after ordering, thereby freeing the table (context??) for the food. If you're going to try to explain things by analogy, it's worth putting effort into making it more relevant.
Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH.
SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (through public keys), streaming output, interactive I/O, even file transfers (through scp / rsync) if that's something you want.
If your users link their accounts to Github or GitLab, you can even scrape their ssh keys and pre-configure authentication for them, so they just connect and they're in.
>> MCP consumes ~65x more tokens than the CLI approach.
For this example, there seems to be no explanation for the LLM to know when to use this curl command, etc. Is the idea that the linear API is known in the LLM weights already and therefore there is no need to include "the manual" in the context window? If so, it's a pretty narrow win.
Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have agents without it.
The problems listed on the article are problems with specific tools that have large tool descriptions. This has nothing to do with MCP. There is nothing in MCP that would cause the tool descriptions to use more context than they would otherwise.
If you build connectors for yourself or your team, you probably can skip MCP because you can tell your friends to install CLI or whatever and provide extra prompts for your CLI.
If you have external users, then you have to use MCP, which comes with how to use each endpoint and etc. MCP is what their current apps e.g. Cowork, Cursor support out-of-the-box.
In that sense, MCP is very much not dead
Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.
CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.
It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.
I used to compare MCP and Skill in my post (AI-assisted [1]) and also maintain a CLI/MCP/Skill for YouTube.
In my opinion, MCP is not dead. "MCP Belongs to Software Engineering", it ships existing concepts from software engineering into AI. CLI, MCP-tools, and OpenAPI are interchangeable to some degree, but MCP is more than tools; there are mcp-apps[2], lazy load in context[3].
[1]: https://log.ifor.dev/posts/mcp_vs_skill/
[2]: https://modelcontextprotocol.io/extensions/apps/overview
[3]: https://code.claude.com/docs/en/agent-sdk/tool-search
My mental model for MCPs is that it's like a Swagger/OpenAPI spec for LLMs. Point 2 doesn't make much sense in that context as it's describing MCP as a Swagger endpoint that's unstable.
Chrome/Ghidra MCP does have a tendency of crashing, but I'm not sure why this is. Is my way of thinking of MCP incorrect? If it really is a descriptor of how to talk to another tool, then why do they seem fragile at times? I feel like there's a gap in my knowledge somewhere.
Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/) - it circumvents all the arguments.
In the end MCP is just a protocol for discovering tools. And agents _need_ to do stuff with tools.
is this post old? MCP context poisoning was fixed like months ago
i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
The pro-MCP arguments sound a lot like the same ones for SOAP, J2EE, "Enterprise Service Bus" and other "once-dominant, now dead in favor of dev driven simpler solutions" tech.
I don't understand how anyone is still primarily thinking about single-user scenarios in 2026
I think it is on the way to death because of security .
MCP is still great if you're running AI in an environment that precludes a shell while needing dynamic tool discovery, but that's a narrow set. People are learning how useful it is to give AI access to a shell. If you're giving them a shell, may as well give them a CLI.
However, I don't think that's what is really hurting MCP, because it could evolve. What really killed it was the standards process and enterprise groups getting ahold of it. It went into spec writing and got adjudicated into uselessness all while enterprise authentication groups were figuring out the best angle to make money on it. I listened to a pitch from Okta on MCP and they wanted to charge out the nose for it for no good reason.
I think mcp will become more important than ever.
Besides people with positions relevant to the field I'm weirded out by most of the replies, isn't MCP effectively just a communication standard? Like the only difference between an MCP server and my Express webserver is the supposed logic on how it needs to communicate with the AI, why are we making such a big deal out of it? Eventually we'll all converge into some form of standard to link things to our LLMs and it's probably going to be based in some form on MCP, but I genuinely don't get what the big deal is
A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing.
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
> Alternative 1: CLI-First Strategy
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.
2024. Oh woe, I have to scrape everything, why don't companies just give me an API to consume what I need.
2026. Oh woe, the MCP that all the companies are giving me isn't ideal.
2028? oh woe, the CLI that calls the REST API, that calls the MCP that all the companies are giving me..
The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:
- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.
- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.
- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.
Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?
I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).
I prefer the skill/CLI approach, but with Claude, I have found that building skills or plugins using CLI tools or bespoke code connected to external APIs runs into a problem with what Claude allows in its locked-down sandbox, particularly in Co-Work. The only way out of the sandbox seems to be MCP, and even then, there are timeout issues.
Well, I am not sure why everything is declared dead nowadays, I am actually trying to find the thing that actually die when people claim "x" is dead. Everyone is riding the wave, and so am I tbh...but the dead thing...I mean.. invite me to the funeral then
There is no publishing date on the article.
I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.
A bit off topic, but I think Google's A2A protocol could be a sleeper hit vs. the MCP protocol.
Not because it's better, but with one switch a significant portion of web traffic can be directed to A2A servers through Google's new search box.
I use all three (MCP/CLI/API) based on what Claude excels at:
* CLI: GitHub & AWS it already knows how to operate the CLIs well. Even learned about a few new CLIs like 1Password's op which it volunteered one day.
* MCP: Supabase, Shopify etc. where the CLI would be non-obvious and the affordances from the tools/descriptions helps Claude maneuver.
* API: Sometimes it just knows an API exists and is able to call it directly with python/curl. I discovered from Claude the Pokemon ecosystem has a free API out there for example.
IDK, in my company we are qwen code base agent with quite a few MCP's:
Jira
Confluence
Gitlab
Logs & Metrics platform (inhouse solution)
QA (not sure what this one does)
Context7
mattermost
I have no idea about modern trands etc, but I wouldn't say that MCP is dead. Not the hottest new thing, sure.
A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?
MCP is based on a lie: Machines are good at read/generate machine-parsable procotols.
Turns LLMs are shit with JSON. Especially those JSON str embeded inside another JSON key-value pairs.
Why do smart ppl design a schema like escape JSON into str embeded into another?
It's based on another lie: AIs favor static typed languages.
I think those are solvable problems. E.g. wrap mcp in skill or seperate forked (non context eating) call to smaller model to ask which mcps are applicable. Iet probably does this. Honestly I have not had issues with MCPs where I felt compelled to debug them.
MCPs are very useful when you don't have a CLI or you do but the MCP can handle auth like a proxy to something (e.g. Splunk). Or just for the USB-C analogy she gave.
People who say MCPs are dead don’t understand how MCPs work or when to use them.
I was writing MCP servers, now I just write tools for agents to consume. It's often easier to simply write the tool you need and suggest to it to look at the tool to do that thing.
I was also surprised to find out Claude knew how to use the gitlab api with pointing it at the token var in the environment. But for corporations it might make more sense to use a cli to keep the secrets separate from the agent.
I just don't see how she missed in her example that the post to linear graphql endpoint needs the model to load the graphql definitions, there's no way it's 65x the tokens. Whatever overage it actually is, it's well worth not having to muck around with graphql.
> Using existing CLI directly: No context wasted on tool definitions
Can someone explain this to me? I've seen claude code try to run a not-well-known package and it basically shot in the dark a command, noticed that failed, then ran the help command for the cli tool to get a list of commands and what they do.
How is that different than passing the tools with an MCP? Like how are we saving context?
We can't generalize, it depends on the case, and it's not a XOR. I personally go CLI first, and if not possible MCP.
I’m sure Unisys will still support it for decades to come.
Oh. You mean that new thing also named MCP?
It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?
What comes after CLI?
In the early days of computing, desktop apps and later webapps provided richer human experiences.
What will provide richer experiences for agents, after CLIs?
mcp will consolidate, its all stdio fragile and stateless
good to hear!
Meta: there is no question mark in the title of the original post.
I never understand the "eats context" argument. Why do you have so many MCP enabled in the first place? Do you actually use them in every project?
So what's this saying? Rather than trust the llm to query external tools via mcp you should handle the external queries yourself? Otherwise the llm wastes a bunch of queries?
Man I wish I could downvote stories. There needs to be some way to push back against dark patterns in writing, like clickbait.
Clearly MCP is not dead, as the article itself says. But the article lies in order to play on human sentiment/heuristics and steal your attention. It's like shouting fire in order to get people to run over to see your business.
I swear something is dead every week for yall.
The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.
MCP will die for the same reason RAG died and why prompt engineering is dying. The models get better at understanding what you want and where to find the right tool or context to solve the problem on their own.
The idea that MCP tool definitions take up a certain number of tokens is laughable. That's an implementation detail of the agent harness. MCP is just an API specification. Hell, there's nothing in it that makes it much of any different than OpenAPI, except that its a bit more local-dev focused. There's a thousand things harnesses can and do do to optimize MCP beyond just "spit out the raw MCP output into the context window and pray".
MCP is what XML dreamed of becoming.
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.
When agents don’t encrypt secrets, MCP servers help prevent users from handing their API tokens to AI providers or intermediaries such as Cloudflare and Akamai.
Is Betteridge's law of headlines irrelevant today?
https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines
Do CLI enjoyers realize that MCP can be called via curl?
For example I have a no-auth clock for AI deployed from https://github.com/firasd/mcpclock to https://mcpclock.firasd.workers.dev/mcp (anyone is welcome to go ahead and add it to your AI apps as an MCP endpoint)
You can still call it via CLI if you're a MCP hater
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' event: message data: {"result":{"content":[{"type":"text","text":"[\n {\n \"timezone\": \"UTC\",\n \"iso\": \"2026-05-30T04:05:07.175Z\",\n \"unixtime\": 1780113907\n },\n {\n \"timezone\": \"Alphadec\",\n \"alphadec\": \"2026_K6G7_066464\"\n }\n]"}]},"jsonrpc":"2.0","id":1}
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/list","params":{"name":"","arguments": {}}}' 2>&1 | grep '^data:' | sed 's/^data: //'| jq -r '.result. tools[].name' clock_get clock_day_info clock_convert clock_convert_alphadec clock_convert_unixtime clock_shift_utc clock_delta_utc clock_delta_alphadec
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer 2) On a laptop 3) With a shell open Inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project 5) That's like... maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
> MCP is dead
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
Claude code basically fixes MCP context usage with tool search, so MCPs are only loaded into context when actually used. Unfortunately codex doesn't support that functionality.
Until that happy day arrives I run every required MCP with mcpc.
[1] https://github.com/apify/mcpc
Claude context window is now 1M, not 200K, which significantly weakens the first argument.
These AI slop articles about AI are getting especially boring to read.
> Problem 1: It Devours the Context Window
Don't harnesses support progressive discovery these days?
Claude (200K).... GPT-4o..........?
> every MCP server adds a process layer between the LLM and the underlying API
But a CLI doesn't?
------------------
> Measurement: Tool Definition Sizes
> MCP Server: Linear, Notion, Slack, Postgres
Oh, so these are the MCP servers that are examples of context bloat we're going to replace! Later in the article:
> At Quandri we use all three approaches side by side...
> MCP for services without a strong CLI (Slack, Linear, Notion)
Wait. it was alive?
MCP is dead. AI bubble. Windows is dead. Linux is dead.
The only thing worse than the people saying it are the people that repeat it.
Everyone is sort of missing the point here.
While the title is quite obnoxious, the author is right.
I don't think that anyone would argue against standardizing training for any model on ways of invoking tools through specific output templates (with MCP being an extension of that). However, the question is what is the best way of having the model use those tools? There are 2 options
1 - Encode actual functionality during training, let the model figure out how to use available tools to do what it needs to. Latest Claude models are a good example of this, when editing files if it encounters issues with the under the hood tool, it will write a bash python command to edit the file
2 - Describe functionality in instruction context. This allows you to define complex sequences of things to do, but at the risk of the model losing context as the conversation continues.
3 - Use tool calling, where every request gets an available tools section appended to it, and define the complex functionality in the static code (whether its local tools or MCP servers)
Ideally, if we are pushing towards smarter models, the answer is between 1 and 2, where you have a model that only has access to be able to run shell commands, and some memory that it can reference on sequences of shell commands to run. An MCP invocation is then a simple echo jsonrpc pipe to local executable or a curl command. Eventually, its probably worthwhile to have your LLM run in a CPU like sandbox where it can execute arbitrary assembly commands from sequences stored in memory to do what it needs to do.
Until then, 2 and 3 are really what we have for adapting with current frameworks.
I don't know about it being dead, but i certainly stopped using it because it kills the context. A huge amount of tokens are wasted to mcp when in use. Skills use far fewer tokens. From my experience anyway. I'm also not advanced enough so maybe I'm not using it right.