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.
Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents.
Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.
Yeah it was quite weird seeing "Many of these companies don't even have an external API!" given MCP is literally a protocol for an external API. Not a good one in my opinion but it indeed has mindshare.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
> 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.
Wow if that's not an echo-chamber comment I don't know what is.
It’s definitely an outlandish statement to make. There’s 200-400mn companies in the world on a conservative estimate. I assume the poster means something like “all listed companies”.
You failed to describe what value the MCP protocol provides.
If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?
One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.
MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two.
Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.
MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.
Sure. It would be great if they were portable as well.
To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.
If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.
MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.
Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?
Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification.
You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.
But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.
Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
and many more that offer both, but support their MCP more.
Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.
There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.
At times I feel like these people are naive and may be do not have enough practical industry experience around software development, and then on second thought I realize that they are way smarter and counting on everyone else being naive here. This is a cycle of FOMO and a temporary phase.
Something like MCP is not a one time investment, the API's need to be maintained and updated regularly to be useful. Maintenance work is already a cost factor and no one gets promoted by maintaining anything.
Within organizations, smart carrier oriented folks are picking up this area of work for their personal growth and visibility which comes across as if every company is going for it.
Did you consider that maybe he has different information than you do, and thus he holds a different opinion?
I for one love MCP. It's way faster in my experience than skills / shell. And I like how (with Claude Code) I can setup the MCP in the web interface, use it in the chat and the CLI.
Plus the flow to add an MCP via the browser is achievable to any user.
And one thing I don't understand of skills is this. I have an MCP for my life organisation app that authorizes via OAuth. The flow is fully via the browser so I can use the app session and its stored somewhere in claude.ai. How does authentication work with skills?
It would be really, really great if Codex could support MCP Prompts[0]
This would allow us to deliver standard prompts across the team without having to sync manually or with scripts; keep everyone up to date. Even allow per-user customization of "skills" via server rendering of the prompts.
AFAIK, Codex is the only major harness to not support this.
I agree. Mcp might be useless in a personal scenario but it absolutely plays a role of service infrastructure in organizations. It is another form of api for those abilities that are not wrapped with rest api yet. But when they are wrapped in mcp, it seems not necessary to wrap them into rest api or cli again in near future. So these mcp services survive.
The only thing matters is how to import these mcp services into agent context on demand or say by the gradual disclosure principle.
This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.
It's not 'who is building' but 'who is using' that's the concern.
AI is a bandwagon tech, a lot of people will 'build because others are' adhering to an ostensible standard.
Most of the people that I know are moving away from MCP in favour of skills where the advantage of MCP goes away if the REST API is clear enough.
Also - I'm sorry to say but MCP management on Codex (and Claude) is just really bad. Everything from discovery, to management, to context window, to documentation - it feels unfinished as a 'feature' even if the protocol is supposed to be narrow.
1) I have a big popup and yellow warning every time a window is opened or a sub agent is launched warning me that 'SkySomething Computer Use' does not work. I had to Google to find out that has something to do with Codex MCP. So already the externalizations of problems, resolutions ... not very well done.
I'm not even sure what to do - and I'm honestly not interested in 'fixing' something I didn't cause, I'm not sure of, and don't want to deal with.
2) Just listing the current MCPs, knowing really what the are for (clearly, concisely) is hard.
What's that supposed to mean? What is 'codex_apps'?
As presented - it resolves to 'nonsense gibberish'. Those are things that I did not even install.
Do you expect people magically know what 'codex_apps' is?
Here is what 'AGI!' Codex 5.5 answered when I asked about 'codex_apps' is:
====
" codex_apps appears to be Codex’s own internal cache/tooling area, not part of J1 (my project).
"I only found it under .codex, e.g.:"
" I did not find it referenced by the J1 source. So unless you saw it somewhere specific, treat it as Codex runtime metadata for app/tool integration, not project code."
====
So even Codex itself has no idea what it's own MCP tools are, and after a full '1 minute of thinking' on 'xhigh' it responded with nonsense.
This whole experience fundamentally deflates my perception of AU, OpenAI, Codex and MCP.
This is supposed to be the 'future' but it feels like 1982 dialup.
This is where 'traditional UX' really starts to show it's value obviously, but you really need to consider enhancing this experience, possibly with some traditional ux mechanisms.
3) Knowing the 'state' of the MCP is totally opaque. Is the 'MCP server' running? Can I restart it? That might be outside the scope of 'Codex' but you're offering the product so all of the underlying stuff is essentially 'your responsibility' as well at least from a UX perspective. Why isn't the 'state' of the MCP listed.
4) How can I not just easily enable/disable individual MCPs so they don't chew up context?
5) How can I not discover MCPs from codex itself, so that I can find solutions to problems? MCPs are all a bit different, and awkward to install and manage. Like with VS Code, we can 'discover plugins'. Even from the Web we can search and discover plugins.
While I realize that most of this rant is oriented around MCP tooling management, and not the standard, I do feel that these issues are 'fundamentally at the crux' of the situation.
Our team has moved away from MCP into Skills - and after doing so, it's hard to see why MCP is going to be valuable - other than plausibly as defining some 'jon calling conventions'.
There's a lot of obvious things to improve, please do that.
This is not even 'basic product design' - it's just 'product common sense'.
That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.
They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.
If they don't do that, all the money in the world and all the best product people wouldn't be able to help.
I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?
No offense but you are paid to say these things. Your paycheck depends on it [1]
[1] “It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
― Upton Sinclair, I, Candidate for Governor: And How I Got Licked
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.
It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem.
'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work
The scope was too narrow, given how it ended up being applied.
If they layer something on top of it, it may yet be revived.
> 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.
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].
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...
Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using.
Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.
hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..
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?
Its crazy that people are still discussing this. It's ancient history. Deferred tool loading, large contexts, and prompt caching have made 2026 completely different from 2025.
Also, the "CLI saves token" debate really falls apart when step one of using the CLI is running "--help". The problem remains: if knowing how to call the thing isn't in parametric memory, it has to be in context.
And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.
To do it client-side:
1. Define a single tool, tool_search
2. List the names of your deferred tools in context (or tool_search's description)
3. When tool_search is called, match the query against the tool names (or names + descriptions)
4. Append the matched tool def to the context in a new <system>-esque tag
Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.
Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools.
Crazy that the company that invented MCP is not putting basic features like this in the product.
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.
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.
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.
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.
> Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply.
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
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.
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.
personally if i have the need to move a skill/script, etc. to another one of my machines, i'll make a git repo for them (if they aren't already on git)
This was one of the first ideas me and my team had for sharing skills and scripts. The problem is this is a very "why Dropbox and not FTP" answer.
The second you utter the word git, you may have lost 90% of your audience - depending on their background, of course. MCPs are a lot more non-tech friendly
yeah it 100% depends on who you'll be sharing them with, for me its just myself and a couple agents i have on a dedicated machine so git is ideal to keep versions matching when i update something on my daily driver
You can’t sell that in b2b negotiations though. You can absolutely say “and for $x per user we will grant you access to our central, closed-source MCP server that does things our CLI doesn’t do”.
right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that.
i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
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.
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
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.
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'.
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.
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.
> 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?
The usual problem is companies write an MCP server with 50 different tools, and each one has a schema, description, etc. Say each tool is 150 tokens, that's 150 * 50, or 7500 tokens, dumped into the beginning of every session. Compared to a text file that gets loaded on demand with command-line tool examples, so you still get close to the same amount of context, but you can control what tool definitions you pull in.
The other thing is the agent gets the entire MCP API response dumped into context as a tool response in JSON, which can be a lot. Compare that to shell commands where agents often `head` or `tail` or `grep` the response (which I kinda hate, but it does save tokens).
It also depends on whether the agent loads them on-demand or not (most modern agents do), and whether your MCP has a ton of tools or not. If your MCP only has 2 tools, and the responses aren't big, it's really not that much context.
The other thing that doesn't get talked about is the non-determinism of shell one-liners. There is a lot more non-determinism in shell tool calls; the AI can mess up commands, options, arguments. It can incorrectly filter output, miss output, miss return status, which results in re-running calls, polluting context, making results worse. Compare that to MCP calls which are more likely to succeed because they have a schema, well-defined errors, etc. Do you want less token use or more reliable results?
The thing is, you don't have to pick a side. I personally use both MCPs and CLIs at different times in different ways. Often I'll have the AI write a small script to do many calls (sometimes with tools, sometimes with libraries) which saves tokens, allows me to review, and is more deterministic.
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".
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.
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.
There's a fix for the context which involved an mcp search and execute gateway. Essentially the mcp server queries for desired capabilities, gets search results with execution and requirement details and fires off the actual mcp as subcalls:
You can call it "rag for mcp". I was pushing it hard a few months ago and nobody seemed to care but I'm all in if the timing has caught up to the tech.
It's nontrivial effort: basically a giant survey of all the mcp servers, running inference over them to figure out how to instrument them, cross referencing to make sure they are the "official" sources (or at least the ones that search engines think are) then using qdrant to do embeddings and reranking and offering it for free.
If people have become interested I'm all in. I'll bring the infra back up. I just don't want to spin my wheels on dead end streets.
The value proposition is solid, the problem is real, this fix works, it's fast, it's free, and people give exactly zero shits. I dunno...
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.
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.
Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.
Agents are just making REST calls and that's it.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
It could very well entrench itself however.
Wow if that's not an echo-chamber comment I don't know what is.
If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?
Still easily doable with CLI
Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.
MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.
[0] https://modelcontextprotocol.info/docs/concepts/prompts/
[1] https://modelcontextprotocol.info/docs/concepts/resources/
[2] https://modelcontextprotocol.io/specification/2025-11-25/cli...
[3] https://modelcontextprotocol.io/specification/2025-11-25/ser...
To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.
If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.
MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.
Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?
You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.
But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI:
and many more that offer both, but support their MCP more.Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.
There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.
They have different tradeoffs.
> And that's why MCP is not only not dead, but more important than ever.
Just screams "written by GPT."
Something like MCP is not a one time investment, the API's need to be maintained and updated regularly to be useful. Maintenance work is already a cost factor and no one gets promoted by maintaining anything.
Within organizations, smart carrier oriented folks are picking up this area of work for their personal growth and visibility which comes across as if every company is going for it.
I for one love MCP. It's way faster in my experience than skills / shell. And I like how (with Claude Code) I can setup the MCP in the web interface, use it in the chat and the CLI.
Plus the flow to add an MCP via the browser is achievable to any user.
And one thing I don't understand of skills is this. I have an MCP for my life organisation app that authorizes via OAuth. The flow is fully via the browser so I can use the app session and its stored somewhere in claude.ai. How does authentication work with skills?
This would allow us to deliver standard prompts across the team without having to sync manually or with scripts; keep everyone up to date. Even allow per-user customization of "skills" via server rendering of the prompts.
AFAIK, Codex is the only major harness to not support this.
[0] https://github.com/openai/codex/issues/5059#issuecomment-453...
That’s covered in the article: a human can modify the commands generated by the agent, or vice versa, to debug problems or transfer knowledge.
AI is a bandwagon tech, a lot of people will 'build because others are' adhering to an ostensible standard.
Most of the people that I know are moving away from MCP in favour of skills where the advantage of MCP goes away if the REST API is clear enough.
Also - I'm sorry to say but MCP management on Codex (and Claude) is just really bad. Everything from discovery, to management, to context window, to documentation - it feels unfinished as a 'feature' even if the protocol is supposed to be narrow.
1) I have a big popup and yellow warning every time a window is opened or a sub agent is launched warning me that 'SkySomething Computer Use' does not work. I had to Google to find out that has something to do with Codex MCP. So already the externalizations of problems, resolutions ... not very well done.
I'm not even sure what to do - and I'm honestly not interested in 'fixing' something I didn't cause, I'm not sure of, and don't want to deal with.
2) Just listing the current MCPs, knowing really what the are for (clearly, concisely) is hard.
This is what you get if you type /mcp in Codex:
/mcp
What's that supposed to mean? What is 'codex_apps'?As presented - it resolves to 'nonsense gibberish'. Those are things that I did not even install.
Do you expect people magically know what 'codex_apps' is?
Here is what 'AGI!' Codex 5.5 answered when I asked about 'codex_apps' is:
====
" codex_apps appears to be Codex’s own internal cache/tooling area, not part of J1 (my project).
"I only found it under .codex, e.g.:"
" I did not find it referenced by the J1 source. So unless you saw it somewhere specific, treat it as Codex runtime metadata for app/tool integration, not project code."
====
So even Codex itself has no idea what it's own MCP tools are, and after a full '1 minute of thinking' on 'xhigh' it responded with nonsense.
This whole experience fundamentally deflates my perception of AU, OpenAI, Codex and MCP.
This is supposed to be the 'future' but it feels like 1982 dialup.
This is where 'traditional UX' really starts to show it's value obviously, but you really need to consider enhancing this experience, possibly with some traditional ux mechanisms.
3) Knowing the 'state' of the MCP is totally opaque. Is the 'MCP server' running? Can I restart it? That might be outside the scope of 'Codex' but you're offering the product so all of the underlying stuff is essentially 'your responsibility' as well at least from a UX perspective. Why isn't the 'state' of the MCP listed.
4) How can I not just easily enable/disable individual MCPs so they don't chew up context?
5) How can I not discover MCPs from codex itself, so that I can find solutions to problems? MCPs are all a bit different, and awkward to install and manage. Like with VS Code, we can 'discover plugins'. Even from the Web we can search and discover plugins.
While I realize that most of this rant is oriented around MCP tooling management, and not the standard, I do feel that these issues are 'fundamentally at the crux' of the situation.
Our team has moved away from MCP into Skills - and after doing so, it's hard to see why MCP is going to be valuable - other than plausibly as defining some 'jon calling conventions'.
There's a lot of obvious things to improve, please do that.
That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.
They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.
If they don't do that, all the money in the world and all the best product people wouldn't be able to help.
I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?
I hope they improve.
[1] “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” ― Upton Sinclair, I, Candidate for Governor: And How I Got Licked
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.
'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work
The scope was too narrow, given how it ended up being applied.
If they layer something on top of it, it may yet be revived.
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
> 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.
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
Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.
So these numbers are at least 7 months out of date. Why is this being posted now?
Its crazy that people are still discussing this. It's ancient history. Deferred tool loading, large contexts, and prompt caching have made 2026 completely different from 2025.
Also, the "CLI saves token" debate really falls apart when step one of using the CLI is running "--help". The problem remains: if knowing how to call the thing isn't in parametric memory, it has to be in context.
And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.
To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new <system>-esque tag
Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.
Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
Crazy that the company that invented MCP is not putting basic features like this in the product.
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
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.
MCP is a combination of a server responding to requests, and a prompt to tell the agent how to format those requests.
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
pretty much
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
The second you utter the word git, you may have lost 90% of your audience - depending on their background, of course. MCPs are a lot more non-tech friendly
Its not that hard.
i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
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.
* 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.
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.
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.
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?
The other thing is the agent gets the entire MCP API response dumped into context as a tool response in JSON, which can be a lot. Compare that to shell commands where agents often `head` or `tail` or `grep` the response (which I kinda hate, but it does save tokens).
It also depends on whether the agent loads them on-demand or not (most modern agents do), and whether your MCP has a ton of tools or not. If your MCP only has 2 tools, and the responses aren't big, it's really not that much context.
The other thing that doesn't get talked about is the non-determinism of shell one-liners. There is a lot more non-determinism in shell tool calls; the AI can mess up commands, options, arguments. It can incorrectly filter output, miss output, miss return status, which results in re-running calls, polluting context, making results worse. Compare that to MCP calls which are more likely to succeed because they have a schema, well-defined errors, etc. Do you want less token use or more reliable results?
The thing is, you don't have to pick a side. I personally use both MCPs and CLIs at different times in different ways. Often I'll have the AI write a small script to do many calls (sometimes with tools, sometimes with libraries) which saves tokens, allows me to review, and is more deterministic.
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.
Until that happy day arrives I run every required MCP with mcpc.
[1] https://github.com/apify/mcpc
> 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)
https://github.com/day50-dev/mcp-search-and-run
You can call it "rag for mcp". I was pushing it hard a few months ago and nobody seemed to care but I'm all in if the timing has caught up to the tech.
It's nontrivial effort: basically a giant survey of all the mcp servers, running inference over them to figure out how to instrument them, cross referencing to make sure they are the "official" sources (or at least the ones that search engines think are) then using qdrant to do embeddings and reranking and offering it for free.
If people have become interested I'm all in. I'll bring the infra back up. I just don't want to spin my wheels on dead end streets.
The value proposition is solid, the problem is real, this fix works, it's fast, it's free, and people give exactly zero shits. I dunno...
One day I'll figure it out, hopefully...
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
The only thing worse than the people saying it are the people that repeat it.
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.