This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool.
I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.
> If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.
For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.
Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
1. Control can be done via CLIs --> api key based access controls. We have been doing it forever.
2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo.
3. This can be done via apis/clis too --> not something unique to MCP iimo
4. Same thing, not unique to MCP --> api servers can also be logged
MCP doesn't inherently make this easier. its still requires engineering maintaincence.
Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.
Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI!
MCP suffers from its harebrained choice early on to load everything into context up front.
> Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
I don't think this is a valid statement too. I'll explain why.
A MCP server represents those APIs that agents and coding assistants can call.
If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work?
Because that's what MCP is all about.
Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.
The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.
MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.
Exactly this. It’s a very effective way to integrate your app into Claude/openai.
I was anti-MCP at one point when it was eating up a substantial amount of context in Claude code. That’s largely been fixed now.
From my perspective, they are a great way to wrap an API for agent consumption. I can see a future where every major commercial or service website (think airline websites) have an MCP your agent can use to check flight status, rebook, or check you in.
The title feels clickbaity. Direct API, CLI and MCP all have their uses.
Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.
CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.
MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
This doesnt match my experience. Yesterday, I was using Microsoft's Power BI Authoring MCP to make a semantic model from some SQL or CSV files. It was magical.
Microsoft has defined how to do that in the MCP. It's trivial to add the MCP to the machine and reliable in execution.
The alternative would be the model having to get the documentation directly from their documentation website, it sounds like. If this was the case, then MS would likely have great docs and probably support that markdown header... but everything hinges on finding a specific web page on the internet? Seems worse in every way than MCP to me.
MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool.
They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.
It's not just the agent understanding the API, it's locking down the access they have. If I want to give access to an internal service in specific ways that the API doesn't lock down then an MCP that offers very specific queries, with protective controls and transformations in place is very useful.
CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
a lot of websites that never bothered to provide a REST API are now exposing MCP server because it has become popular, and you can use those servers to write normal automation for yourself, without plugging in any LLM etc
I don't think MCP is a bad idea, but using them incorrectly is.
CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly.
HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones.
Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.
I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist.
But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.
There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials.
There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.
Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).
Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.
> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic.
I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible.
Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply.
Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?
I’m not sure I agree that the frontier just know the apis right now, in my experience trying this there’s still a lot of faffing around trying to figure out the right parameters happily burning tokens and bloating context. Also the cost effective models to use in production for real agentic enterprise work absolutely still need the extra help and will do for at least the next 6 months.
In my experience they are very good at figuring out the apis. Well designed clis matter here but I've been able to give llms clis and its been pretty good.
It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.
GPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
> I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent.
This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features.
This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system.
Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches
I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content.
It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying.
This for me solves the danger of a tool returning tons of content.
If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.
This issue isn't just about communication methods and technical details. It's also about “standards”, and it will become increasingly important over time. As we begin to integrate AI into everything-for example, into banks...
>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers
oh would you look at that, Vercel suggesting to abuse how standard headers have been used for decades so it can send Accept-Language: rust because it's too lazy to ask for standardising an X-Prefers-Lang or anything else, and Shopify is here to shit on the internet too. Great.
Don’t worry, you don’t need to attack them – they do a great job of making themselves look ridiculous with their ignorant conversation. I would be so embarrassed if I had suggested that in public then subsequently discovered that the header doesn’t mean that at all.
People keep trying to systematize things for the tools they keep saying don't need systemization. No idea why you can't just put the documentation programming language context in the URL. "/docs/typescript/...", "/docs/python/..." etc.
I don't think the agents are struggling with the idea that different URLs have different responses, and that checking the sitemap is a good idea.
MCP for agents never made sense, especially when the tokens they consume a significant amount of tokens on a single request for a basic action, and sustained usage blows up you token costs.
The spec was poorly designed to begin with. Even saw some folks here thinking it was a good idea to enable MCP directly on a production database for what? Risking exfiltration of sensitive data for bad AI agents.
Given the increased security capabilities of these new models (Mythos, Astra, K3), it sounds like MCP would not be able to justify on making sense from a security perspective and would be a very bad idea to use anyway.
With MCP or HTTP, how do you implicitly limit access of the agent to a particular user? In other words, how do you avoid giving the agent access to perform an operation for any injected user? This is a basic security question.
I can do this trivially when my tool functions are closures that have the user-id pre-bound, but with MCP and HTTP I naively assume that the callables are pre-set.
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.
If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?
This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool.
I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.”
Well yes.
Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait
And call it not-closed API or something like that.
I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.
Best of both worlds in my view.
> If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
they were suggesting that you take the agent out of the run time tool usage
Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.
For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.
Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.
This is my favorite position, the advantage of an MCP tends to lie more in token optimization.
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
Hah, I made that same point last December: https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-...
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
Yeah, from a design perspective MCP upsets me, because it’s a poorly designed standard and creating a good one could have been much easier.
But you’re right, since clients don’t have a nicely sandboxed “make api request” tool, it’s basically the way to go for a lot of use cases.
"without first having to solve the problem of effectively sandboxing Bash"
Hopefully this is easier as time goes on. Of course- also policy on the egress
Pretty much, MCP is still a bad idea.
LLMs perform significantly better and faster when you strap them to plain old apis/and an open api spec with a search tool.
My current MCP design is… grab a fastapi spec shove it into fastmcp, shallow wrapper, search tool for the full schema.
Oh boy so exciting I just wrapped an api spec for no reason and have to host infra for the translation layer. If only we invented api gateways.
But I am Mr. AI now.
How do you handle credentials safely?
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
1. Control can be done via CLIs --> api key based access controls. We have been doing it forever. 2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo. 3. This can be done via apis/clis too --> not something unique to MCP iimo 4. Same thing, not unique to MCP --> api servers can also be logged
MCP doesn't inherently make this easier. its still requires engineering maintaincence.
Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.
Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI!
MCP suffers from its harebrained choice early on to load everything into context up front.
[flagged]
A CLI doing all this is still a better UI for the agent though.
What if the agent doesn't have a CLI?
What does that even mean?
totally makes no sense. so weird after all this time people don’t “get” the value of MCPs, so weird
Real hard to not think-
"This is a job for a CLI/terminal, which is absolutely a million times easier to learn today, thanks to AI."
Feels like MCP is still a product of -- well, "AI as a product" brain, which I have no love or use for. Give EVERYONE ALL the tools.
> Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
I don't think this is a valid statement too. I'll explain why.
A MCP server represents those APIs that agents and coding assistants can call.
If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work?
Because that's what MCP is all about.
Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.
Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.
MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.
Exactly this. It’s a very effective way to integrate your app into Claude/openai.
I was anti-MCP at one point when it was eating up a substantial amount of context in Claude code. That’s largely been fixed now.
From my perspective, they are a great way to wrap an API for agent consumption. I can see a future where every major commercial or service website (think airline websites) have an MCP your agent can use to check flight status, rebook, or check you in.
The title feels clickbaity. Direct API, CLI and MCP all have their uses.
Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.
CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.
MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
MCP's monolithic design always felt like fighting a hydra; one fix created five new bugs elsewhere. Never understood why it gained traction.
This doesnt match my experience. Yesterday, I was using Microsoft's Power BI Authoring MCP to make a semantic model from some SQL or CSV files. It was magical.
Microsoft has defined how to do that in the MCP. It's trivial to add the MCP to the machine and reliable in execution.
The alternative would be the model having to get the documentation directly from their documentation website, it sounds like. If this was the case, then MS would likely have great docs and probably support that markdown header... but everything hinges on finding a specific web page on the internet? Seems worse in every way than MCP to me.
AWS has many MCP servers that work extremely well.
MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool.
They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.
Not sure why the title on HN ends with a question mark. It's grammatically incorrect and not in the original article
It's not just the agent understanding the API, it's locking down the access they have. If I want to give access to an internal service in specific ways that the API doesn't lock down then an MCP that offers very specific queries, with protective controls and transformations in place is very useful.
I always wonder why they didn't use Swagger|https://www.openapis.org. It addresses all the key description and security details.
CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
MCP lead to one good thing though
a lot of websites that never bothered to provide a REST API are now exposing MCP server because it has become popular, and you can use those servers to write normal automation for yourself, without plugging in any LLM etc
You have to throw in “load bearing” in the request though to avoid suspicion
Also dynamic oidc registration (client.dev) has became better supported on oidc idps to support MCP
I don't think MCP is a bad idea, but using them incorrectly is.
CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly.
HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones.
Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.
I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist.
But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.
There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials.
There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.
> both to bypass IP address rate limits
Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).
MCPs are indeed useless, they're very limited in functionality and frequently struggle with large requests or get wedged in bad states.
There is no reason not to use the native API directly.
The MCP is the most efficient way of handling what we do! I can't sit here and worry about every little user request that comes in!
Surprised WebMCP hasn't come up here.
Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.
> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic.
I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible.
Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply.
Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?
I'm old enough to remember the OpenAPI spec.
Yeah sorry I'm just a humble Senior-Staff Vibe-Engineer born in 2020. Get out of here with your ancient 2010s API specs, old man! </sarcasm>
But seriously, just publishing OAS docs at a /.well-known URI seems very sensible. https://www.rfc-editor.org/rfc/rfc9727.html
Even if the premise is correct, bad ideas are often the first step towards a good idea.
I’m not sure I agree that the frontier just know the apis right now, in my experience trying this there’s still a lot of faffing around trying to figure out the right parameters happily burning tokens and bloating context. Also the cost effective models to use in production for real agentic enterprise work absolutely still need the extra help and will do for at least the next 6 months.
In my experience they are very good at figuring out the apis. Well designed clis matter here but I've been able to give llms clis and its been pretty good.
is it easier for an LLM to figure out a CLI or a REST API?
cli because the feedback loop is faster
There are numerous applications that you don't need and don't want to give shell access to an llm.
It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.
I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent.
I think something like infiscial ai proxy could be useful here. Never store the creds on device.
GPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
Well, if your agent lacks shell access (or has some other sandboxing going on), it shouldn't have access to envs and MCP setup files.
(leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
> I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent.
This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features.
This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
It doesn't need to be. The service creds can be on another host entirely.
Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system.
Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches
Some people can't appreciate that their local Claude code workflow isn't the only MCP usecase. If you don't need it, then don't use it.
Why are they still having this debate in 2026 when CodeAct have existed for years, and the LLM's are getting much better at coding in the first place?
I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content.
It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying.
This for me solves the danger of a tool returning tons of content.
> captures the output of anything and allows the LLM to query it later
Otherwise known as a “file”. ;)
Don't most harnesses already do that for bash commands?
If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.
This issue isn't just about communication methods and technical details. It's also about “standards”, and it will become increasingly important over time. As we begin to integrate AI into everything-for example, into banks...
MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.
> The MCP Industrial Complex
Was that a real thing? I mean it must've been for it to be mentioned there, but, rephrased: what was the scale of that?
How many individuals were involved in that? 1? 10? 100? 1000? 10000? 100000?
Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.
>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers
oh would you look at that, Vercel suggesting to abuse how standard headers have been used for decades so it can send Accept-Language: rust because it's too lazy to ask for standardising an X-Prefers-Lang or anything else, and Shopify is here to shit on the internet too. Great.
Don’t worry, you don’t need to attack them – they do a great job of making themselves look ridiculous with their ignorant conversation. I would be so embarrassed if I had suggested that in public then subsequently discovered that the header doesn’t mean that at all.
People keep trying to systematize things for the tools they keep saying don't need systemization. No idea why you can't just put the documentation programming language context in the URL. "/docs/typescript/...", "/docs/python/..." etc.
I don't think the agents are struggling with the idea that different URLs have different responses, and that checking the sitemap is a good idea.
Tangential: A rare en–dash user out in the wild!
Yeah I think a better header is good. The idea isnt bad in concept.
Well Malte came up with AMP so there’s a history of doing odd things
> Accept-Language: rust
That's craziness.
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
Well, SaaS don't do CLIs for extension APIs.
Plus the performance issues to restarting processes all the time.
Neither of those things are true?
Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?
Yes, if the SaaS application needs to fork subprocesses for every little step of agentic workflows.
Welcome to CGIs, a great 1990's technology for Web applications.
We do that, and the cost of forking the cli vs the llm or network call is very small. It works really well.
CLI first
MCP is a good idea
JSON is a bad format/transport.
https://github.com/kunchenguid/axi
MCPs are a bad idea because they encourage token burn at runtime when a deterministic program that uses the API should be used.
Of course Mario, Sammy, Jensen et al. would be for this.
MCP for agents never made sense, especially when the tokens they consume a significant amount of tokens on a single request for a basic action, and sustained usage blows up you token costs.
The spec was poorly designed to begin with. Even saw some folks here thinking it was a good idea to enable MCP directly on a production database for what? Risking exfiltration of sensitive data for bad AI agents.
Given the increased security capabilities of these new models (Mythos, Astra, K3), it sounds like MCP would not be able to justify on making sense from a security perspective and would be a very bad idea to use anyway.
So no thanks and no deal.
Well, think of the near-future when tokens are so cheap that they’re not worth to meter.
"The attack surface wasn't big _enough_"
With MCP or HTTP, how do you implicitly limit access of the agent to a particular user? In other words, how do you avoid giving the agent access to perform an operation for any injected user? This is a basic security question.
I can do this trivially when my tool functions are closures that have the user-id pre-bound, but with MCP and HTTP I naively assume that the callables are pre-set.
You know you are getting old when Acronym's change on you.
Vacate entry port, program! I said, move out!
[flagged]
[dead]
[dead]
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.
If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?