Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

Post reply on HN
Print view View original

191–200 of 301 posts

Re: When does MCP make sense vs CLI?

#191

Post by butcloudagent »

Okay, MCP is useless if the agent has full CLI access, sure. But what if it's a remote cloud agent connecting to another equally remote service. Well, now I need to install said CLI tool. What if I dont want to install a local mcp server either (which was always a stupid idea), and I want for there to be an harness around what the agent can do instead of give it a whole API?

With that said, the total number of applications that should have a MCP before an API is 0, and all that go beyond that threshold are partaking in sin and sacrilege.

Re: When does MCP make sense vs CLI?

#192

Post by sunir »

The only place MCP made sense for me, so I thought, was to give my Claude Web agents access to the same cli tools my Claude Code agents had. In this context, agents don't have shells.

However, then I discovered MCP servers on Claude Web are forced onto my laptop for Claude Code, which is very confusing. I don't know if there is a way to stop that, but it has messed up my Claude Code agents.

Is this experience common, and is there a known way to stop this?

Re: When does MCP make sense vs CLI?

#193

Post by coppsilgold »

femiagbabiaka wrote: post #125
umairnadeem123 wrote: post #83

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.

Containers, virtual machines, jails.

Containers have jail runtimes available. See for example gVisor/runsc.

Re: When does MCP make sense vs CLI?

#194

Post by drdaeman »

fasbiner wrote: post #100
drdaeman wrote: post #75

This is like comparing OpenAPI and strings (that may be JSON). That is, weird, and possibly even meaningless. MCP is formally defined in the general sense (including transport protocols), CLI is not. I mean, only specific CLIs can be defined, but a general CLI is only `(String, List String, Map Int Stream) -> PID` with no finer semantics attached (save for what the command name may imply), and transport is “whatever…

I would spend less time with theory and more time with practice to understand what people are getting at. MCP and CLI could, in theory, be the same. But in practice as it stands today, they are not. > MCP is just a way to write this in a structured way, Nope! You are not understanding or are actively ignoring the difference which has been explained by 20+ comments just here. It's not a controversial claim, it's a mut…

Fair enough, I’ll give it a try when I’ll have time for it.

I recognize that MCP as typically used would eat a good chunk of context - shoving all those API specs is wasteful for sure. The solution to this, I believe, is either RAG or single-tool (Context7-like), where relevant APIs are only provided on demand from models’ intermediate requests.

Caveat is model may need training to use that efficiently (or even at all, esp. smaller models are either very shy or crazy with tool use), and I don’t want to spend time fine tuning it. Could be that’s where the reality may prove me wrong.

But a token is a token. There is not a lot of difference between Playwright (or any other tool) use documentation wrapped in JSON with some logical separations, or provided as a long plain text blob (ultimately most likely also wrapped in JSON). So if the model doesn’t know how to use some tool innately (it may, for Playwright), and if it needs to use all tool functionality, I’m sure a CLI wouldn’t fare any better that MCP. But if the model knows the tool or needs just a small bit of its capabilities - naive MCP is going to be a bad idea.

Just like a human. If all I need is some simple thingy, I probably don’t need a whole textbook upfront, just a select excerpt. As far as I understand MCP, supplying full textbook in the system prompt is not MCPs innate design fault, it’s merely a simplest implementation approach.

Re: When does MCP make sense vs CLI?

#195

Post by butcloudagent »

jngiam1 wrote: post #124
quectophoton wrote: post #107

Earlier quoted context omitted.

Thank you, I was going to say something like this. I've been reading all the comments here and thinking, "do ChatGPT/LeChat/etc even allow running CLIs from their web or mobile interfaces?".

Exactly. and even if so, how are you going to safe guard tool access? Imagine your favorite email provider has a CLI for reading and sending email - you're cool with the agent reading, but not sending. What are you going to do? Make 2 API keys? Make N API keys for each possible tool configuration you care about? MCPs make this problem simple and easy to solve. CLIs don't. I don't think OpenClaw will last that long wi…

Supposedly, you make a Skill for it, but even that is out of scope for chat agents. I didn't scroll far, but I wouldn't be surprised more people in this thread have made the mistake of giving that answer.

Re: When does MCP make sense vs CLI?

#196

Post by tiahura »

umairnadeem123 wrote: post #83

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

And your most common command sequences can be dropped into a script that takes options. Add a tools.md documenting the tools and providing a few examples. How many workflows need more than maybe two dozen robust scripts?

Re: When does MCP make sense vs CLI?

#197

Post by 0x696C6961 »

bmurphy1976 wrote: post #183
buremba wrote: post #135

There is nothing wrong with MCP, it's just that stdio MCP was overengineered. MCP's Streamable HTTP with OAuth discovery is the best way to ship AI integration with your product nowadays. CLIs require sandboxing, doesn't handle auth in a standard way and it doesn't integrate to ChatGPT or Claude. Look at Sentry, they just ship a single URL https://mcp.sentry.dev/mcp and you don't need anything else. All agents that s…

Could you expand on this some more? I'm not quite following. I agree with the sandboxing challenge of a CLI, although I think any CLI (or MCP) wrapping an http API should be subject to a sane permissioning system that's a first class concept in the API itself. That's in my opinion the correct way to limit what different users/tools/agents can do. But I don't fully understand the Streamable HTTP point.

I doesn't matter how it "should" work. In the real world you need to interact with external systems which don't have granular enough permission schemes.

People out here letting Claude code run CLIs using their own user permissions are morons waiting to have their data deleted.

Re: When does MCP make sense vs CLI?

#198

Post by woctordho »

notepad0x90 wrote: post #168
umairnadeem123 wrote: post #83

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

Strongly disagree, despite that meaning I'm swimming upstream here. Unlike cli flags, with MCP I can tune the comments for the tool more easily (for my own MCPs at least) than a cli flag. You can only put so much in a cli --help output. The error handling and debugability is also nicer. Heck, I would even favor writing an MCP tool to wrap cli commands. It's easier for me to ensure dangerous flags or parameters aren't…

You can just write a README.md and put it along with the CLI

Re: When does MCP make sense vs CLI?

#199

Post by woctordho »

rimeice wrote: post #97

Very good points, but, I think this blog is pretty focussed on the developer use case for LLMs. It makes a lot more sense in chat style interfaces for connecting to non-dev tools or services with non technical users, if anything just from a UX perspective.

Interface for non-devs has evolved. We already have OpenClaw and things like Claude Cowork.

Re: When does MCP make sense vs CLI?

#200

Post by rprend »

umairnadeem123 wrote: post #83

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!
Post reply on HN