I would bet that MCP is going to die.

The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI.

AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use).

Sure, companies want to expose MCP servers because it is the cool thing to do right now.

So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.

And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.

So MCP feels more like a temporary workaround for current model limitations.

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.

> 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.

The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later.

And to be blunt, a) you're investment bias'ed and b) whether you're selling the product (MCP) to a gazillion companies doesn't exactly disprove a).

Just look at Microsoft -- they've buried more technology than most, and there's little correlation between usefulness and how deeply buried it is, and some would claim that the correlation is _inverse_. Organisational factors are what drive them, just as I suspect they are now driving OpenAI's insistence on MCP. I understand it's hard to see that from inside.

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?

This is a classic PM take IMO, no disrespect.

"Everyone is building this!"

Except... Few are actually using it. So what, exactly, is the value in MCP?

Especially that there are simple ways for anyone to spin their own MCP based on standards like OAS. I talk to dozens of new clients in a given week. Our product should attract users who want MCP. And in the last month only one conversation actively asked us if we had an MCP server. Surprised, I asked about use case and the response was as I'd expect: "No specific use case, we're just playing around with it". Seems to be pretty standard for AI conversations these days.

You should probably consider that your perspective is also biased and you see all the companies that are in esting.

IME, MCP has often lagged APIs in terms of complete ess, so as a user, if there was an API, I would be better off using that because Codex is already so good at calling APIs.

Now, the API story sucks for non-coders, but I'm not really bullish on MCP for dev tools atm.

> practically ~every company on the planet is building an MCP server

That's just because no one knows what they're doing and everyone is trying to copy everyone else. It's a giant mud hut made of shit.

MCP will go away, and something much simpler will play the same role.

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 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.

[0] https://github.com/openai/codex/issues/5059#issuecomment-453...

Isn’t this just a lagging indicator of popularity at the early liftoff of cli ai?

A sign of weariness in the rapid evolution of tooling, where people got off the train a stop too early?

A confusing overloaded acronym (cli) and term (skill) lacking the marketability / easy mind share of a unique acronym?

These all fail to establish a hearty reason to be.

The walking dead are still dead.

Another aspect is access control.

CLIs live in the same namespace as the agent, so any secrets the CLI needs access to, the agent can also exfiltrate. And access control is lightly gated by the agent's tool call policy.

For an enterprise-level deployment, it becomes quickly desirable to have a centralized MCP backbone, on which each MCP is attached to. A place you can attach policies to, log activity, and reason about access control.

Off-topic question: Where is this an "App Store", as this is basically just a curated list off apps? I wouldn't exactly call it a "store". I have an approved ChatGPT App myself, but those do not surface anyway on the chatgpt.com domain. So, this isn't a "store", but a "curated directory". Calling this a store is misleading to a lot of us developers as you can see in the openai forums on this topic, where you find a lot of confusion around this. People put a lot of energy into developing a ChatGPT App, just to find out, they are completely on their own afterwards.

MCP vs CLI is the same discussion as between a GUI app and a web app: it's all about the distribution. There is approximately no difference in functionality except whether you're hitting a dedicated service or running a local tool which connects to a dedicated service.

With saas is turned out that distribution to a browser solves a pretty major pain point and I expect MCPs to be treated the same. Can you trivially replace an MCP server with a CLI tool which accepts a token? Yes - but why do that to yourself when you can hit the endpoint directly?

I think graphql backed by mcp is the technically best solution. Graphql allows an agent to select which fields it wants in context. Graphql is easy to generate clis for / easy to generate libraries for (if we want llms to generate scripts that call tools).

I agree, codex app’s computer use agent feels sci-fi. Closest we’ve seen yet of a general purpose virtual worker.

Please keep in mind that CLIs do not run on mobile and never will. This is the elephant in the room that nearly everypne seems to be ignoring. This "debate" is built around the assumption that AI is only for at-your-desk work. It's obviously not. Having the ability to mix/match the services you use for everything in your life, whether that's email or social networks or managing your book collection, is going to be a normal thing everyone does in the future. It's just not today, because AI companies are almost exclusively focused on the programming use-case (and related desk job stuff).

