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

231–240 of 301 posts

Re: When does MCP make sense vs CLI?

#231

Post by stevekrouse »

The important part of MCP (that this misses) is that it's a machine interface you can quickly iterate on. In other words, an API is too slow-moving. You can't break it; it's a promise. A UI is too annoying for an LLM to deal with. An MCP is the perfect middleground: speaks JSON, but there's inference involved, so if you change the tools, the LLM will be just fine. (Just like how you can change your UI much faster than you change your API, because there's inference at runtime, ie in the human brain.)

For example, at my startup val.town, our MCP server is way more powerful than our API, because we added a bunch of tools to it willynilly because we're not worried about having to be stuck with those tools forever. We can remove them and nobody's code will break. (Just like we could remove buttons in our UI.) But an API change needs to be thought-through.

Re: When does MCP make sense vs CLI?

#232

Post by nvdnadj92 »

One clear use case where MCP is better than anything else: design system documentation for an enterprise, or using a specific UI library. Daisy UI has an example: https://github.com/birdseyevue/daisyui-mcp

Context7 is a good MCP. If one were to point an agent to a docs website, the amount of tokens consumed would use up too much of the context window to be able to do a meaningfully complex task with it.

Figma MCP translates Figma to a language an agent understands.

Not everything can be a cli.

Re: When does MCP make sense vs CLI?

#233

Post by ako »

bear3r wrote: post #112
ako wrote: post #67

Earlier quoted context omitted.

So far, cli --help seems to work quite well. I'm optimizing the cli to interact with the agent, e.g., commands that describe exactly what output is expected for the cli DSL, error messages that contain DSL examples that exactly describe the agent how to fix bugs, etc. Overall i think the DSL is more token efficient that a similar JSON, and easier to review for humans.

fair point on token efficiency -- dsls are usually tighter than json. where i see mcp still winning is tool discovery: the client learns what tools exist and what args they take without having to try calling them first or knowing the commands upfront. with cli you have to already know the tool exists.

This can be easily done using CLAUDE.md or similar. Easier than registering the MCP with the agent.

Re: When does MCP make sense vs CLI?

#234

Post by ithkuil »

cglan wrote: post #165
ejholmes wrote: post #163

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

Fwiw I'm having a good experience with a skill using Jira CLI directly. My first attempt using a Jira MCP failed. I didn't invest much time debugging the MCP issues, I just switched to the skill and it just worked.

Yes occasionally Claude uses the wrong flag and it has to retry the command (I didn't even bother to fork the skill and add some memory about the bad flag) but in practice it just works

Re: When does MCP make sense vs CLI?

#235

Post by cagz »

I understand the argument, and there are some really good points.

My biggest concern would be that adopting the CLI method would require LLM to have permission to execute binaries on the filesystem. This is a non-issue in an openclaw-type scenario where permission is there by design, but it would be more difficult to adopt in an enterprise setting. There are ways to limit LLMs to a directory tree where only allowed CLIs live, but there will still be hacks to break out of it. Not to mention, LLM would use an MCP or another local tool to execute CLI commands, making it a two-step process.

I am a supporter of human tools for humans and AI tools for AI. The best example is something like WebMCP vs the current method of screenshotting webpages and trying to find buttons inputboxes etc.

If we keep them separate, we can allow them to evolve to fully support each use case. Otherwise, the CLIs would soon start to include LLM-specific switches and arguments, e.g., to provide information in JSON.

Tools like awscli are good examples of there LLM can use a CLI. But then we need to remember that these are partly, if not mostly, intended for machine use, so CI/CD pipelines can do things.

Re: When does MCP make sense vs CLI?

#236

Post by kitd »

seemaze wrote: post #223
closeparen wrote: post #219

Earlier quoted context omitted.

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’..

Be careful. I'm pretty sure my wife is going to leave me for Claude any day now.

Re: When does MCP make sense vs CLI?

#237

Post by baruch »

stldev wrote: post #131

I've found MCP is great for stacking claude code instances- https://github.com/cduerr/stewardmcp has legit been a useful tool for me, and more reliable than handing a single instance 100k lines of code over a dozen repos.

Isn't that handled pretty well these days with sub agents? They can research the code without polluting the context.

Re: When does MCP make sense vs CLI?

#238

Post by D-Machine »

seemaze wrote: post #223
closeparen wrote: post #219

Earlier quoted context omitted.

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’..

Because "him" is objectively wrong, under almost any interpretation of any words involved. You can cause Claude, or any text-based LLM, to emit language that matches almost any personality / gender / character in the training set. At best you might be able to say "the default outputs have a masculine tone / vibe", but this still doesn't justify, by modern discourse, the "him".

Re: When does MCP make sense vs CLI?

#239

Post by bartek_gdn »

ejholmes wrote: post #89
bartek_gdn wrote: post #87

I've come to the same conclusion as op, created a CLI tool to work with Chrome sessions. It works well, and I'm planning to do some token comparison on this vs an MCP approach. https://news.ycombinator.com/item?id=47207790

Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.

It does so many things though, very similar in the core though. I'm wondering what the token counts will be when I compare. Also the agent browser seems to support other browsers too, I only when with chromium

Re: When does MCP make sense vs CLI?

#240

Post by singularity2001 »

rcarmo wrote: post #123

This feels misguided. MCP is still one of the best ways to execute deterministic sub-flows (i.e., stepwise processes) and secure tooling that an LLM would either lose itself while executing or should never access directly.

state. i'm not sure if they had that in mind but one keyword that is important here is: state. Sure CLI tools can also affect state, but in MCP service it's somewhat more natural?
Post reply on HN