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.

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.

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

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.

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.

To be fair, after visiting some trade shows recently, a lot of these “parasitic” LLM startups are not very convincing from a business-use case perspective. (They’re not really parasitic, more like a remora attaching itself to a shark, the shark being OpenAI or Anthropic).

At IMTS at Chicago the skepticism amongst the visitors towards AI and pure-AI startups was at an all-time high. More than once I heard, “Oh yeah I visited that AI booth and they couldn’t explain what value they would add to my business.”

So in that sense, while MCPs are “winning”, I also see them as a significant part of the AI “bubble”, specifically solutions looking for problems backed by VC money.

Aside from the actual protocol, it makes a lot of sense to have a standardized, discoverable protocol.

Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again. Not only very inefficient, it's unpredictable, and often slow.

Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.

With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!

MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.

Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.

What you're describing, though, is that agents need a REST API. And I meant true REST rather than the JSON RPC APIs we've been building for 20+ years now.

Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.

Another strong point for CLI is the `--dry-run` flag

The MCP use case is mainly another attempt at papering over the fact that effectively no API today is actually RESTful. We wouldn't need MCP at all if we still implemented REST APIs.

But you had to install their MCP server on your computer? That works for developers. Wouldn't it be nice to avoid another install?

AWS has many MCP servers that work extremely well.