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)

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.