Been ignoring this junk for a long but I had to look since the front page is littered with "MCP". Is acronym on purpose?
When does MCP make sense vs CLI?
171–180 of 301 posts
Re: When does MCP make sense vs CLI?
#172Also 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.
Re: When does MCP make sense vs CLI?
#173> 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…
I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used. I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companie…
For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me.
We don’t use the cloud versions, so not sure if they work better with cloud.
On the other hand, i found some unofficial CLIs for both and they work great.
I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
Re: When does MCP make sense vs CLI?
#174One underrated reason that CLIs are often better than MCP is that Unix tools seem to have close to information theoretically optimal layout to enabled reasoning. They are concise, in the Solomonoff/Kolmogorov sense.
This means that the related parts in the inputs and outputs are recursively as close together as possible.
There's a reason humans don't type and read http/json on the command line. It's hard to read and reason over that type of syntax. json is made to be easy to parse for simple algorithms, not meant to organise info in an easy to reason about layout.
AIs benefit from the easy to reason about layout. It's not just about being able to fit in the context window but about the contents of that context window being organized such that the attention mechanism doesn't have to stretch itself out trying to connect far apart related pieces. It doesn't have to try to match brackets to disambiguate information. CLIs tend to use formats that are obvious at a glance for humans and LLMs alike.
It's about the entropy of the formats. https://benoitessiambre.com/entropy.html
Re: When does MCP make sense vs CLI?
#175> 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…
Even if the help isn't great, good coding agents can try out the cli for a few minutes and write up a skill, or read the sources or online docs and write up a skill. That takes the spot of the --help if needed. I found that I can spare quite a lot of time, I don't have to type up how to use it, if there is available info about it on the web, in man pages, in help pages, or the source is available, it can figure it out. I've had Claude download the sources of ffmpeg and blender to obtain deeper understanding of certain things that aren't much documented. Recent LLMs are great at quickly finding where a feature is implemented, how it works based on the code, testing the hypothesis, writing it up so it's not lost, and moving on with the work with much more grounding and fewer guessing and assumptions.
Re: When does MCP make sense vs CLI?
#176> 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…
If you want a validation layer, why not write a cli that wraps the other cli?
Re: When does MCP make sense vs CLI?
#177> 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…
When is MCP the right choice though? For example - letting internal users ask questions on top of datasets? Is it better to just offer the api openapi specs and let claude run wild? or provide an MCP with instructions?
MCP is never the right choice.
If you want to build an AI app that lets people “do random thing here”, then build an app.
Peak MCP is people trying to write a declarative UI as part of the MCP spec (1, I’m not kidding); which is “tldr; embed a webview of a web app and call it MCP”.
MCP is just “me too”; people want MCP to be an “AI App Store”; but the blunt, harsh reality is that it’s basically impossible to achieve that dream; that any MCP consumer can have the same app like experience for installed apps.
Seriously, if we can barely do that for browsers which have a consistent ui, there was never any hope even remotely that it would work out for the myriad of different MCP consumer apps.
It’s just stupid. Build a web app or an API.
You don’t need an MCP sever; agents can very happily interact with higher level functions.
(1) - https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-ap...
Re: When does MCP make sense vs CLI?
#178CLIs are dead. Long live the skill. Which is a wrapper around the CLI! Haha.
Re: When does MCP make sense vs CLI?
#179Earlier quoted context omitted.
I hate MCP servers That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems. But that's…
I always get a kick out of seeing MCP wrappers around CLI’s.
In my experience, a skill is better suited for this instead of an MCP.
If you don’t want the agent to probe the CLI when it needs it, a skill can describe the commands, arguments and flags so the agent can use them as needed.
Re: When does MCP make sense vs CLI?
#180If 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.