alt Hacker NewsWhen does MCP make sense vs CLI?
Comments
When we give LLM access to the terminal, LLM doesn't need anything else. LLM already knows all the commands, and there's no need to waste context on MCP. When we tell it to use a new command, it can get `--help` as needed.
If you’re going this far, why even have a cli? Just have your agent grab the openapi spec from the server and set envvars. It can curl its way around happily. Security? I don’t see how this is any more or less secure than any other claude code workflow.
It seems we've round about rediscovered apis.
I tried this with datadog and it can build high quality monitoring notebooks for the pr im working on in a single shot.
I keep asking why the default Claude tools like Read(), Write(), Edit(), MultiEdit(), Replace() tools aren’t just Bash() with some combination of cat, sed, grep, find. Isn’t it just easier to pipe everything through the shell? We just need to figure out the permissions for it.
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.
What, those job ads asking for 5 years of experience with MCP were useless after all?
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.
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
You use MCP to provide dumb-down API that LLM can consume. It's not that hard. If you MCP server is 1:1 map to your REST - you're doing it wrong.
Then there things like browser-mcp and some tools you make yourself to make workflow easier (adding self-describing MCP is easier than telling agent about your CLI tool in some markdown file that LLM forgot about 20k tokens ago.
MCP is a completely useless abstraction, and I’m not sure why anyone would push for it over basic cli tools / skills.
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.
What if you want to build a third party integration to connect to Claude Chat or Cowork? Those can't run arbitrary CLIs. The only way to integrate with them is via MCP.
For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.
It really seems the primary benefit of MCP servers was to force companies to establish some externally exposed APIs if/when they did not have them.
Even for Openclaw, the response API is a better way to interact with it adhoc. I tell Cursor how to contact OC with a bearer key, and they work things out in the background when I'm building something for Openclaw.
?? 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.
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.
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.
Tell my business users to use CLI when they create their agents. It's just not happening. MCP is point-and-click for them.
MCP is far from dead, at least outside of tech circles.
MCP is worth it when you need standardized, safe, observable tool calls across many systems; for single-purpose workflows, a CLI stays simpler and more debuggable.
And for anything at all complicated, what’s even better than a CLI is a JS or Python library so the thing can just write code.
I’ve noticed Claude Codes sandbox mode works with MCPs. With CLIs I’ve rain into permission issues. CLIs also need reminding about whats available unless references are baked the context window.
In terms of what companies are actually implementing, MCP isnt dead by a long time. Number of companies with a MCP server grew 242% in the last 6 months and is actually accelerating (according to Bloomberry) [1]
https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
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...)
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
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.
Also when they use cli you can learn from it and sometimes, next time you’ll be faster if its just a simple edit compared to an ai that first has to understand relevant context.
> OpenClaw doesn’t support it. Pi doesn’t support it.
It's maybe not optimal to conclude anything from these two. The Vienna school of AI agents focuses on self extending agents and that's not really compatible with MCP. There are lots of other approaches where MCP is very entrenched and probably will stick around.
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.
For personnal agents like claude code, clis are awesome.
In web/cloud based environment, giving a cli to the agent is not easy. Codemode comes to mind but often the tool is externalized anyway so mcp comes handy. Standardisation of auth makes sense in these environments too.
APIs and CLIs still remain king, just like before. The difference is mostly in UIs and how you deliver it.
This doesn't really pay attention to token costs. If I'm making a series of statically dependent calls I want to avoid blowing up the context with information on the intermediary states. Also, I don't really want to send my users skill.md files on how to do X,Y & Z.
Use APIs for building things (and preparing for things to be built upon). Production.
Use CLI for exploration, coding, and learning. Greenfield.
In general, Declarative > Imperative.
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.
https://github.com/mcpshim/mcpshim - converts MCPs to CLI - best of both worlds
I don't understand the CLI vs MCP. In cli's like Claude Code, MCPs give a lot of additional functionality, such as status polling that is hard to get right with raw documentation on what APIs to call.
That's too close to actual programming, vibe coders will never go for it.
To be fair to MCP it came out 150 years ago, in November 2024. Agents were running on steam and coal then with Sam Altman shovelling the furnace.
Advancing capability in the models themselves should be expected to eat alive every helpful harness you create to improve its capabilities.
genuine question: how would you turn a debugger-mcp into a CLI? do CLI tools used in agents have the concept of persistence?
MCPs were always for chat apps, not coding agents. Benefit is auth for normies + can serve UI through ChatGPT + Claude.
Biggest downside of CLI for me is that it needs to run in a container. You're allowing the agent to run CLI tools, so you need to limit what it can do.
CLIs are dead. Long live the skill. Which is a wrapper around the CLI! Haha.
on the other hand, MCP/tools style lets me run specialized agents without needing to give them a bash-like unix environment. Vercel makes a fake bash simulator but if i’m trying to run an agent that analyzes production telemetry, it’s a hell of a lot easier to do that safely with just MCP
Couldn't agree more. Simple REST APIs often do the job as well. MCP felt like a vibe-coded fever dream from the start.
I’ve been using the command line tools except for teams integration which I use MCP for
Thoughts on Agent Context Protocol (ACP)?
This is spot on
This is the dumbest most myopic take I’ve seen in awhile. MCP servers aren’t just used for geeks using Claude Code. If I have an app in production that uses an MCP server what is he suggesting? That my LLM create a shell script and run it inside of a Docker container?
I don't know about this. I use AI, but I've never used or tried MCP. I've never had any problems with the current tools.
CLI vs MCP debate misses the protocol's actual value prop: steering the agent: https://cra.mr/context-management-and-mcp