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

11–20 of 301 posts

Re: When does MCP make sense vs CLI?

#11

Post by phpnode »

simianwords wrote: post #6
phpnode wrote: post #3

I don't doubt that CLIs + skills are a good alternative to MCP in some contexts , but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.

Why? The llm can install cli through apt-get or equivalent and non developers wouldn’t need to know

well I'm sure you can understand the dangers of that, and why that won't work if your app is hosted and doesn't run on users' local machines

Re: When does MCP make sense vs CLI?

#12

Post by sigmoid10 »

phpnode wrote: post #3

I don't doubt that CLIs + skills are a good alternative to MCP in some contexts , but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.

>we can expect it to get much better than it is today

Which is not a high bar to clear. It literally only got where it is now because execs and product people love themselves another standard, because if they get their products to support it they can write that on some excel sheet as shipped feature and pin it on their chest. Even if the standard sucks on a technical level and the spec changes all the time.

Re: When does MCP make sense vs CLI?

#13

Post by trollbridge »

phpnode wrote: post #8
orange_joe wrote: post #4

This doesn't really pay attention to token costs. If I'm making a series of statically dependent calls I want to avoid blowing up the context with information on the intermediary states. Also, I don't really want to send my users skill.md files on how to do X,Y & Z.

the article only makes sense if you think that only developers use AI tools, and that the discovery / setup problem doesn't matter

But that's the current primary use case for AI. We aren't anywhere close to being able to sanitise input from hostile third parties enough to just let people start inputting prompts to my own system.

Re: When does MCP make sense vs CLI?

#14

Post by krzyk »

orange_joe wrote: post #4

This doesn't really pay attention to token costs. If I'm making a series of statically dependent calls I want to avoid blowing up the context with information on the intermediary states. Also, I don't really want to send my users skill.md files on how to do X,Y & Z.

Why? MCP and CLI is similar here.

You need agent to find MCP and what it can be used for (context), similarly you can write what CLI use for e.g. jira.

Rest is up to agent, it needs to list what it can do in MCP, similarly CLI with proper help text will list that.

Regarding context those tools are exactly the same.

Re: When does MCP make sense vs CLI?

#16

Post by ako »

recursivedoubts wrote: post #9

MCP has one thing going for it as an agentic API standard: token efficiency The single-request-for-all-abilities model + JSON RPC is more token efficient than most alternatives. Less flexible in many ways, but given the current ReAct, etc. model of agentic AI, in which conversations grow geometrically with API responses, token efficiency is very important.

I've been creating a cli tool with a focus on token efficiency. Dont see why cli could not be as token efficient as mcp. The cli has the option to output ascii, markdown and json.

Re: When does MCP make sense vs CLI?

#17

Post by juanre »

Reports of MCP's demise have been greatly exaggerated, but a CLI is indeed the right choice when the interface to the LLM is not a chat in a browser window.

For example, I built https://claweb.ai to enable agents to communicate with other agents. They run aw [1], an OSS Go CLI that manages all the details. This means they can have sync chats (not impossible with MCP, but very difficult). It also enables signing messages and (coming soon) e2ee. This would be, as far as I can tell, impossible using MCP.

[1] https://github.com/awebai/aw

Re: When does MCP make sense vs CLI?

#19

Post by goranmoomin »

I can't believe everyone is talking about MCP vs CLI and which is superior; both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities. CLIs might be marginably better (LLMs might have been trained on common CLIs), but MCPs have their uses (complex auth, connecting users to data sources) and in my experience if you're using any of the frontier models, it doesn't really matter which tool calling format you're using; a bespoke format also works.

The difference that should be talked about, should be how skills allow much more efficient context management. Skills are frequently connected to CLI usage, but I don't see any reason why. For example, Amp allows skills to attach MCP servers to them – the MCP server is automatically launched when the Agent loads that skill[0]. I belive that both for MCP servers and CLIs, having them in skills is the way for efficent context, and hoping that other agents also adopt this same feature.

[0]: https://ampcode.com/manual#mcp-servers-in-skills

Re: When does MCP make sense vs CLI?

#20

Post by SOLAR_FIELDS »

recursivedoubts wrote: post #9

MCP has one thing going for it as an agentic API standard: token efficiency The single-request-for-all-abilities model + JSON RPC is more token efficient than most alternatives. Less flexible in many ways, but given the current ReAct, etc. model of agentic AI, in which conversations grow geometrically with API responses, token efficiency is very important.

But the flip side of this is that the tools themselves take up a ton of token context. So if you have one mcp it’s great but there is an upper bound that you hit pretty quick of how many tools you can realistically expose to an agent without adding some intermediary lookup layer. It’s not compact enough of a spec and doesn’t have lazy loading built into it
Post reply on HN