Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

211–220 of 301 posts

Re: When does MCP make sense vs CLI?

#211
post #74

MCPs (especially remote MCPs) are like a black box API -- you don't have to install anything, provision any resources, etc. You just call it and get an answer. There's a place for that, but an MCP is ultimately a blunt instrument. CLI tools on the other hand are like precision instruments. Yes, you have to install them locally once, but after that, they have access to your local environment and can discover things on…

Unrelated, but as a non native English speaker it's funny to me that you use MCPs (plural) to refer to MCP tools.

Re: When does MCP make sense vs CLI?

#212
This author gets it. Ignore MCP, WebMCP, etc and instead build for humans like we always have. If LLM providers want usage they can push models to engage with tools like a human does - read docs, use a11y features, and when in doubt `--help`.

Re: When does MCP make sense vs CLI?

#213
I haven't been able to make a coherent argument against MCP, so I've settled for "I just don't like it".

CLI tools have an edge in that their definition live in model weights; MCP requires a portion of the context for tool definitions.

Having an extra server just to orchestrate the tools, I don't like it.

For anything that does not have a native CLI tool -- just write a wrapper, a shell script, whatever performs the task adequately. It folds into the workflow nicely. Leveraging decades of unix tooling philosophy has its benefits.

Having a shell runner is just... simpler. And as another comment mentions, you can create users for the various agents to restrict their access to things, almost as if that's what users were meant for!

Re: When does MCP make sense vs CLI?

#214

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

Interestingly think I just came to the opposite conclusion after building CLIs + MCPs for code.deepline.com

Where MCPs fit in - short answer is enterprise auth for non-technical users.

CLIs (or APIs + Skills) are easier + faster to set up, UX is better for most use cases, but a generalized API with an easier auth UX (in some cases, usually the MCP Oauth flow is flaky too).

So feels like an imperfect solution, but once you start doing a ton of enterprise auth setups, MCP starts to make more sense.

Re: When does MCP make sense vs CLI?

#215
post #165

Earlier quoted context omitted.

I always get a kick out of seeing MCP wrappers around CLI’s.

They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands

Silly. All it needs is docs. No need to overcomplicate it.

Re: When does MCP make sense vs CLI?

#217

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

What about MCP Apps? That seems like a legit use case but open to learning why maybe it isn't.

Re: When does MCP make sense vs CLI?

#218
These are all evolving technologies and it's pretty evident that the big AI labs are trying different things to see what sticks. Some of it does and they keep evolving it.

The reason MCPs are so powerful are less a technological advantage over other tools and more how ridiculously easy they are to install and use.

Also given it's an official standard now (AAIF), it's easy for sharing across differently agent harnesses and tools.

Those are the two main reasons imho, they are still a mainstay.

If you'll allow some shameless plugs, my co-host and I talk about it in our podcast:

https://fragmentedpodcast.com/episodes/302/

Re: When does MCP make sense vs CLI?

#219

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

We have a lot of tools (starting with the internal wiki) which are normally only exposed to engineers through web interfaces; MCPs make them available to terminal agents to use autonomously. This can get really interesting with e.g. giving Claude access to query logs and metrics to debug a production issue.

It is obnoxious that MCP results always go directly into the context window. I'd prefer to dump a large payload into Claude's filesystem and let him figure it out from there. But some of the places MCPs can be used don't even have filesystems.

Re: When does MCP make sense vs CLI?

#220
The only MCP server I use is Svelte's and every time I use it, I feel as though I'm just spamming my context window for little to no reason. I mostly only use it when I'm unsure about something.

However, it did feel useful when breaking changes were introduced, such as class->function component instantiation from Svelte 4 to Svelte 5.

This is probably true of any well-maintained MCP server provided for a project that has a rapidly-evolving API and highly opinionated maintainers who are unafraid to act on their opinions and break stuff. In that scenario, the Svelte MCP server seemed to act as a stop gap for context that the model's cutoff wouldn't allow it to have yet.

Post reply on HN