Top
Best
New

Posted by ejholmes 8 hours ago

When does MCP make sense vs CLI?(ejholmes.github.io)
209 points | 148 commentspage 3
simonw 6 hours ago|
MCP makes sense when you're not running a full container-based Unix environment for your agent to run Bash commands inside of.
someguy101010 5 hours ago|
yep! thats the motivation behind https://github.com/r33drichards/mcp-js

I want to be able to give agents access to computation in a secure way without giving them full access to a computer

deadf00d 2 hours ago||
IMO the biggest issue with CLIs for agents is to know when the agent is allowed to type. When is the command fully proceed, and next tokens can now be generated.
stldev 3 hours ago||
I've found MCP is great for stacking claude code instances- https://github.com/cduerr/stewardmcp has legit been a useful tool for me, and more reliable than handing a single instance 100k lines of code over a dozen repos.
g947o 4 hours ago||
If the author is just using Claude Code on their own personal computer, they can do whatever they want.

As soon as there is a need to interact with the outside world in a safe, controlled manner at enterprise scale, the limitations of CLI quickly become obvious.

I wish people get more informed about a subject before they write a long blog post about it.

ejholmes 4 hours ago||
You're right, but it still doesn't mean MCP was a good design even in that space. We could've done better.
Mapsmithy 4 hours ago||
Here’s your chance to educate us. It’s not at all obvious what sorts of limitations you’re talking about.
mikkelam 4 hours ago||
For me, GitHub CLI is the prime example of this. This CLI is so incredibly powerful when combined with regular command line tools. Agents know how to use head, tail, jq and so on to only extract the parts it needs.

The best selling point of CLIs is the ability to chain, transform and combine. MCP cannot do this.

bloppe 3 hours ago||
I've been thinking about this a lot lately in terms of my personal clauding, and it's hard for me to think of a scenario where an mcp server makes more sense than CLI tools and AGENTS.md. But if you're deploying an agentic product, it's probably different. Seems like you could just deploy little Bash sandboxes for each customer. Or you could deploy mcp servers. The latter feels much easier to reason about in terms of attack surface and potential side effects.
nemo1618 3 hours ago||
This will happen with GUIs as well, once computer-use agents start getting good. Why bother providing an API, when people can just direct their agent to click around inside the app? Trillions of matmuls to accomplish the same result as one HTTP request. It will be glorious. (I am only half joking...)
CloakHQ 3 hours ago|
Half joking, sure, but the "click around the app" problem is already real for teams running browser automation at scale. The issue isn't the clicks themselves - it's that every Chrome instance looks identical to a bot detector the moment you spin up ten of them from the same machine. The fingerprint (canvas, WebGL, navigator properties, etc.) is basically screaming "I'm automated". Dealing with this from the ops side: the headache isn't writing the automation, it's keeping each browser session isolated enough that sites don't treat them as the same entity. MCP or CLI doesn't really change that underlying problem.
cjonas 3 hours ago||
MCPs are useful to deploy internally as an agent tool gateway for your organization or customers. That's a totally different use case than how most of us interact with agents (claude code / cursor). That said, there's only limited benefit over just using OpenAPI.
jngiam1 3 hours ago||
I think if you want background agents with sandboxes and well scoped permissions, you want MCP to be your data protocol and security layer.

If you’re vibing and doing the open claw thing without any security concerns; then you’re absolutely right.

recursivedoubts 7 hours ago|
MCP has one thing going for it as an agentic API standard: token efficiency

The single-request-for-all-abilities model + JSON RPC is more token efficient than most alternatives. Less flexible in many ways, but given the current ReAct, etc. model of agentic AI, in which conversations grow geometrically with API responses, token efficiency is very important.

ejholmes 4 hours ago||
But they're not token efficient. Take the terraform example from the post. Plan JSON is massive. You're not saving tokens by using a Terraform MCP and shoving an entire plan into context. Composition allows for efficient token use.
SOLAR_FIELDS 6 hours ago|||
But the flip side of this is that the tools themselves take up a ton of token context. So if you have one mcp it’s great but there is an upper bound that you hit pretty quick of how many tools you can realistically expose to an agent without adding some intermediary lookup layer. It’s not compact enough of a spec and doesn’t have lazy loading built into it
harrall 6 hours ago||
Yes but I consider that just a bug in the agents that use MCP servers.

It could just be fixed to compress the context or the protocol could be tweaked.

Switching to CLIs is like buying a new car because you need an oil change. Sure, in this case, the user doesn’t get to control if the oil change can be done, but the issue is not the car — it’s that no one will do the relatively trivial fix.

dnautics 6 hours ago||
you know what you could do? You could write a skill that turns mcps on or off!
ako 6 hours ago||
I've been creating a cli tool with a focus on token efficiency. Dont see why cli could not be as token efficient as mcp. The cli has the option to output ascii, markdown and json.
recursivedoubts 6 hours ago|||
I'm working on a paper on this, if you are using a hypermedia-like system for progressive revelation of functionality you are likely to find that this chatty style of API is inefficient compared with an RPC-like system. The problem is architectural rather than representational.

I say this as a hypermedia enthusiast who was hoping to show otherwise.

bear3r 5 hours ago|||
the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.
ako 5 hours ago||
So far, cli --help seems to work quite well. I'm optimizing the cli to interact with the agent, e.g., commands that describe exactly what output is expected for the cli DSL, error messages that contain DSL examples that exactly describe the agent how to fix bugs, etc. Overall i think the DSL is more token efficient that a similar JSON, and easier to review for humans.
bear3r 3 hours ago||
fair point on token efficiency -- dsls are usually tighter than json. where i see mcp still winning is tool discovery: the client learns what tools exist and what args they take without having to try calling them first or knowing the commands upfront. with cli you have to already know the tool exists.
More comments...