Why MCP Was Always a Bad Idea

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.

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.

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

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

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.

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

There are numerous applications that you don't need and don't want to give shell access to an llm.

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

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.

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

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

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.

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

Well, SaaS don't do CLIs for extension APIs.

Plus the performance issues to restarting processes all the time.

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.

i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http

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.

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.

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

You know you are getting old when Acronym's change on you.