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.
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.
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.
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.
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...
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..
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.
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?
> 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.
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.
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'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)
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?
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?
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...
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.
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.
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.
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.
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.
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.
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...
This one? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
Yes, exactly that one! thanks
Exactly right. Co’s like Runlayer are growing like wild exactly for this reason. Without a central control plane MCP is a minefield.
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..
So is this in lieu of using permissions to protect apis? Because it seems like API's should have some kind of permission mechanism around them anyway.
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.
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?
Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.
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
Not providing a publishing date is real maddening.
> 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.
pretty much
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.
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'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.
MCP seems like what you'd do when you want to encapsulate and share a skill+script in a standard way.
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)
You can share a skill by copy pasting the text file to someone in slack.
Its not that hard.
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?
[delayed]
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?
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)
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:
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...