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.

MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl.

Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible.

It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment.

I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.

> there's almost no reason to use MCPs if you are running a full-blown terminal agent

I disagree. Adding "https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.

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.

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.

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.

I feel like this would build a false sense of security.

Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent.

We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.

As someone who has never used MCP, or allowed an AI to directly talk to APIs, putting something between a model and a service just seems like common sense. If nothing else, it presents an opportunity to tightly control what the AI is allowed to do with external services, especially if the MCP code is outside of the AI's context. I would go as far as to say it's a necessary security measure.

Even for coding agents. MCP is the only unified interface INTO harnesses. This pattern has not struck yet for most, but will soon in the coming months given the MCP spec. MCP has been about models calling tools., it is about to become some form of inverse and MCP will be the only actual way to integrate into the models. Simple example is sending an event to the model (today models have to poll)... these coming updates will cement MCP as permanent infrastructure.

> This article entirely misses the value that MCP brings today.

Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics).

I have a CLI interface to my webapp, not an MCP.

> 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

Access control is not built into my CLI, it's built into the WebApp.

> 2. A way to handle authentication that doesn't allow the agent to directly access API keys

My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables.

> 3. A sensible UI to allow users to connect and authenticate further services

The parts of my WebApp that relays or re-requests to other third-party services handles access control.

> 4. Strong audit logging for what's going on

Not sure what this is supposed to mean: the WebApp already has auditing logs.

> MCP makes all of that so much easier to provide.

Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature.

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

It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.

The article also doesn't contemplate the "skill distribution problem" which will be addressed by skills-over-mcp.

With the plain ol' API solution, you still need some way for agents to fetch the instructions provided by the service. Of course there are answers for this, but they are not standardized.

With MCP, all you have to do is provide the harness with a single URL and all context can be bootstrapped the same way for every service.

Agree. MCP also helps in some esoteric use cases like interacting with legacy windows applications over COM. I created an MCP for Outlook 2019 desktop version and COM was the most straightforward way to let my agent interact with my mails for classification.

All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs.

MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form.

I see value in MCP, but it feels like a stopgap/stepping stone.

[0] Where "predict" = "hope". The best solutions are often not the winners.

> MCP makes all of that so much easier to provide.

Easier being the key!

Right now it really does feel like early web days where like 5% of the population is adopting things, but most people just get confused and don't participate.

This is why I'm pretty excited about WebMCP in particular!

WebMCP aligns more stakeholders than pure MCP - which seems heavily biased towards model providers. It also seems like it has the potential for a much cleaner ux.

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.

What matters is local server or not. Using a remote server means exposure.

The article misses the point of MCP but he is not wrong that it was a mistake (in some ways)

The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.

Now that MCP is stateless we can start building what is actually useful: extending API’s for agents.

When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s

This is not a dig at MCP, the original vision of MCP was much different from how the community used it.

A CLI doing all this is still a better UI for the agent though.

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.

In essence: MPC servers are the sandbox

Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too.

Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use?

I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.

Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans

Also MCP allows exposition, which helps an autonomous agent understand the semantics of the API.

That's the killer feature from my PoV. I just point my agent at a URL and suddenly it knows when, why and how to use it.

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.

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.