Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

Post reply on HN
Print view View original

221–230 of 301 posts

Re: When does MCP make sense vs CLI?

#221

Post by baruch »

sunir wrote: post #192

The only place MCP made sense for me, so I thought, was to give my Claude Web agents access to the same cli tools my Claude Code agents had. In this context, agents don't have shells. However, then I discovered MCP servers on Claude Web are forced onto my laptop for Claude Code, which is very confusing. I don't know if there is a way to stop that, but it has messed up my Claude Code agents. Is this experience common,…

There is a global setting you can do to disable using the Claude.ai MCPs from being used on your Claude code.

Re: When does MCP make sense vs CLI?

#223

Post by seemaze »

closeparen wrote: post #219
umairnadeem123 wrote: post #83

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

> dump a large payload into Claude's filesystem and let him figure it out

I just realized I never thought of Claude as ‘him’, usually I think of Claude as ‘it’..

Re: When does MCP make sense vs CLI?

#224

Post by crazylogger »

MCP solves a very specific problem: how do you ship a LLM’s tool/function so that it is callable by an LLM in an inter-process manner (so that you don’t need to modify OpenAI’s code to make your tool available in ChatGPT)? CLIs concern what happens inside such tools, namely a `bash` tool. As you can see they are different layers of the same stack.

> LLMs don’t need a special protocol ... LLMs are really good at using command-line tools.

The author's point only makes sense if LLMs all have a computer built-in - they don't. LLMs will only have a commandline if it is provided with commandline tools, and MCP is the standard way to provide tools.

If I have to find an analogy for this (nonsensical) MCP vs. CLI framing, it's like someone saying “ditch the browser, use html instead” - what is that supposed to mean?

Re: When does MCP make sense vs CLI?

#225

Post by gopalv »

rprend wrote: post #200
umairnadeem123 wrote: post #83

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

MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!

> The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves.

The original take was that "We need to make tools which an AI can hold, because they don't have fingers" (like a quick-switch on a CNC mill).

My $job has been generating code for MCP calls, because we found that MCP is not a good way to take actions from a model, because it is hard to make it scriptable.

It definitely does a good job of progressively filling a context window, but changing things is often multiple operations + a transactional commit (or rename) on success.

We went from using a model to "change this" vs "write me a reusable script to change this" & running it with the right auth tokens.

Re: When does MCP make sense vs CLI?

#226

Post by notepad0x90 »

bonoboTP wrote: post #176
notepad0x90 wrote: post #168

Earlier quoted context omitted.

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?

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 aren't aware of the context window either, they're not keeping track of it. I might want my cli tool to output lots of useful text but maybe I don't want some of that for the LLM to save on tokens. Sure, I could create another cli tool to wrap my cli tool, now i have two cli tools to maintain. I'd prefer to do all the wrapping and pre-llm cleanup done in one consistent place. The instructions for the LLM letting it know what tools, parameters,etc.. are available is also defined in a consistent way, instead of me inventing my own scheme. I'd rather just focus on getting a usable agent.

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.

Re: When does MCP make sense vs CLI?

#227

Post by notepad0x90 »

woctordho wrote: post #198
notepad0x90 wrote: post #168

Earlier quoted context omitted.

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…

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 as well I guess. curl would do fine I suppose, but that'd be too annoying. Why not use the best tool for the task. as far as I'm concerned an stdio MCP server is a cli tool, it just happens to be an integration layer that can run either other cli tools, or do other things as it makes sense.

And FFS! I know jq can do wonderful things, but I'd seriously question anyone's competency if you're building a production code base that relies on a tangled mess of jq piping commands when you could just write a python function to parse, validate and process the content. And don't get me started with the risks of letting an agent running commands unchecked. What happens when your agent is running your cli tool using user-input arguments and you forgot to make sure command-injection won't be a thing? That can happen with MCP as well, but in many cases you shouldn't just run cli commands, you would call libraries, apis, process data files directly instead. You wouldn't call the sqlite3 command when you can just use the library/module.

Re: When does MCP make sense vs CLI?

#228

Post by notepad0x90 »

rprend wrote: post #200
umairnadeem123 wrote: post #83

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

MCP blew up in 2024, before terminal agents (claude code) blew up in early 2025. The story isn’t “MCP was a fake marketing thing pushed on us”. It’s a story of how quickly the meta evolves. These frameworks are discovered!

Do you mean for code generation, or process automation? for process automation, I think MCP is still very useful right?

Re: When does MCP make sense vs CLI?

#229

Post by [deleted] »

wenc wrote: 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…

[deleted]

Re: When does MCP make sense vs CLI?

#230

Post by realMorrisLiu »

Strong take: MCP is the wrong default for agent runtimes.

It solves the wrong layer and adds operational drag: extra server lifecycle, protocol semantics, and tool-schema overhead in context.

CLI + skills is simpler and more robust for long-running agents: - composability (pipes, filters, redirection) - debuggability (human runs the exact same command) - clearer permission boundaries (allowlist by subcommand) - less moving parts (no always-on MCP daemon)

If MCP is used at all, it should be an edge adapter, not the core runtime contract.

Post reply on HN