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.
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...
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?
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 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.
This is also my point of confusion. People in the comments seem to be saying that MCP is necessary due to discoverability, but I fundamentally fail to understand how a protocol can make interfaces discoverable to an LLM in a way that wouldn't also be achieved by making traditional interfaces more discoverable to a human. These things mimic human behaviour after all.
Surely people aren't saying we haven't solved API discoverability by now and need new tech for 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.
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.
Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke.
People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the weights. If I make a new CLI tool I still need to somehow teach the AI to use it. If one wants the 'teaching' part comes from a server then MCP. If one wants it local and static then skills. How could there be so many debates around these simple concepts?
Agreed, MCP works and it works well. Often I’ll wrap an API in an MCP because getting the agent to interact with an API just wastes tokens with it trailing things back and forth; MCPs just work.
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 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.
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?
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.
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.
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
> 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 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.
If you don’t know how to keep your openapi spec up to date then yes you’ll struggle with keeping an MCP up to date. At the end of the day, keeping APIs in sync with SDKs, documentation, MCPs is a solved problem through automation. It’s not hard.
> 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
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.
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.
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 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.
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.
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.
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).
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).
> 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.
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!
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.
> 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.
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.
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.
So because people are doing it, it's the right thing to keep? There is a long way to go before we know the shape of the real solution. Don't let things like MCP slow down the exploration
Oh man - hearing that we’re building MCP’s where there is no CLI makes me super nervous.
It’s one thing to dupe the functionality of your CLI for better agent integration. It’s another to make it the sole method of interface locking everyone into a spec that we may decide we can do better at some point. Then we gotta pay off all the MCP debt and it will be cheaper to just not.
Wouldn't it be easier if MCP supported vector embeddings as input/output? It would shift its integration from a Broker Agent to a Deterministic Semantic Router. That by itself would prevent context bloat.
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.
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.
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
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.
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.
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.
174 comments
[ 2.6 ms ] story [ 97.1 ms ] threadi personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
> 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)
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.
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.
What do you mean? Tool is a pretty generic concept.
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.
Surely people aren't saying we haven't solved API discoverability by now and need new tech for it.
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.
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.
People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the weights. If I make a new CLI tool I still need to somehow teach the AI to use it. If one wants the 'teaching' part comes from a server then MCP. If one wants it local and static then skills. How could there be so many debates around these simple concepts?
Not being facetious, but why not:
"If one wants the 'teaching' part comes from a server then OpenAPI specs. If one wants it local and static then man page."
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.
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.
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.
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?
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.
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...
[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
Wow if that's not an echo-chamber comment I don't know what is.
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.
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
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.
I find a lot of HN content seems to be doomer farming
i was a big skeptic of MCPs
now i build em
Right now you have to create an MCP but v1s are always easier to maintain than v10.
We're speed running a trap.
Jane #2: "We're not a cult. We're an organization that promotes love and—"
Hank Hill: "Yeah, this is it."
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?
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.
"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.
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.
> 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.
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.
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!
News at 11.
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.
Didn’t ~every company also jump on blockchain and NFTs?
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.
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.
"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.
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.
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.
It’s one thing to dupe the functionality of your CLI for better agent integration. It’s another to make it the sole method of interface locking everyone into a spec that we may decide we can do better at some point. Then we gotta pay off all the MCP debt and it will be cheaper to just not.
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.
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
* 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.
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.
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
Until that happy day arrives I run every required MCP with mcpc.
[1] https://github.com/apify/mcpc