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 is just Tool Use

I wish. https://modelcontextprotocol.io/specification/2026-07-28

The spec describes Resources, Prompts, Tools, and Elicitation.

In practice, I believe Tools represent 95%+ of what people actually use MCP for. I've not seen an MCP with Resources or Prompts that seems to have widespread use of those features, and I don't think I've ever seen anything implement Elicitation.

Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.

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.

That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.

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.

The simplified interactions are how it should have been designed in the first place.

It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.

Sure but that common case should go into the core APIs, not an MCP.

agreed lots of ppl writing mcp as a lipstick on the pig.

MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.

Yea my company is willing to pour money into an MCP but has concretely resisted attempts to improve or care about the API for years.

What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.

Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.

Sharing Slack with Claude:

- Using the "normal" way, it shares too much, including privates messages.

- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.

- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.

Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait

And call it not-closed API or something like that.

Congrats you just invented the Unix shell!

Yes, having LLMs write deterministic programs is still an under used solution.

Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.

Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.

> If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.

The MCP is the deterministic program.

You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.

It's the interface for your deterministic program. That's it.

they were suggesting that you take the agent out of the run time tool usage

> they were suggesting that you take the agent out of the run time tool usage

That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.

It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.

Heisenberg begs to differ with your view of reality.

So does Gödel. Maybe it was a joke? Unclear.

A protocol is not a program.

I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.

Best of both worlds in my view.

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

Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard.

Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear.

1: https://thebiglog.com/links/linear-cli-instead-of-linear-mcp

This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same.

I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.

Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.

How much are using Linear if token usage is a problem? Sounds like a case of straining at a gnat and swallowing a camel.

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.

For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.

Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.

No one is saying to wrap your local power shell modules in an MCP. That would be pointless and stupid.

This is my favorite position, the advantage of an MCP tends to lie more in token optimization.

In what way?

Not sure whats the norm nowadays, but it used to be MCP descriptions were loaded in from the start.

In any case, to be cheaper the `cli --help` command needs to more noisy than the json description.

Finally, and the really big one: cli can be composed with `grep`, `jq` , etc.

This is not true.

I guess it depends on the implementations.

When I use the Atlassian CLI vs their MCP server, I tend to see something like half the token burn with the CLI with more accurate results.

That could be an Atlassian issue but that's the results I'm seeing.

yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.

How do you think the LLM becomes aware of which mcps are available? Vibes?

It depends on the harness. But most use a tool_search tool.

yes and using that tool does what with tokens?

You seem confused.

I'm not. You can build an MCP and throw a ton of junk in there and bloat the shit out of its token cost. So, really, "it depends".

Sure, but if you have a staff of 10000, you're doing this 10000 times. Unless you share that in a common place, and now you're re-inventing the thing we're claiming not to need.

I love the level of sassiness this debate brings forward in people

People like you can't seem to comprehend that there are use-cases other than your little local claude code workflow.

Making the model use curl is even stupider. It still needs to do the same amount of work to lookup and understand the API contracts (assuming those are even public). But now it also needs to juggle the auth flows and marshalling at the tool call level.

You said ""re-implements an API client" which means you either don't know what curl is or don't know what an api client is. So I'd chill on calling things "stupider" when you don't have a strong grasp on the words you're using.

What is "implementing".... I'd define it as "figuring out the workflow, and storing it in a way that allows reuse". This could be a program written in assembly, or rust, or even python. Or it could be a shell script that calls curl. Or it could just be a set of tokens in the current session. Outside of the computer it could even be a set of processes people do, or a mechanical device.

If it's just a set of tokens in the current session, well then next session it has to figure out the workflow, and then store it in a way to use in the next session.

Seems like maybe you should take your own advice.

How does the definition of "implementing" change the fact that curl quite literally is an api client? It's an implemented api client.

> Seems like maybe you should take your own advice.

Seems like maybe if you have to use your own custom definition of a word in order to support a point you might not have one. lol.

Nonsense, curl is a tool for executing a single http request.

Many apis require several requests to get things done. (one to auth, one or more to fecth resource ids, one or more to modify resources, etc).

That would be a series of curl calls with logic applied to the output of each call to curl. An api client just does those things in a single function call. The steps are the same, but in one case the AI has to figure out each curl call and implement the logic, rather than just call the function.

lol Id say the nonsense is tying multiple calls to the definition of an api client.

Irony died in this comment thread.

By your logic 'ls' is a file manager, 'grep' is a search engine, and 'echo $X >> /proc/sys/$Y' is a settings manager.

It makes sense though. It's the same logic that allows you to say promting an AI with "do a simple thing for me" makes you a programmer, and prompting an AI with "what is an api" allows makes you knowledgable about computers.

In your mind, is netcat also an API client? When normal people talk about api clients, they're referring to an sdk or a cli which provides a simpler interface for a specific API.

You're not implying netcat and curl are synonymous are you?

And When "normal" people talk about api clients? lol This site is wild.

Alright dude ... Either you have major comprehension issues or you're arguing in bad faith. But I'm done responding to you.

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.

The other problem with MCPs is that the harnesses don't auto-reconnect if you've enabled access. Connection status should be persistent

Exactly. There are so many replies here of the form “MCP sucks. If you just do you don’t need mcp at all.”

Well yes.

I think the point of those comments is this could have been much simpler for everyone if the model providers had given us some tools around existing standards.

Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).

> Exactly. There are so many replies here of the form “MCP sucks. If you just do you don’t need mcp at all.”

See my previous reply to simonw elsethread.

It's not "If you just do you don’t need mcp at all", it's that many of us were already doing that in a CLI prior to LLMs. You think only github and amazon had CLI clients?

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.

The service itself needs to control what the agent can access.

Relying on an intermediary to provide access controls, and that agents will never access the service directly, seems dangerous and naive.

And it's easy for the service to do that by hosting a remote MCP server.

Agent doesn't have api key to access service directly

What? Why? More is more but you're arguing a security proxy is a dangerous and naive pattern?

What’s the advantage of MCP over a regular old security proxy?

The better solution for security is sandbox execution. Most agents used in practice, if given terminal access, can find ways to get around most of the MCP restrictions.

well if you realease an api you should make sure its usable for ai out of box without 'something in between'. You should always assume ai might be directly calling your api.