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.

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.

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.

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.

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.

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

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

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.