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.
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.
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.
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.
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.
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.
> 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?
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.
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’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.
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.
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...
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
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.
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.
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.
>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.
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.
Best of both worlds in my view.
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.
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 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.
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?
But seriously, just publishing OAS docs at a /.well-known URI seems very sensible. https://www.rfc-editor.org/rfc/rfc9727.html
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.
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 is no reason not to use the native API directly.
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 think something like infiscial ai proxy could be useful here. Never store the creds on device.
(leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
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.
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?
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.
Otherwise known as a “file”. ;)
Of course Mario, Sammy, Jensen et al. would be for this.
Plus the performance issues to restarting processes all the time.
Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?
Welcome to CGIs, a great 1990's technology for Web applications.
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.
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.
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!
That's craziness.