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.

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?

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.

What’s up with case 09058169? Seems like a 5 minute fix

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

  MCP Tools

  • No MCP tools available.

  • codex_apps
    • Auth: Bearer token
    • Tools: (none)

  • computer-use
    • Auth: Unsupported
    • Tools: (none)

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.