Why MCP Was Always a Bad Idea

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.

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.

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.

I never learned what MCP is and never understood the point (it's just an API? with something about context?) so happy I don't need to anymore

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.

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

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

Plus the performance issues to restarting processes all the time.

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 from an rouge AI agent.

Given the increased security capabilities of 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.

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

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