When does MCP make sense vs CLI?

Posted by ejholmes 10 hours ago

When does MCP make sense vs CLI?(ejholmes.github.io)

268 points | 181 commentspage 5

baq 7 hours ago|

Remote MCP solve the distribution problem just like everyone uses web apps for everything nowadays instead of desktop apps. Local MCP servers make as much sense as local web apps.

juanre 9 hours ago||

Reports of MCP's demise have been greatly exaggerated, but a CLI is indeed the right choice when the interface to the LLM is not a chat in a browser window.

For example, I built https://claweb.ai to enable agents to communicate with other agents. They run aw [1], an OSS Go CLI that manages all the details. This means they can have sync chats (not impossible with MCP, but very difficult). It also enables signing messages and (coming soon) e2ee. This would be, as far as I can tell, impossible using MCP.

[1] https://github.com/awebai/aw

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

Nevin1901 9 hours ago||

This is actually the first use case where I agree with the poster. really interesting, especially for technical people using ai. why would you spend time setting up and installing an mcp server when u can give it one man page

bartek_gdn 7 hours ago||

I've come to the same conclusion as op, created a CLI tool to work with Chrome sessions. It works well, and I'm planning to do some token comparison on this vs an MCP approach. https://news.ycombinator.com/item?id=47207790

ejholmes 7 hours ago|

Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.

mavam 8 hours ago||

Why choose if you can have both? You can turn any MCP into an CLI with Pete's MCPorter: https://mcporter.dev.

Since I've just switched from buggy Claude Code to pi, I created an extension for it: https://github.com/mavam/pi-mcporter.

There are still a few OAuth quirks, but it works well.

appsoftware 9 hours ago||

?? I'm using my own remote MCP server with openclaw now. I do understand the use case for CLI. In his Lex Friedman interview the creator highlights some of the advantages of CLI, such as being able to grep over responses. But there are situations where remote MCP works really well, such as where OAuth is used for authentication - you can hit an endpoint on the MCP server, get redirected to authenticate and authorise scopes etc and the auth server then responds to the MCP server.

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

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

More comments...