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.
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.
MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.
It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.
MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban
It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
I have some hope that this'll all lead to a revival of semantic web / microformats / etc. Why write an API when you can just add some markup to your existing API, which already looks like stuff that it was trained on, and won't fall out of sync (because you use it too)?
I definitely see it going that way from a marketing perspective if you want what you send/produce to be machine readable and actually used in intermediated surfaces like email and web search.
> I have some hope that this'll all lead to a revival of semantic web / microformats / etc
Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get.
Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better.
To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it.
It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained.
That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.
Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs?
The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.
It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable.
I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.
Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?
You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work.
It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
What we really should have is an aligned discovery protocol and a generic globally used sdk which handles negotiation.
You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it.
Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
I haven't found this to be the case. I tried to make `acli` work, with CLAUDE.md fine saving the things Claude learns about how to use the API (eg which custom variables to include and so on), but in the end found the MCP to work better. I think I had trouble getting the CLI to update a certain custom field, which the MCP was able to do. Not to mention, I don't think `acli` even works with Confluence?
That’s only true for the frontier. The moment you start looking at enterprise consumers of AI you’ll see slow monoliths that make decisions by committee and those committees often don’t even understand the tech they’re passing ruling on.
And you’ll also often see CISO-offices that are managed by checklists and yet more committees.
Asking for MCP access is generally easier than asking for an API for several reasons:
1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)
2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.
3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.
In short: Enterprises are a very different beast to your average business.
Here is my vision: the future of AI is about truly understanding the real world. The world around us.
Not everything in the real world will expose an MCP server so AI can interact with it.
Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments.
MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination.
> 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.
The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste
> 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.
Updating MCP by AI is one time effort.
Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison
It's not question of "model limitation" but of cost effectiveness.
> 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.
My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?
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.
Yeah it was quite weird seeing "Many of these companies don't even have an external API!" given MCP is literally a protocol for an external API. Not a good one in my opinion but it indeed has mindshare.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:
* Internal services that never had real APIs are getting them retrofitted via the MCP layer
* MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions
The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.
The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.
MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:
> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.
I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.
So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.
Corporate automations face the same problems human driven agents use:
+ The 'tool' section of the chat is not the right place, and it's too limiting
+ The very concept of MCP server introduces a brittle layer - for what purpose?
CLI for local calls, REST for remote.
That's it.
We build security around that the same way we would otherwise.
Now -> 'better / standard' json type calling for both of those!
Sure! 'Agent Calling API' or something. Yes.
'Agentic Identity Standard'? Yes to that as well.
But MCP was 'the right solution for a period in LLMs that has been superceded.
If MCP did not exist today - we would not invent it. That's the strongest argument I think.
I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.
It was always about tricking people into thinking there was authentic interest in it and it still is.
> 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.
> Wow if that's not an echo-chamber comment I don't know what is.
Wouldn’t expect anything less from someone working as a manager at OpenAI. I don’t think their org culture is survivable if you’re not 200% all-in on LLMs eating the universe.
It’s definitely an outlandish statement to make. There’s 200-400mn companies in the world on a conservative estimate. I assume the poster means something like “all listed companies”.
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 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.
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?
One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.
mostly, but not enough — i have been experimenting with this, and what i found to help is:
- help menu is the default, not an error message to stderr. ex: `gh pr` and `gh pr --help` are byte identical
- if the subcommand, or the options passed are wrong, present suggestions. ex: `gh gists` -> "Did you meant this? gist"
- the help menu should provide examples like `tldr`. sprites.dev tool `sprite` does this well, `gh` is in the training set so theirs is shorter
- can you append the docs url to the bottom of the help menu?
- you're serving llms.txt, right?
MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two.
Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.
MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.
this is bad. Anyone doing any cursory work with agents will realize how brittle <<just managing your own prompts>> can be. Adding an extra layer of indirection isn’t helpful, it’s a gigantic hindrance that gives you a moving eval target. Being an MCP developer means you have a moving target of model optimization. It is a win for nobody.
The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a better integration point than MCP.
That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work.
An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.
I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.
I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.
I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.
> jsonschema, openapi, all of it is a better integration point than MCP.
MCP is schema + interaction model. If MCP were built on OpenAPI, it would still need another layer to describe interaction. It is effectively JSON schema + interaction flow + standard surface area.
Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.
You’re not talking about how teams and enterprises work, you’re talking about how teams and enterprises don’t work.
Teams and enterprises had problems maintaining API keys long before there was MCP and they will have the same problems afterwards. The better teams and enterprises have had solutions for a long time.
Sure. It would be great if they were portable as well.
To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.
If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.
MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.
Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?
Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification.
You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.
But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.
Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant fine-grained OS-level permissions to add such things back, except perhaps `sudo` and similar tools.
MCPs are impossible to combine this way: everything you feed or get from them goes though the model and consumes tokens.
You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools.
Remember: jq can always be a tool (MCP or otherwise). In this way you can allowlist specific CLI programs and give them to the agent via tools. Making python a tool is more difficult; that would have all of the same RCE injection issues that the shell would have.
There are isolation stacks that help make “running an agent with a shell on behalf of a customer in the cloud” possible. It’s just very risky. There’s a thousand attack vectors, and to a very real degree companies that are getting to this point are re-thinking their cloud infrastructure and architecture from first principals.
jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data.
I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files. Maybe even Python if it can be made safe. If not, then there are a lot of languages can be.
Can an MCP provide prompts for your model to download and use CLIs (and ensure they have the right versions of those tools) in such a way that the data flows through the client side tools?
The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps.
However MCPs couples with a client willing to run tools locally can provide the best of both worlds
As far as I know, the only way an MCP can provide you data that doesn't go into the context is by providing URLs to the data, and then the model uses e.g. curl to access that data for data manipulation purposes. You could also return result set ids and provide accessors to such data, but ultimately you'd need to provide powerful accessors to that result set to avoid polluting context. Things like shell with all its power already provides.
It seems like there's little point in MCP in that case. Maybe more point if it was a standard mechanism for MCP to provide additional data, in a completely compatible fashion with all other tools? You could perhaps even pass such URLs to other MCPs. You could have an MCP for jq for doing stream processing. Starts to look a lot like a shell, though.
Seems like MCPs could also be extended to store auxiliary data to your memory (or filesystem..), and then an additional extension to provide that kind of data as auxiliary data in the calls to MCP.
Well, even as is, MCP still provides a standard method of using OAuth for accessing such services. And you must use MCP if you wish to add something to the ChatGPT.com web service, so it's easy to see why OpenAI folks are seeing companies going that way.
Hmm, indeed, so maybe I could have all this as an MCP, so I can just easily pass any imaginable data manipulation inside it, and then also have it support calling other MCPs, all inside that one MCP, to avoid filling context with intermediate data..
You prevent the LLM from deleting your instances by not granting its AWS user that permission. Whatever tool you let it use to talk to AWS is irrelevant.
Is that so surprising? I thought that was a given. And as soon as remote resources are involved, the old "it's in a docker" peace of mind does not apply.
Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.
and many more that offer both, but support their MCP more.
Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.
There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.
A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.
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.
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.
This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.
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.
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).
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).
Create a skill that has the CLI in the scripts sub-directory. The implementation language depends on the LLM and the VM it uses. Claude includes shell, python, and a bunch of other interpreters in a Linux environment.
A skill's instructions can direct the LLM to call the CLI.
Claude skills can be installed into Claude web from a web browser. Those skills can then run on the Claude app on your phone.
Ok, I can see there's a new (to me) Customize section where you can install skills. You have been able to connect MCP servers for quite a while.
The UX here isn't great, but let's assume it can be improved. How would auth work with this alternative method? I want to connect to Puma store and that's done using a skill with a CLI. Can the CLI launch your web browser to do oauth from the skill (on a phone)? And then the credentials are saved where?
Not challenging you, I'm open to alternatives to MCP for sure. But MCP seems way more mature especially for non-programming use-cases.
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.
No OP, but MCP really is just a logical next step once you've got an API.
The API is the "low level" protocol, the MCP is the high level one, suited perfectly to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).
With just an API, the agent needs to "read your API docs" to know how to call it (that can be an OpenAPI spec or even just text).
With MCP, the agent sees a bunch of tools it can call, and they've been trained to call tools so they nail it.
One more very important factor is authorization, which no one seems to mention in these discussions. CLIs were made for humans and use primitive mechanisms for authorization: either an API key you hardcode in your environment, or they literally run a background HTTP Server to get a callback OAuth call to receive a token from a browser authentication flow. Incredible that people are happy with that, appparently. With the MCP Authorization spec, you solve authorization across multiple MCP servers in the same standardized way, the LLM client you use just need to know the protocol, not how to login for every single MCP server.
Very importantly, if the MCP client does the authorization, the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise! People think it's ok to let an LLM act on behalf of the human but that will eventually bite a lot of people. Did the LLM just try to hack the API while you were mindlessly clicking "yes" when it asked if you wanted to let it do something? Tough luck, there's no way to distinguish an LLM making a mistake from a human maliciously running some attack.
And as the post mentions, there's also more benefits like being able to "elicit" user input (not just request/response cycles) and the ability to have documentation and assets (skills also have this though).
This is a great example of the AI-hype-induced reply.
> to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).
"Tools" is literally an API call
> With MCP, the agent sees a bunch of tools it can call,
Yes, the agent first calls a specific API that returns the schema for that particular server. It's literally the same.
> One more very important factor is authorization, which no one seems to mention in these discussions.
Yes, API calls to services are often gated behind auth. OAuth that MCP uses is from 2006, and its version 2 is from 2012. What do you think it was created for?
> the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise
We had "differentiate these two accounts and audit log their activity" probably since the 1950s
> there's also more benefits like being able to "elicit" user input
Two-way communication is also a thing since the 1950s, probably.
If you think tool call and letting the LLM call an API via curl are the same thing, you haven’t a clue how LLMs work and honestly shouldn’t be commenting on the topic at all.
It was obvious hyperbole. I can believe that there are many companies where the boss heard about MCP and put it on a roadmap before anthropic decided that it wasn’t a good idea… and now the team is implementing this in the name of “we need to do some AI”
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.
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!
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.
This is not even 'basic product design' - it's just 'product common sense'.
That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.
They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.
If they don't do that, all the money in the world and all the best product people wouldn't be able to help.
I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?
> 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.
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 think the comparison to TCP/DNS/BGP is the more apt one compared to MCP/A2A
- Those protocols negotiate capabilities and exchange information about themselves, but not in a self-serving manner of just talking about themselves, but with the goal of ultimately transporting data for a higher layer. Ask Protocol lacks that.
- Objects don't exist in a vacuum, but in a context. As the objects will only know about themselves they will always be limited in how to describe themselves best. An LLM that lives on the outside and just gets a static description of an object will be in a much better description to answer an "ask" query.
- Given that the existing agent protocols you are putting it in a context in already come with "description" fields and the like, the protocol seems too little of a value add to actually target. e.g. there is no benefit for a MCP server to conform to the prescribed manifest rather than implementing a freeform "ask" tool.
- If you want to actually bring the point across that it "occupies a different position" than transport/agent protocols, don't put it into a comparison matrix where you force it into the same schema
> 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
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
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?
My take is that most of the AI related posts are written by AI under instruction of people who hype it up but have no idea about how any of it works.
It all has some form of "the thing I'm doing is the future and everyone who doesn't join me will fall behind" energy that AI/NFT/blockchain/web3/etc. enthusiasts talk about when they're trying to sell you something or when they're trying to convince the world they really are the big money makers they claim to be.
The LLM isn't going to care about where the tokens it's inserting into the context window are coming from. For all it cares the data it's processing came in over fax and was read in with OCR.
i feel exactly the same its literally the only api standard that we truly made plug and play and even automatically oauth antenticathable with dcr and people are falling over it. also in an absolute record speed thousands of mcps.
cli’s also need to be documented and input/output typed.
its also extremly dsitributable by just pointing to an url.
cli’s are great because they are composable but i really got huge mileage out of mcps
Paradoxically, I've seen new CLI tools take on usage patterns from existing ones because of the idea of user familiarity. Even if the existing pattern sucked. I could see the same thing happening now under the idea that "the LLM already knows how to use X, so we should make our tool work like X"
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.
You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.
Yes, MCP taking the form of 'skill' because MCP serves no purpose.
The concept of 'mcp server' is a brittle abstraction that need not exist.
A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.
You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.
Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command.
> Problem 2: Low Operational Reliability
If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol.
> Problem 3: Overlaps with Existing CLI/API
Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP?
But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean).
> Provide CLI -> API -> docs, in that order
Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.
> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something?
I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed.
And I guess you can put some usage examples into the skill file. Which might migate the first --help.
Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?
Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.
I like MCP, but most servers and harnesses just dump all of the tools into context each message. Also the default tutorials for everything around MCP say to dump tools this way.
It’s really hard to determine which tools an agent will need on the fly. The best idea I’ve seen was to do a “search tools” tool which an agent would use to find relevant tools, then have an “execute tool” tool which did what it says.
Alternatively, if you’re using an agent that’s good with code, give it something like “port of context” (pctx) which translates MCP tools into a JavaScript package so the agent can chain MCP tools together with code, and they can filter the data down to just what they need. I haven’t used this method much yet but soon I need to improve the MCP gateway in our cloud agent builder product so I’m going to try this one out soon myself.
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.
I think that what they mean is that instead of ten perfectly orthogonal "unix philosophy" tools (skills) for the agent to compose when solving a problem, each with an API surface (description text) the size of Texas, you'd want to can each composition in a shell script (or a bespoke rust binary, if you enjoy watching your bot perform some heavy lifting) that only solves one problem but solves it so focused that the accompanying skill description barely consumes more context than the tool's self descriptive name.
I still didn't follow, you mean to pipe things between tool calls? Like if you want to query something and then update another without the intermediate getting brought in context?
Instead of requiring each session to understand the n tools used to solve a particular problem, you bundle up the solution in a conventional script (that's what I meant by "can", as in canning) that the agent can use with very little documentation in the context. When the model is smart enough to figure out the composition of underlying tools during regular execution, it will also be able to do the canning up as a script and write the lightweight documentation that turns the script into a skill. Subsequent use will only require that lightweight documentation in context.
And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.
To do it client-side:
1. Define a single tool, tool_search
2. List the names of your deferred tools in context (or tool_search's description)
3. When tool_search is called, match the query against the tool names (or names + descriptions)
4. Append the matched tool def to the context in a new <system>-esque tag
Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.
Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools.
Crazy that the company that invented MCP is not putting basic features like this in the product.
Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.
Also the calling of the Mcp is nicer in the chat UI, clearer for users.
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...
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.
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..
- remote mcps are server driven, meaning the producer can introduce new functionality without requiring all clients to update their skills and clis
- remote mcps are safe as they don't require literal code execution privileges on your system. Many times skills even bundle scripts with `npx`/`uvx` which is basically just `curl npm.com | bash` level of unsafe
Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH.
SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (through public keys), streaming output, interactive I/O, even file transfers (through scp / rsync) if that's something you want.
If your users link their accounts to Github or GitLab, you can even scrape their ssh keys and pre-configure authentication for them, so they just connect and they're in.
And I know I will forget again. "Model Context Protocol" is so bland I already forgot half of it by the time I'm at the third word, so that even some old Amiga stuff instantly overrides it.
> You sit down and 10 menus (MCP tool definitions) are spread across the table
> There's no room left for actual food (your work)
> Every time you order, the menus have to be pulled out again
This is a bad analogy. Ordering repeatedly is uncommon except for tapas restaurants. You could easily put food on top of menus, but more commonly, menus are removed after ordering, thereby freeing the table (context??) for the food. If you're going to try to explain things by analogy, it's worth putting effort into making it more relevant.
>> MCP consumes ~65x more tokens than the CLI approach.
For this example, there seems to be no explanation for the LLM to know when to use this curl command, etc. Is the idea that the linear API is known in the LLM weights already and therefore there is no need to include "the manual" in the context window? If so, it's a pretty narrow win.
> 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.
Because Claude Code only loads the tools it needs now, so context bloat is pretty much solved for MCPs.
"We've done extensive renovations in our apartment and while the coring drill was essential to install electrical conduits it's pretty useless in making furniture installations".
In the world of AI development we are jumping from tech to tech every 20 minutes. I'm in shivers every time when I see "A new claude version was released, do you want to update now?"
The moment you kinda automate something with the AI, the process breaks and you have to build the new thing.
Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have agents without it.
The problems listed on the article are problems with specific tools that have large tool descriptions. This has nothing to do with MCP. There is nothing in MCP that would cause the tool descriptions to use more context than they would otherwise.
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.
You can have your IT department configure an MCP for the org, and your regular non-technical users click a button and login with their account the service. Then they get all the tool calls authenticated as themselves.
The AI probably can figure out. However, Claude Code and other tools are built to support MCP. This means MCP is probably more reliable than using REST API + llms.txt.
MCP is an API with some description. It adds tools to your agent, along with some context.
The (common) complaint is that the principle of progressive disclosure isn't working because all tools, with all their descriptions, are loaded into context right at the start. This is a somewhat reasonable complaint, as the structure makes it hard for the harness to progressively disclose the tools.
This is a fundamental issue with anything that just adds a bunch of tools, whether it be via MCP or HTTP (still sad that MCP won over OpenAI's HTTP based approach).
How might it be solved? Well, we could work with sets of tools. That's pretty much what the CLI approach does: Wait until you need it, then invoke the help command to discover what to do exactly. The caveat of the CLI being that it's a nightmare to secure.
At the end of the day, every capability eats some amount of context because the LLM needs to know when to invoke it.
Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.
Bingo. All this agentic hype is just people discovering POCs. Yes you can hodgepodge semi-reliable solutions where you don't really know what you're trying to build so you wrap it in a layer than can sometimes approximate logic and decision making, so that you don't have to use logic or make decisions. Amazing.
Sooner or later you have to build the real thing, and the cost and slowness of token-based computation become unacceptable.
CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.
It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.
I used to compare MCP and Skill in my post (AI-assisted [1]) and also maintain a CLI/MCP/Skill for YouTube.
In my opinion, MCP is not dead. "MCP Belongs to Software Engineering", it ships existing concepts from software engineering into AI. CLI, MCP-tools, and OpenAPI are interchangeable to some degree, but MCP is more than tools; there are mcp-apps[2], lazy load in context[3].
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.
> 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.
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.
The pro-MCP arguments sound a lot like the same ones for SOAP, J2EE, "Enterprise Service Bus" and other "once-dominant, now dead in favor of dev driven simpler solutions" tech.
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
I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing.
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?
When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary.
The problem is that the agent does not care. Its primary goal is to get the job done.
Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution.
An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary.
You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D
At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result.
In practice, this is a surprisingly tricky problem. :D
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.
The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:
- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.
- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.
- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.
Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?
I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).
I prefer the skill/CLI approach, but with Claude, I have found that building skills or plugins using CLI tools or bespoke code connected to external APIs runs into a problem with what Claude allows in its locked-down sandbox, particularly in Co-Work. The only way out of the sandbox seems to be MCP, and even then, there are timeout issues.
Well, I am not sure why everything is declared dead nowadays, I am actually trying to find the thing that actually die when people claim "x" is dead. Everyone is riding the wave, and so am I tbh...but the dead thing...I mean.. invite me to the funeral then
i dont think there is anything preventing devs to filter out certain items from the tools list - security is more of a issue for how you are harnessing your agent (at code-level of course)
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)
This was one of the first ideas me and my team had for sharing skills and scripts. The problem is this is a very "why Dropbox and not FTP" answer.
The second you utter the word git, you may have lost 90% of your audience - depending on their background, of course. MCPs are a lot more non-tech friendly
yeah it 100% depends on who you'll be sharing them with, for me its just myself and a couple agents i have on a dedicated machine so git is ideal to keep versions matching when i update something on my daily driver
You can’t sell that in b2b negotiations though. You can absolutely say “and for $x per user we will grant you access to our central, closed-source MCP server that does things our CLI doesn’t do”.
right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that.
i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
for developers working in claude code, sure. but there's ai users who don't use claude code. chatGPT business and enterprise tiers integrate with MCP servers controlled by your organization admin.
We have b2b enterprise solutions for sharing text files; we have 1st party, security approved methods for distributing source code that are fundamentally business friendly and compatible with using skills.
MCP might have a place, but claiming it exists because you need a more “enterprise” solution to distributing prompts is just enormously difficult to justify.
(Unless, as the other peer comment indicates, you're not actually trying to make things better or useful, you're trying to sell access to your MCP server. I admit, I take it back; if shilling your company is all you care about maybe MCP is a better option)
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.
A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?
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.
I just don't see how she missed in her example that the post to linear graphql endpoint needs the model to load the graphql definitions, there's no way it's 65x the tokens. Whatever overage it actually is, it's well worth not having to muck around with graphql.
> 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.
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?
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.
Most of the internet is clickbait for a long while now.
No one would read a title like "MCP and CLI can both be usefull in certain scenarios. Ask your AI and he'll tell ya" :)
The idea that MCP tool definitions take up a certain number of tokens is laughable. That's an implementation detail of the agent harness. MCP is just an API specification. Hell, there's nothing in it that makes it much of any different than OpenAPI, except that its a bit more local-dev focused. There's a thousand things harnesses can and do do to optimize MCP beyond just "spit out the raw MCP output into the context window and pray".
MCP will die for the same reason RAG died and why prompt engineering is dying. The models get better at understanding what you want and where to find the right tool or context to solve the problem on their own.
MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
When agents don’t encrypt secrets, MCP servers help prevent users from handing their API tokens to AI providers or intermediaries such as Cloudflare and Akamai.
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer
2) On a laptop
3) With a shell open
Inside an agentic coding harness (Claude Code, Codex CLI, Cursor)
4) Working on a software project
5) That's like... maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
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.
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...
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.
I don't know about it being dead, but i certainly stopped using it because it kills the context. A huge amount of tokens are wasted to mcp when in use. Skills use far fewer tokens. From my experience anyway. I'm also not advanced enough so maybe I'm not using it right.
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 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.
MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.
It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.
Can you not just install/ restrict the available CLIs in the same way you do with MCPs?
Or what else am I missing about why MCP is more secure than a CLI?
MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
You can easily do this with simple Unix `chmod x-rw` on a wrapper that makes HTTP requests, adding the access token as it does.
Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Just use scopes in the API key the agent uses? If you’re exposing something publicly that should be a requirement anyways.
That’s how I use gh, aws, etc. No need to modify any of the code in the cli, they’re just wrappers.
I want the harness to use read freely but require confirmation for write.
Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
How do you ensure the cli can use the auth without knowing how to read it ? It’s potentially a bearer Token
I think that’s exactly right: MCP provides a capability security model for agents.
How in the world MCP is going to be more secure? It introduce a big surface layers for injection attacks and supply chain attacks..
To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban
rm -rf ~
but sandboxing in general is not an easy problem.
It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
Totally agree, MCP is the WAP equivalent of mobile internet access.
Have you used MCP, at the protocol level?
WAP was dumb and failed because it oversimplified the web, and phones evolved to be real computers.
MCP is more sophisticated than typical APIs. It adds organization, policy, and code vs data (prompts) partitioning.
IMO it’s more likely that non-LLM apps will start using MCP than it is for MCP to go the way of WAP.
I'm old enough to get this reference! Spent years writing WAP... it was really great at the time.
It blew my mind as a kid
I was maybe 10/11 when the Nokia 3330 came out, and being able to use the internet while not in front of a computer just felt like magic
Those were the days of the dotcom era when finding the next restaurant with your Nokia + WAP was THE killer use case.
I have some hope that this'll all lead to a revival of semantic web / microformats / etc. Why write an API when you can just add some markup to your existing API, which already looks like stuff that it was trained on, and won't fall out of sync (because you use it too)?
I definitely see it going that way from a marketing perspective if you want what you send/produce to be machine readable and actually used in intermediated surfaces like email and web search.
> I have some hope that this'll all lead to a revival of semantic web / microformats / etc
Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
Different levels.
Yes, MCP is a hack that could have been carefully built on prior art, and it would have been better for it.
Yes, MCP is capable of expressing that prior art, and you can do semantic web concepts even if the wire protocol looks different.
That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get.
Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better.
To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it.
It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained.
That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.
Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs?
The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
But then there is the other side that companies are adding MCP servers to stuff that has never had a public API.
They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.
MCP is a higher layer than your existing API.
It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable.
I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.
Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?
You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work.
It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
What we really should have is an aligned discovery protocol and a generic globally used sdk which handles negotiation.
You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it.
Why don't we have this? Right because of people.
Its always people problem.
MCP is now here, it might stay.
I usually just generate the MCP server spec from existing openapi/swagger spec, maybe with a filter to omit certain endpoints and so on.
> AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use).
Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.
Authorisation is a way to do that, too.
Yes, but you often do not have much control over that.
For example try giving a local LLM read access to specific folders in your email account
Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
Theoretically you should be creating a "read email" CLI tool and letting agents interact with it in a chroot sandbox.
LLMs are much more proficient with bash and --help than they are with bespoke API protocols.
Treat LLMs like you would a junior programmer - keep things as generic and obvious as you can.
> temporary workaround
I've heard this one before
(Maybe it'll be the first time that a temporary workaround stays around longer than expected then)
Funny thing is that Claude knows the api of Atlassian better than the mcp they provide. Mcp is limited it doesn't have all api calls described.
I haven't found this to be the case. I tried to make `acli` work, with CLAUDE.md fine saving the things Claude learns about how to use the API (eg which custom variables to include and so on), but in the end found the MCP to work better. I think I had trouble getting the CLI to update a certain custom field, which the MCP was able to do. Not to mention, I don't think `acli` even works with Confluence?
Is this not just a tooling problem?
As someone who supports Atlassian products; Atlassian is a tooling problem.
Yeah, having two tools when you only need one is a problem. Like one is always going to be full phat and the other will ride the back of the bus.
That’s only true for the frontier. The moment you start looking at enterprise consumers of AI you’ll see slow monoliths that make decisions by committee and those committees often don’t even understand the tech they’re passing ruling on.
And you’ll also often see CISO-offices that are managed by checklists and yet more committees.
Asking for MCP access is generally easier than asking for an API for several reasons:
1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)
2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.
3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.
In short: Enterprises are a very different beast to your average business.
Here is my vision: the future of AI is about truly understanding the real world. The world around us.
Not everything in the real world will expose an MCP server so AI can interact with it.
Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments.
MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination.
I give it max 3 to 6 years and it will just die.
Explains a lot.
Totally agree with you.
> 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.
The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste
> 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.
Updating MCP by AI is one time effort.
Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison
It's not question of "model limitation" but of cost effectiveness.
You can build a MCP server in minutes these days to connect to a REST API. The friction is close to zero.
> 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.
My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?
That wouldn't solve the core issue: if Claude makes a mistake during the MCP generaration, it would poison further agentic use.
It's adding another failure point to the process for no gain.
No, because as everything which is a part of a release process, you'd have tests.
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.
Yeah it was quite weird seeing "Many of these companies don't even have an external API!" given MCP is literally a protocol for an external API. Not a good one in my opinion but it indeed has mindshare.
Yes. But that's dangerous for end users. It enables lock in. All it does is context management, so skills are much better choice
"and the one they're using." no it's not.
Agents are just making REST calls and that's it.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
It could very well entrench itself however.
It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.
I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:
The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.
MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:
> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.
I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.
So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.
Corporate automations face the same problems human driven agents use:
+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?
CLI for local calls, REST for remote.
That's it.
We build security around that the same way we would otherwise.
Now -> 'better / standard' json type calling for both of those!
Sure! 'Agent Calling API' or something. Yes.
'Agentic Identity Standard'? Yes to that as well.
But MCP was 'the right solution for a period in LLMs that has been superceded.
If MCP did not exist today - we would not invent it. That's the strongest argument I think.
That mimetic thing…
I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.
It was always about tricking people into thinking there was authentic interest in it and it still is.
I suggest you implement an MCP server before adopting this as a firm technical opinion.
The opinion that more companies creating APIs is good?
> 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.
> Wow if that's not an echo-chamber comment I don't know what is.
Wouldn’t expect anything less from someone working as a manager at OpenAI. I don’t think their org culture is survivable if you’re not 200% all-in on LLMs eating the universe.
Yup agreed, this reads like massive coping...
Trying to imagine my boss telling me that I’ve talked to everyone on earth in a convincing way and can’t stop laughing
Like imagine somebody saying “you’re the most handsomest boy in the world” and thinking “Shit, nobody would just make something like that up.”
The comment just reads to me as:
"Person working on MCP tools says MCP is not dead."
Or, "Person who sells tokens responds to article claiming MCP spends too many tokens says please keep buying tokens."
Yeah this is copium. Everyone is sprinting to adopt everything that is useful, and it just haven't happened with MCP.
Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?
It’s definitely an outlandish statement to make. There’s 200-400mn companies in the world on a conservative estimate. I assume the poster means something like “all listed companies”.
Resist the urge to nitpick and accept that the poster simply means "a large number of high-profile companies".
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 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.
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?
One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.
Isn’t that basically just a —help flag though?
Still easily doable with CLI
> Isn’t that basically just a --help flag though?
mostly, but not enough — i have been experimenting with this, and what i found to help is:
Then give the CLI a man page.
> One advantage is the MCP advertises itself to the agent with its schema and api shape.
So, OpenAPI/Swagger for REST? GraphQL? SOAP schemas? All of these (and more) exist. What does MCP add that these don't have?
i mean you can surface an openapi schema too.
MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two.
Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.
MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.
[0] https://modelcontextprotocol.info/docs/concepts/prompts/
[1] https://modelcontextprotocol.info/docs/concepts/resources/
[2] https://modelcontextprotocol.io/specification/2025-11-25/cli...
[3] https://modelcontextprotocol.io/specification/2025-11-25/ser...
this is bad. Anyone doing any cursory work with agents will realize how brittle <<just managing your own prompts>> can be. Adding an extra layer of indirection isn’t helpful, it’s a gigantic hindrance that gives you a moving eval target. Being an MCP developer means you have a moving target of model optimization. It is a win for nobody.
The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a better integration point than MCP.
That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work.
An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.
I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.
I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.
I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.
MCP is schema + interaction model. If MCP were built on OpenAPI, it would still need another layer to describe interaction. It is effectively JSON schema + interaction flow + standard surface area.Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.
You’re not talking about how teams and enterprises work, you’re talking about how teams and enterprises don’t work.
Teams and enterprises had problems maintaining API keys long before there was MCP and they will have the same problems afterwards. The better teams and enterprises have had solutions for a long time.
It keeps people employed, yes?
And with people I guess I might actually mean not people but tokens everybody has to spend on keeping their environment self-adapting...
can these not be surfaced in an api and accessed using curl, with instructions in a SKILLS.md?
Sure. It would be great if they were portable as well.
To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.
If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.
MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.
Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?
Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification.
You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.
But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.
Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant fine-grained OS-level permissions to add such things back, except perhaps `sudo` and similar tools.
MCPs are impossible to combine this way: everything you feed or get from them goes though the model and consumes tokens.
You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools.
Remember: jq can always be a tool (MCP or otherwise). In this way you can allowlist specific CLI programs and give them to the agent via tools. Making python a tool is more difficult; that would have all of the same RCE injection issues that the shell would have.
There are isolation stacks that help make “running an agent with a shell on behalf of a customer in the cloud” possible. It’s just very risky. There’s a thousand attack vectors, and to a very real degree companies that are getting to this point are re-thinking their cloud infrastructure and architecture from first principals.
jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data.
I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files. Maybe even Python if it can be made safe. If not, then there are a lot of languages can be.
Can an MCP provide prompts for your model to download and use CLIs (and ensure they have the right versions of those tools) in such a way that the data flows through the client side tools?
The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps.
However MCPs couples with a client willing to run tools locally can provide the best of both worlds
As far as I know, the only way an MCP can provide you data that doesn't go into the context is by providing URLs to the data, and then the model uses e.g. curl to access that data for data manipulation purposes. You could also return result set ids and provide accessors to such data, but ultimately you'd need to provide powerful accessors to that result set to avoid polluting context. Things like shell with all its power already provides.
It seems like there's little point in MCP in that case. Maybe more point if it was a standard mechanism for MCP to provide additional data, in a completely compatible fashion with all other tools? You could perhaps even pass such URLs to other MCPs. You could have an MCP for jq for doing stream processing. Starts to look a lot like a shell, though.
Seems like MCPs could also be extended to store auxiliary data to your memory (or filesystem..), and then an additional extension to provide that kind of data as auxiliary data in the calls to MCP.
Well, even as is, MCP still provides a standard method of using OAuth for accessing such services. And you must use MCP if you wish to add something to the ChatGPT.com web service, so it's easy to see why OpenAI folks are seeing companies going that way.
>to manipulate or combine the data into a more useful format
why not build this directly into MCPs?
Hmm, indeed, so maybe I could have all this as an MCP, so I can just easily pass any imaginable data manipulation inside it, and then also have it support calling other MCPs, all inside that one MCP, to avoid filling context with intermediate data..
Sounds a lot like a shell to me.
You prevent the LLM from deleting your instances by not granting its AWS user that permission. Whatever tool you let it use to talk to AWS is irrelevant.
So the permissions model h is a the main advantage MCP has over CLIs?
Is that so surprising? I thought that was a given. And as soon as remote resources are involved, the old "it's in a docker" peace of mind does not apply.
Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
> The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution.
Is this an advantage? Phrased differently, every MCP that could have been a CLI call is a new opportunity for sandbox escape.
I don’t follow. It’s the other way around. Would you rather run an arbitrary binary blob (aka: a random cli) or `curl`?
Edit: Maybe to clarify, I’m talking about remote MCP. Local MCP is obviously nonsensical. Remote MCP is very much thriving aggressively.
The security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code.
They have different tradeoffs.
You nailed it! There are established tools that handle the security model. MCP is the 5th leg.
I have a couple MCP servers connected to my Claude web & mobile clients. How would your clis work there?
Yes they would be.
MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.
The value is that many companies like building MCP servers much more than CLIs. For whatever reason.
Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI:
and many more that offer both, but support their MCP more.Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.
There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.
A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.
That kind of code is easily portable in C or Rust or Go or Java or Python so long as it is a CLI and not GUI.
The mcp support gets more support because there is no cli.
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.
> 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.
Unless you also want humans to also interact with your tools.
That’s covered in the article: a human can modify the commands generated by the agent, or vice versa, to debug problems or transfer knowledge.
This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.
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...
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.
To the extent this is true, and it isn't with setuid binaries, it's a limitation of operating system apis.
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.
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).
GraphQL also allows the LLM to DOS your service
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).
CLIs do work on mobile when they are packaged in skills that run in an appropriate VM behind the LLM.
Claude on the web does this. The only issue is controlling network access, which could be fixed by per-skill ACLs.
Walk me through how a user installs and then uses these CLIs from their mobile phone.
Create a skill that has the CLI in the scripts sub-directory. The implementation language depends on the LLM and the VM it uses. Claude includes shell, python, and a bunch of other interpreters in a Linux environment.
A skill's instructions can direct the LLM to call the CLI.
Claude skills can be installed into Claude web from a web browser. Those skills can then run on the Claude app on your phone.
Ok, I can see there's a new (to me) Customize section where you can install skills. You have been able to connect MCP servers for quite a while.
The UX here isn't great, but let's assume it can be improved. How would auth work with this alternative method? I want to connect to Puma store and that's done using a skill with a CLI. Can the CLI launch your web browser to do oauth from the skill (on a phone)? And then the credentials are saved where?
Not challenging you, I'm open to alternatives to MCP for sure. But MCP seems way more mature especially for non-programming use-cases.
> CLIs do not run on mobile and never will
Can you clarify why the never? What's the issue with giving a phone-based AI a sandboxed file system and bash shell?
How is the user installing the CLIs? Proprietary app store for each chat app?
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
What advantage did you find in MCP vs a traditional API?
No OP, but MCP really is just a logical next step once you've got an API. The API is the "low level" protocol, the MCP is the high level one, suited perfectly to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).
With just an API, the agent needs to "read your API docs" to know how to call it (that can be an OpenAPI spec or even just text).
With MCP, the agent sees a bunch of tools it can call, and they've been trained to call tools so they nail it.
One more very important factor is authorization, which no one seems to mention in these discussions. CLIs were made for humans and use primitive mechanisms for authorization: either an API key you hardcode in your environment, or they literally run a background HTTP Server to get a callback OAuth call to receive a token from a browser authentication flow. Incredible that people are happy with that, appparently. With the MCP Authorization spec, you solve authorization across multiple MCP servers in the same standardized way, the LLM client you use just need to know the protocol, not how to login for every single MCP server.
Very importantly, if the MCP client does the authorization, the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise! People think it's ok to let an LLM act on behalf of the human but that will eventually bite a lot of people. Did the LLM just try to hack the API while you were mindlessly clicking "yes" when it asked if you wanted to let it do something? Tough luck, there's no way to distinguish an LLM making a mistake from a human maliciously running some attack.
And as the post mentions, there's also more benefits like being able to "elicit" user input (not just request/response cycles) and the ability to have documentation and assets (skills also have this though).
This is a great example of the AI-hype-induced reply.
> to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).
"Tools" is literally an API call
> With MCP, the agent sees a bunch of tools it can call,
Yes, the agent first calls a specific API that returns the schema for that particular server. It's literally the same.
> One more very important factor is authorization, which no one seems to mention in these discussions.
Yes, API calls to services are often gated behind auth. OAuth that MCP uses is from 2006, and its version 2 is from 2012. What do you think it was created for?
> the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise
We had "differentiate these two accounts and audit log their activity" probably since the 1950s
> there's also more benefits like being able to "elicit" user input
Two-way communication is also a thing since the 1950s, probably.
If you think tool call and letting the LLM call an API via curl are the same thing, you haven’t a clue how LLMs work and honestly shouldn’t be commenting on the topic at all.
sometimes I remind myself HN is reddit now except when Dang is awake
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.
It was obvious hyperbole. I can believe that there are many companies where the boss heard about MCP and put it on a roadmap before anthropic decided that it wasn’t a good idea… and now the team is implementing this in the name of “we need to do some AI”
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?
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!
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.
OpenAI should hire you.
This is not even 'basic product design' - it's just 'product common sense'.
That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.
They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.
If they don't do that, all the money in the world and all the best product people wouldn't be able to help.
I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?
I hope they improve.
> 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."
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.
Main points that came to my mind:
- I think the comparison to TCP/DNS/BGP is the more apt one compared to MCP/A2A
- Those protocols negotiate capabilities and exchange information about themselves, but not in a self-serving manner of just talking about themselves, but with the goal of ultimately transporting data for a higher layer. Ask Protocol lacks that.
- Objects don't exist in a vacuum, but in a context. As the objects will only know about themselves they will always be limited in how to describe themselves best. An LLM that lives on the outside and just gets a static description of an object will be in a much better description to answer an "ask" query.
- Given that the existing agent protocols you are putting it in a context in already come with "description" fields and the like, the protocol seems too little of a value add to actually target. e.g. there is no benefit for a MCP server to conform to the prescribed manifest rather than implementing a freeform "ask" tool.
- If you want to actually bring the point across that it "occupies a different position" than transport/agent protocols, don't put it into a comparison matrix where you force it into the same schema
- ("Open Source" doesn't count as governance)
What do you think about MCP security being limited as it is. Frankly, it seems mathematically impossible.
> 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
What’s up with case 09058169? Seems like a 5 minute fix
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
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.
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?
My take is that most of the AI related posts are written by AI under instruction of people who hype it up but have no idea about how any of it works.
It all has some form of "the thing I'm doing is the future and everyone who doesn't join me will fall behind" energy that AI/NFT/blockchain/web3/etc. enthusiasts talk about when they're trying to sell you something or when they're trying to convince the world they really are the big money makers they claim to be.
The LLM isn't going to care about where the tokens it's inserting into the context window are coming from. For all it cares the data it's processing came in over fax and was read in with OCR.
i feel exactly the same its literally the only api standard that we truly made plug and play and even automatically oauth antenticathable with dcr and people are falling over it. also in an absolute record speed thousands of mcps.
cli’s also need to be documented and input/output typed.
its also extremly dsitributable by just pointing to an url.
cli’s are great because they are composable but i really got huge mileage out of mcps
Paradoxically, I've seen new CLI tools take on usage patterns from existing ones because of the idea of user familiarity. Even if the existing pattern sucked. I could see the same thing happening now under the idea that "the LLM already knows how to use X, so we should make our tool work like X"
I can't pipe an MCP's output to jq, and I can't ask an AI to write a python script to call an MCP.
sorry both of the things you said are false, why are they stated so confidently?
because being confidently incorrect is a thing?
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.
You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.
Yes, MCP taking the form of 'skill' because MCP serves no purpose.
The concept of 'mcp server' is a brittle abstraction that need not exist.
A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.
You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.
> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something?
I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed.
And I guess you can put some usage examples into the skill file. Which might migate the first --help.
Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?
Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.
I like MCP, but most servers and harnesses just dump all of the tools into context each message. Also the default tutorials for everything around MCP say to dump tools this way.
It’s really hard to determine which tools an agent will need on the fly. The best idea I’ve seen was to do a “search tools” tool which an agent would use to find relevant tools, then have an “execute tool” tool which did what it says.
Alternatively, if you’re using an agent that’s good with code, give it something like “port of context” (pctx) which translates MCP tools into a JavaScript package so the agent can chain MCP tools together with code, and they can filter the data down to just what they need. I haven’t used this method much yet but soon I need to improve the MCP gateway in our cloud agent builder product so I’m going to try this one out soon myself.
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?
+1
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.
Build a more specific skill the for the exact workflow you want?
Skill still needs to be loaded in context, what would it change?
I think that what they mean is that instead of ten perfectly orthogonal "unix philosophy" tools (skills) for the agent to compose when solving a problem, each with an API surface (description text) the size of Texas, you'd want to can each composition in a shell script (or a bespoke rust binary, if you enjoy watching your bot perform some heavy lifting) that only solves one problem but solves it so focused that the accompanying skill description barely consumes more context than the tool's self descriptive name.
I still didn't follow, you mean to pipe things between tool calls? Like if you want to query something and then update another without the intermediate getting brought in context?
Instead of requiring each session to understand the n tools used to solve a particular problem, you bundle up the solution in a conventional script (that's what I meant by "can", as in canning) that the agent can use with very little documentation in the context. When the model is smart enough to figure out the composition of underlying tools during regular execution, it will also be able to do the canning up as a script and write the lightweight documentation that turns the script into a skill. Subsequent use will only require that lightweight documentation in context.
Older than that, as it implies GPT-4o is current.
Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.
OpenAI API also supports defer_loading https://developers.openai.com/api/docs/guides/tools-tool-sea...
And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.
To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new <system>-esque tag
Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.
Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools.
Crazy that the company that invented MCP is not putting basic features like this in the product.
I think if you deny a tool, it won't be loaded in context at all ever, even it's name and description won't be loaded.
Deferred cli/skill loading is also not part of CLIs or skills, it's all about how the coding agent/harness is implemented.
Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.
Also the calling of the Mcp is nicer in the chat UI, clearer for users.
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
But what is the advantage of MCP compared to having the agents access the API directly?
Agents are just a stream of text, they cannot access anything. Some kind of interpreter is needed that recognizes special patterns and runs real code.
Do you mean directly == raw shell access on your production server?
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.
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..
Besides points already mentioned,
- remote mcps are server driven, meaning the producer can introduce new functionality without requiring all clients to update their skills and clis
- remote mcps are safe as they don't require literal code execution privileges on your system. Many times skills even bundle scripts with `npx`/`uvx` which is basically just `curl npm.com | bash` level of unsafe
Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH.
SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (through public keys), streaming output, interactive I/O, even file transfers (through scp / rsync) if that's something you want.
If your users link their accounts to Github or GitLab, you can even scrape their ssh keys and pre-configure authentication for them, so they just connect and they're in.
Scale this across your organization
(zero value comment following)
Every time I read MCP, I think it means "master control program".
http://mcp.a1k.org/indexe.html
And I know I will forget again. "Model Context Protocol" is so bland I already forgot half of it by the time I'm at the third word, so that even some old Amiga stuff instantly overrides it.
> Restaurant analogy:
> You sit down and 10 menus (MCP tool definitions) are spread across the table
> There's no room left for actual food (your work)
> Every time you order, the menus have to be pulled out again
This is a bad analogy. Ordering repeatedly is uncommon except for tapas restaurants. You could easily put food on top of menus, but more commonly, menus are removed after ordering, thereby freeing the table (context??) for the food. If you're going to try to explain things by analogy, it's worth putting effort into making it more relevant.
>> MCP consumes ~65x more tokens than the CLI approach.
For this example, there seems to be no explanation for the LLM to know when to use this curl command, etc. Is the idea that the linear API is known in the LLM weights already and therefore there is no need to include "the manual" in the context window? If so, it's a pretty narrow win.
Not just that, but they retracted this:
> 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.
Because Claude Code only loads the tools it needs now, so context bloat is pretty much solved for MCPs.
MCP’s are fine
They are easy to implement and integrate
You can use OAuth and handle ACL easily
I love those "A coring drill is dead?" article.
"We've done extensive renovations in our apartment and while the coring drill was essential to install electrical conduits it's pretty useless in making furniture installations".
In the world of AI development we are jumping from tech to tech every 20 minutes. I'm in shivers every time when I see "A new claude version was released, do you want to update now?"
The moment you kinda automate something with the AI, the process breaks and you have to build the new thing.
So don't blame a coring drill.
Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have agents without it.
The problems listed on the article are problems with specific tools that have large tool descriptions. This has nothing to do with MCP. There is nothing in MCP that would cause the tool descriptions to use more context than they would otherwise.
You can create tools without using MCP for OpenCode: https://opencode.ai/docs/custom-tools/
i mean yeah but is just a spec
What do you mean?
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.
In that sense, MCP is very much not dead
If you need a network boundary, what MCP provides that REST API + llms.txt can't do?
OIDC? Ease of deployment in a company?
You can have your IT department configure an MCP for the org, and your regular non-technical users click a button and login with their account the service. Then they get all the tool calls authenticated as themselves.
The AI probably can figure out. However, Claude Code and other tools are built to support MCP. This means MCP is probably more reliable than using REST API + llms.txt.
Standardization. Who writes llms.txt? Everyone writes their own? Will agents still behave the same?
It's such a dumb discussion.
MCP is an API with some description. It adds tools to your agent, along with some context.
The (common) complaint is that the principle of progressive disclosure isn't working because all tools, with all their descriptions, are loaded into context right at the start. This is a somewhat reasonable complaint, as the structure makes it hard for the harness to progressively disclose the tools.
This is a fundamental issue with anything that just adds a bunch of tools, whether it be via MCP or HTTP (still sad that MCP won over OpenAI's HTTP based approach).
How might it be solved? Well, we could work with sets of tools. That's pretty much what the CLI approach does: Wait until you need it, then invoke the help command to discover what to do exactly. The caveat of the CLI being that it's a nightmare to secure.
At the end of the day, every capability eats some amount of context because the LLM needs to know when to invoke it.
Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.
Bingo. All this agentic hype is just people discovering POCs. Yes you can hodgepodge semi-reliable solutions where you don't really know what you're trying to build so you wrap it in a layer than can sometimes approximate logic and decision making, so that you don't have to use logic or make decisions. Amazing.
Sooner or later you have to build the real thing, and the cost and slowness of token-based computation become unacceptable.
Yes, and the free-for-all building of nonsense (and insecure) apps by non engineers is probably going to slow down as well.
Editorialized title is not cool, HN.
It was dead from the get go, agents need tools the do not cate about the details that much
MCP and shell/bash tool calling serve totally different use-cases, this discussion is... odd.
CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.
It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.
I used to compare MCP and Skill in my post (AI-assisted [1]) and also maintain a CLI/MCP/Skill for YouTube.
In my opinion, MCP is not dead. "MCP Belongs to Software Engineering", it ships existing concepts from software engineering into AI. CLI, MCP-tools, and OpenAPI are interchangeable to some degree, but MCP is more than tools; there are mcp-apps[2], lazy load in context[3].
[1]: https://log.ifor.dev/posts/mcp_vs_skill/
[2]: https://modelcontextprotocol.io/extensions/apps/overview
[3]: https://code.claude.com/docs/en/agent-sdk/tool-search
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.
What is special about MCP to make it any more or less fragile than any other software?
MCP is a combination of a server responding to requests, and a prompt to tell the agent how to format those requests.
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
Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/) - it circumvents all the arguments.
In the end MCP is just a protocol for discovering tools. And agents _need_ to do stuff with tools.
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 don't understand how anyone is still primarily thinking about single-user scenarios in 2026
The pro-MCP arguments sound a lot like the same ones for SOAP, J2EE, "Enterprise Service Bus" and other "once-dominant, now dead in favor of dev driven simpler solutions" tech.
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
I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing.
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?
When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary.
The problem is that the agent does not care. Its primary goal is to get the job done.
Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution.
An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary.
You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D
At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result.
In practice, this is a surprisingly tricky problem. :D
> Alternative 1: CLI-First Strategy
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.
I think mcp will become more important than ever.
2024. Oh woe, I have to scrape everything, why don't companies just give me an API to consume what I need.
2026. Oh woe, the MCP that all the companies are giving me isn't ideal.
2028? oh woe, the CLI that calls the REST API, that calls the MCP that all the companies are giving me..
The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:
- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.
- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.
- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.
Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?
I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).
I prefer the skill/CLI approach, but with Claude, I have found that building skills or plugins using CLI tools or bespoke code connected to external APIs runs into a problem with what Claude allows in its locked-down sandbox, particularly in Co-Work. The only way out of the sandbox seems to be MCP, and even then, there are timeout issues.
Well, I am not sure why everything is declared dead nowadays, I am actually trying to find the thing that actually die when people claim "x" is dead. Everyone is riding the wave, and so am I tbh...but the dead thing...I mean.. invite me to the funeral then
I think it is on the way to death because of security .
i dont think there is anything preventing devs to filter out certain items from the tools list - security is more of a issue for how you are harnessing your agent (at code-level of course)
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)
This was one of the first ideas me and my team had for sharing skills and scripts. The problem is this is a very "why Dropbox and not FTP" answer.
The second you utter the word git, you may have lost 90% of your audience - depending on their background, of course. MCPs are a lot more non-tech friendly
yeah it 100% depends on who you'll be sharing them with, for me its just myself and a couple agents i have on a dedicated machine so git is ideal to keep versions matching when i update something on my daily driver
Really? 90% of your claude code using team gets lost over git? That seems like it's own problem.
You can share a skill by copy pasting the text file to someone in slack.
Its not that hard.
You can’t sell that in b2b negotiations though. You can absolutely say “and for $x per user we will grant you access to our central, closed-source MCP server that does things our CLI doesn’t do”.
right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that.
i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
Don't most companies have a Git repo for skills that you can pull?
for developers working in claude code, sure. but there's ai users who don't use claude code. chatGPT business and enterprise tiers integrate with MCP servers controlled by your organization admin.
This is a daft argument.
We have b2b enterprise solutions for sharing text files; we have 1st party, security approved methods for distributing source code that are fundamentally business friendly and compatible with using skills.
MCP might have a place, but claiming it exists because you need a more “enterprise” solution to distributing prompts is just enormously difficult to justify.
(Unless, as the other peer comment indicates, you're not actually trying to make things better or useful, you're trying to sell access to your MCP server. I admit, I take it back; if shilling your company is all you care about maybe MCP is a better option)
Fixed with subagents.
A bit off topic, but I think Google's A2A protocol could be a sleeper hit vs. the MCP protocol.
Not because it's better, but with one switch a significant portion of web traffic can be directed to A2A servers through Google's new search box.
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.
Also MCPs for programs like Chrome Dev tools or Playwright.
There is no publishing date on the article.
IDK, in my company we are qwen code base agent with quite a few MCP's:
Jira
Confluence
Gitlab
Logs & Metrics platform (inhouse solution)
QA (not sure what this one does)
Context7
mattermost
I have no idea about modern trands etc, but I wouldn't say that MCP is dead. Not the hottest new thing, sure.
A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?
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.
> now I just write tools for agents to consume
What do you mean? Tool is a pretty generic concept.
I just don't see how she missed in her example that the post to linear graphql endpoint needs the model to load the graphql definitions, there's no way it's 65x the tokens. Whatever overage it actually is, it's well worth not having to muck around with graphql.
People who say MCPs are dead don’t understand how MCPs work or when to use them.
> 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.
Thanks for the answer! I do see both sides
We can't generalize, it depends on the case, and it's not a XOR. I personally go CLI first, and if not possible MCP.
I’m sure Unisys will still support it for decades to come.
Oh. You mean that new thing also named MCP?
What comes after CLI?
In the early days of computing, desktop apps and later webapps provided richer human experiences.
What will provide richer experiences for agents, after CLIs?
It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?
MCP is based on a lie: Machines are good at read/generate machine-parsable procotols.
Turns LLMs are shit with JSON. Especially those JSON str embeded inside another JSON key-value pairs.
Why do smart ppl design a schema like escape JSON into str embeded into another?
It's based on another lie: AIs favor static typed languages.
Meta: there is no question mark in the title of the original post.
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?
I never understand the "eats context" argument. Why do you have so many MCP enabled in the first place? Do you actually use them in every project?
So you have to manually enable/disable every MCP? What fun...
You have MCPs disabled by default but turn on the ones you need in specific projects. Set this up once per project.
I use Playwright MCP, but there is absolutely no reason I'd keep it enabled in a Go project.
mcp will consolidate, its all stdio fragile and stateless
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.
Most of the internet is clickbait for a long while now. No one would read a title like "MCP and CLI can both be usefull in certain scenarios. Ask your AI and he'll tell ya" :)
I swear something is dead every week for yall.
The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.
The idea that MCP tool definitions take up a certain number of tokens is laughable. That's an implementation detail of the agent harness. MCP is just an API specification. Hell, there's nothing in it that makes it much of any different than OpenAPI, except that its a bit more local-dev focused. There's a thousand things harnesses can and do do to optimize MCP beyond just "spit out the raw MCP output into the context window and pray".
good to hear!
MCP will die for the same reason RAG died and why prompt engineering is dying. The models get better at understanding what you want and where to find the right tool or context to solve the problem on their own.
MCP is what XML dreamed of becoming.
MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.
You should disclose that you are behind g8e.
Do I need to add a disclaimer to every one of my posts that shits on the wrong way?
When you mention your own product in a positive light, it’s customary, yes.
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
Oh forgot to mention that each CLI is basically another supply chain issue too. So there is that.
Is Betteridge's law of headlines irrelevant today?
https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines
No.
When agents don’t encrypt secrets, MCP servers help prevent users from handing their API tokens to AI providers or intermediaries such as Cloudflare and Akamai.
Do CLI enjoyers realize that MCP can be called via curl?
For example I have a no-auth clock for AI deployed from https://github.com/firasd/mcpclock to https://mcpclock.firasd.workers.dev/mcp (anyone is welcome to go ahead and add it to your AI apps as an MCP endpoint)
You can still call it via CLI if you're a MCP hater
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' event: message data: {"result":{"content":[{"type":"text","text":"[\n {\n \"timezone\": \"UTC\",\n \"iso\": \"2026-05-30T04:05:07.175Z\",\n \"unixtime\": 1780113907\n },\n {\n \"timezone\": \"Alphadec\",\n \"alphadec\": \"2026_K6G7_066464\"\n }\n]"}]},"jsonrpc":"2.0","id":1}
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/list","params":{"name":"","arguments": {}}}' 2>&1 | grep '^data:' | sed 's/^data: //'| jq -r '.result. tools[].name' clock_get clock_day_info clock_convert clock_convert_alphadec clock_convert_unixtime clock_shift_utc clock_delta_utc clock_delta_alphadec
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer 2) On a laptop 3) With a shell open Inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project 5) That's like... maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
> MCP is dead
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
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.
[1] https://github.com/apify/mcpc
Claude context window is now 1M, not 200K, which significantly weakens the first argument.
And significantly increases the price.
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...
Wait. it was alive?
MCP is dead. AI bubble. Windows is dead. Linux is dead.
The only thing worse than the people saying it are the people that repeat it.
At some point people are dead. Really.
Everyone is sort of missing the point here.
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.
No. The author is wrong. If you’re still using single model/context then it’s kinda your own fault for using things poorly.
I don't know about it being dead, but i certainly stopped using it because it kills the context. A huge amount of tokens are wasted to mcp when in use. Skills use far fewer tokens. From my experience anyway. I'm also not advanced enough so maybe I'm not using it right.