On browser/computer use: I wish I could try them. But since OpenAI is going down the Apple path of cherry-picking random features to block in the EEA, without much explanation or timeline as to when they will be available (or even why they are blocked in the first place), I am unsure if I will be able to in this lifetime.

The number one value of MCP's is that it forced everyone align on an API protocol, but the protocol itself has room for improvement.

Agreed. I think MCP should stay abstract in the sense tool-calling is. JSON-RPC could be one way to do it.

Agree. But Word of caution: MCP will become the 'company wiki' of the 2020s unless you enable monetization and distribution.

Right now you have to create an MCP but v1s are always easier to maintain than v10.

We're speed running a trap.

Based on the corporate I work, MCP is definitely not that. Not sure if it's useful, I just joined. We'll see.

Remember when practically ~every company on the planet was building an NFT collection?

great post

I find a lot of HN content seems to be doomer farming

i was a big skeptic of MCPs

now i build em

A lot of companies will never build a great CLI, and many will not prioritize a clean public API unless there is obvious demand.

> I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP.

> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server.

You have drunk the kool aid. No shot ~every company is building an MCP server.

I totally agree, we’ve been working with enterprises and MCP is the defacto way they are using agents with data.

Just because everyone builds it doesn't mean it will take off. Case in point: All the cloud serverless BS. Everyone in the industry are now switching back from server less because the math didn't work out.

I think it's just a fad and eventually you'll need to address the math no matter how much you sugar coat it - the 3x slower metric, eating of context window is all beneficial for LLM companies but not for the end user.

Ok, how many AI tools do you even use from 3 years ago? Funnily enough, I stopped paying for my chatGPT subscription a year ago.

I get the debate in this thread but this is IMHO the detail that matters:

"Many of these companies don't even have an external API! And yet, they're all building MCP servers."

Whether or not MCP is a temporary means to an end or a more permanent standard is kind of missing the point that the overall callable API surface is expanding rapidly. How it's called by the agent is an implementation detail.

> 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.

Its absolutely hilarious to me how tech people keep imagining that "this time it will be different".

This has been done 100 times before, it's COM, it's the remote Java object marketplace, it's the semantic web.

You are imaging a world where businesses are OK being marginalized into a nameless, faceless api provider with no control over their product. This will never happen. You might get a couple of years while they chase investment frenzy, but it will fragment. They will lock you out of their services. They will interact directly with their customers.

Mcp is not dead says the guy who gets paid half a million to work on it.

News at 11.

> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server.

Didn’t ~every company also jump on blockchain and NFTs?

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.

What is so very strange is that MCP is what we have always wanted, for ourselves!

Haven’t we devs always dreamt of a common interface to query and introspect foreign APIs? Aren’t we lucky we stumbled into an “AI” that is founded upon human language and not some incomprehensible machine code? It seems to me LLMs only made the need for such a universality attractive. Such as so many circumstances where we will do things for our progeny which we would not (yet should have) done for ourselves !

I’ve felt the same thing about skills files, the first things juniors or onboarders should read to explicitly understand their own jobs!

> 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.

As in: if your models and agents were as good as you claim them to be, we wouldn't need to re-implement half if our tools and a significant chunk of the web to conform to this vibe designed protocol.

In 99% of cases your AI agents already have all the access. They are just too stupid to do so.

MCP is not an answer to the lack of a CLI or API.

Hank Hill: "Excuse me, are y'all with the cult?"

Jane #2: "We're not a cult. We're an organization that promotes love and—"

Hank Hill: "Yeah, this is it."

What do you think about MCP security being limited as it is. Frankly, it seems mathematically impossible.

Have you heard of the Ask Protocol? (https://abject.world/ask-protocol/).

I might be biased because I came up with it, but we are over complicating these systems. There is a simpler way, and it appears to work well since I built a system using it to test the idea.

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

> practically ~every company on the planet is building an MCP server

I work at Taco Bell. Every company on earth is working on Doritos Locos Tacos. I know this because I interact with every company on the planet, and they all tell me that Doritos Locos is in their development pipeline. When I see all of these “not everybody eats or wants Doritos Locos” posts I know that they are wrong because the appeal of them is universal, especially when paired with Baja Blast, mankind’s foremost favorite fluid

Maybe MCP doesn't have to be the entire or only solution, or judged as such, and another tool in the toolkit.

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