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…
When does MCP make sense vs CLI?
211–220 of 301 posts
Re: When does MCP make sense vs CLI?
#212Re: When does MCP make sense vs CLI?
#213CLI 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…
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?
#215Earlier 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
Re: When does MCP make sense vs CLI?
#216Re: 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…
Re: When does MCP make sense vs CLI?
#218The 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:
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…
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?
#220However, 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.