Some developers started asking a custumer of mine for a MCP server. They don't have one. They have an API on Postman (docs and examples) so they are exporting it as JSON and sending it to those developers. It might work but it's not what those developers want and maybe they will go to another similar service. So useless or not the availability a MCP server could be part of marketing and a checkbox on a due diligence sheet.
When does MCP make sense vs CLI?
241–250 of 301 posts
Re: When does MCP make sense vs CLI?
#242You actually answered your own question: "If a tool genuinely has no CLI equivalent, MCP might be the right call."
I built an MCP server this week for a structured database of founder decisions extracted from podcasts (https://github.com/echomindr/echomindr). There's no CLI equivalent because the value is in the agent discovering the tool and calling it contextually, when someone asks a startup question, Claude searches real founder experiences before answering.
The key distinction: MCP makes sense for discovery and contextual tool selection. CLIs make sense when the human already knows which tool to use. For `gh pr view 123`, of course the CLI wins. But for "search my specialized dataset when relevant", that's exactly what MCP was designed for.
Re: When does MCP make sense vs CLI?
#243What, those job ads asking for 5 years of experience with MCP were useless after all?
Re: When does MCP make sense vs CLI?
#244Earlier quoted context omitted.
Most APIs and CLIs are not setup with clear separation of permissions, and when they have those permissions are mostly designed around human access patterns and risks, not LLM ones. The primary example of course being read-only vs write access. MCPs have provided any easy way to side-step that baggage. e.g. in an MCP, you have tools, those tools are usually binned into "read" vs "write". Given that, I can easily conf…
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 be more "agent compatible".
Meanwhile, a team within a company that wants to make their company more "agent forward" can build an MCP tomorrow and it is clear what it is for: is a new surface, meant to be consumed by agents, with the needs of agents top-of-mind. It avoids confusing interop issues with existing tooling while maximizing said teams ability to ship changes/experiments quickly.
Re: When does MCP make sense vs CLI?
#245MCP Servers are not simple wrappers around REST APIs, they can do much more and we will see more advanced use-cases surrounding MCP as MCP clients continually improve their conformance to the spec. Just wrapping REST APIs may be what MCP Servers are now, but that's just because MCP clients still need to catch up in supporting these more advanced features.
MCP Sampling (with tool calling) is one such example, where MCP servers will be able to generate responses using the MCP client's LLM - not requiring an API key themselves - including calling other MCP tools within the "sampling loop", and without corrupting the primary agent's context. This will generate an explosion in advanced MCP servers, although neither Claude Code, Gemini CLI, nor Opencode support this feature (yet).
Once MCP sampling becomes widely supported the pendulum will swing back and we'll see the boundary between MCP tools, async workflows, and generative responses begin to blur.
Re: When does MCP make sense vs CLI?
#246Earlier quoted context omitted.
If you want a validation layer, why not write a cli that wraps the other cli?
that's what the MCP server is, except I don't always want a cli. If I need to call API on top of a cli tool, i don't have to have a second wrapper, or extend my existing wrapper. You're suggesting I recreate everything MCP does, just so..it's my own? MCP is just a way to use use wrappers other people have built, and to easily manage wrapping "tools", those could be cli tools, api calls, database query,etc.. cli tools…
> I don't get the issue people in this thread have with MCP, is there some burden about it I haven't ran into? It's pretty easy to set one up.
Doesn’t an MCP server require running a process for the endpoint? A CLI tool doesn’t have this problem.
Re: When does MCP make sense vs CLI?
#247Earlier quoted context omitted.
You can just write a README.md and put it along with the CLI
Because that is a consistent and reliable way of doing it? what happens when I have to use something that can't be done via cli, or if I have lots of small use cases (like I sometimes do with MCP servers - lots of tiny functions), do I create a separate readme for each of them and manage the mess? what exactly is the issue with MCP? is it too well organized? I mean technically I could be using cli tools to browse HN…
There are certainly things can't be done via CLI, or more suitable for a persistent daemon with various RPC rather than a CLI. But most things are simpler than that, and MCP is overcomplicating it.
MCP does not make things more organized. Everything is a file, and the filesystem is a mature infrastructure that we can trust. I don't see how MCP can be more organized than it.
curl is a great example of what CLI can do. Is there really a better way than curl for AI to browse HN?
Of course we should use Python or other sane scripts rather than shell to process JSON in production, but there is no need to hide the script in an MCP server. Also I don't see how it's easier to sandbox an MCP server than the CLI tools.
Re: When does MCP make sense vs CLI?
#248Running both MCP and CLI-based agents in production, my take is that this isn't an either/or question.
MCP shines for stateful integrations where auth and session management would be painful to handle in CLI scripts. Think Notion databases, Stripe dashboards, calendar APIs - things where the agent needs to maintain context across multiple operations. The tool descriptions in MCP also let you embed domain knowledge that's hard to capture in --help output.
But for anything involving file manipulation, git, build systems, or standard dev tooling? CLI wins hands down. The composability point is real - being able to pipe output through jq or redirect to a file gives you flexibility that MCP can't match. And as noted, LLMs have been trained on mountains of CLI usage patterns.
The hybrid approach that's worked best for us: MCP for external service integrations, CLI for everything else. Let the agent write and execute shell scripts when it needs to chain operations - that's when you get the best of both worlds.
Re: When does MCP make sense vs CLI?
#249> 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 ou…
Using the source code to ask questions about poorly documented features in projects you have no experience is my favourite thing that LLMs make possible (of course you could do this before but it would take way, way more time). There are so many little annoyances that I’ve been able to patch and, thanks to NixOS, have the patched software permanently available to me.
In fact NixOS + LLMs feels like the full promise of open source software is finally available to me. Everything is within reach. If you don’t like something, patch it out. If you want to change a default, patch that in.
No need to know the language, the weird build process, or the custom tooling. Idea to working binary in minutes. I love it so much.
Re: When does MCP make sense vs CLI?
#250> 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…
Why don't you just have the agent write scripts against the APIs? The skills-based workflow doesn't confine you to bash only.