Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

291–300 of 301 posts

Re: When does MCP make sense vs CLI?

#291

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.

Yes, it's surely possible, but a well-designed CLI or any tool of that matter would be efficient when it comes to the context size.

Re: When does MCP make sense vs CLI?

#292

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

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

That's a very developer-centric view. So many things in the world don't have a CLI API at all and will never have one, like the huge majority of desktop GUI programs.

Re: When does MCP make sense vs CLI?

#293

Earlier quoted context omitted.

I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.

CLI enables the actions to be made on behalf of you, the external service is not aware whether it's you or AI making the calls. With MCP, Sentry knows it's AI making the call so can be smarter about the security. There is many MCP annotation hints on tools to mark the as destructive, read-only etc.

That's interesting, but that still sounds like something a proper auth/token permission system would more than address. You're also actively choosing to limit what functionality MCP provides, which is fine, but there are many ways to do the same via the API or CLI tooling.

I'm not saying you are wrong to do this, I just don't think it's enough to convince me that yes this is the one true approach you should use.

Re: When does MCP make sense vs CLI?

#294

Earlier quoted context omitted.

That makes some sense. But one can make the argument given how easy it is to create CLI tools and add new API endpoints, enhancing them is still a better approach than creating and MCP. I'm not pro or anti-MCP myself. I just haven't had a lot of success using them yet. I've been struggling to find the right balance and every path has lead me to a CLI tool (optionally paired with a skill). Now I'm not using my cli too…

I don't think MCPs have legs long-term, but they are a great middle ground during this somewhat turbulent transition period we find ourselves in, precisely because they are not the existing tooling (they are greenfield). An existing company that has an API/CLI might not have everyone on the team on-board with LLMs and agents and what have you – it might be hard to get buy-in to modify those existing surface areas to…

You're not wrong, but I could also argue the same about creating a new CLI or custom API. Now I know there's some expectation that APIs and CLI tools don't change willy-nilly, and that's not the case for MCP endpoints (yet), but if you clearly define the use case the outcome is the same.

But I think we generally think the same. MCP is a tax we have to pay right now to play in the whole ecosystem, but it sure doesn't feel like the right play long term.

Re: When does MCP make sense vs CLI?

#295

Most of what the article says is true regarding coding agents, but articles like this are making a big mistake: they're completely forgetting that agentic applications aren't all claude code. We're entering an era where many organisations will have agentic loops running in their own backends. There's a spectrum of constraint that can be applied to these apps -- at one end claude code running unsandboxed on your lapto…

Sure, but it's pretty trivial to generate a CLI application that talks to that API. That's how I let agents access my database too. Letting them access psql is a recipe for disaster, but a CLI executable that contains the credentials, and provides access to a number of predefined queries and commands? That's pretty convenient.

Yes. But are you letting your agent make the decision of when and how to call that CLI? And presumably you're invoking it via the Bash tool. In which case your agent is free to write ad-hoc bash orchestration around your CLI calls. And perhaps you don't just have one such CLI but rather N for N different services.

And so we've arrived at the world of ad-hoc on-the-fly bash scripting that teams writing backend agentic applications in more "traditional"/conservative companies are not going to want.

Don't get me wrong, it's great for claude-code-type local computer automation use cases -- I do the same as you there.

Re: When does MCP make sense vs CLI?

#296

It seems that the author thinks that AI use is limited to developers, I don't understand how short slighted is the debate between CLI and MCP. Sure, CLI are more convenient, but currently most AI users consume LLM through online tools like ChatGPT A basic example: a company using ChatGPT or Claude, and wanting to connect their business tools (ex: marketing, sales, project management...). in that case MCP is perfect f…

Underrated comment

Re: When does MCP make sense vs CLI?

#297
The CLI is great for humans, but for agents, the 'Discovery' problem is real. With a CLI, I still have to 'teach' the LLM how to use it by feeding it help docs or manual examples, especially for new or internal tools the model wasn't trained on.

MCP’s biggest strength is that it self-advertises, the agent knows the capabilities and schemas immediately upon connection. It turns 'tool-use' from a prompting/training problem into a standardized handshake. I’d much rather have a protocol that handles the discovery than have to manage custom system prompts for every new CLI utility.

Re: When does MCP make sense vs CLI?

#298
post #263

Earlier quoted context omitted.

Why don't you just have the agent write scripts against the APIs? The skills-based workflow doesn't confine you to bash only.

If you do that, you end up with all the problems that MCP attempts to solve: how to authorize using a standard mechanism, how to summarize operations in a better way than just dumping the OpenAPI spec on the LLM, providing structured input/output, providing answers to users that the LLM cannot see (for sensitive data or just avoiding polluting the context) and so on. Authorization, in my opinion, is the big problem y…

Broadly agree that authorization is the biggest thing to solve for, but it seems like a Django vs. FastAPI distinction.

MCP in its default state takes up too much context, creating the new for "MCP as code", which seems a bit circular.

Re: When does MCP make sense vs CLI?

#299

Earlier quoted context omitted.

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.

I get that. Should and DO are different. But you aren't addressing my Streamable HTTP question which is the heart of what I asked.

There's nothing special about using http other than most corporate firewalls allow it. It's just the pragmatic choice.

Re: When does MCP make sense vs CLI?

#300

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

[dead]
Post reply on HN