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

21–30 of 301 posts

Re: When does MCP make sense vs CLI?

#21

Post by avaer »

goranmoomin wrote: post #19

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…

MCP vs CLI is the modern version of people discussing the merits of curly braces vs significant whitespace.

That is, I don't think we're gonna be arguing about it for very long.

Re: When does MCP make sense vs CLI?

#22

Post by rvz »

MCPs were dead in the water and were completely a bad standard to begin with. The hype around never made sense.

Not only it had lots of issues and security problems all over the place and it was designed to be complicated.

For example, Why does your password manager need an MCP server? [0]

But it still does not mean a CLI is any better for everything.

[0] https://news.ycombinator.com/item?id=44528411

Re: When does MCP make sense vs CLI?

#24

Post by vojtapol »

goranmoomin wrote: post #19

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…

MCP needs to be supported during the training and trained into the LLM whereas using CLI is very common in the training set already. Since MCP does not really provide any significant benefits I think good CLI tools and its use by LLMs should be the way forward.

Re: When does MCP make sense vs CLI?

#25

Post by wolttam »

ako wrote: post #18

Biggest downside of CLI for me is that it needs to run in a container. You're allowing the agent to run CLI tools, so you need to limit what it can do.

It gets significantly harder to isolate the authentication details when the model has access to a shell, even in a container. The CLI tool that the model is running may need to access the environment or some credentials file, and what's to stop the model from accessing those credentials directly?

It breaks most assumptions we have about the shell's security model.

Re: When does MCP make sense vs CLI?

#27

Post by lmeyerov »

krzyk wrote: post #14
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.

This feels right in theory and wrong in practice

When measuring speed running blue team CTFs ("Breaking BOTS" talk at Chaos Congress), I saw about a ~2x difference in speed (~= tokens) for a database usage between curl (~skills) vs mcp (~python). In theory you can rewrite the mcp into the skill as .md/.py, but at that point ... .

Also I think some people are talking past one another in these discussions. The skill format is a folder that supports dropping in code files, so much of what MCP does can be copy-pasted into that. However, many people discussing skills mean markdown-only and letting the LLM do the rest, which would require a fancy bootstrapping period to make as smooth as the code version. I'd agree that skills, when a folder coming with code, does feel like largely obviating MCPs for solo use cases, until you consider remote MCPs & OAuth, which seem unaddressed and core in practice for wider use.

Re: When does MCP make sense vs CLI?

#28

Post by bikeshaving »

I keep asking why the default Claude tools like Read(), Write(), Edit(), MultiEdit(), Replace() tools aren’t just Bash() with some combination of cat, sed, grep, find. Isn’t it just easier to pipe everything through the shell? We just need to figure out the permissions for it.

Re: When does MCP make sense vs CLI?

#29

Post by lakrici88284 »

AznHisoka wrote: post #23

In terms of what companies are actually implementing, MCP isnt dead by a long time. Number of companies with a MCP server grew 242% in the last 6 months and is actually accelerating (according to Bloomberry) [1] https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...

Companies are usually chasing last year's trend, and MCP makes for an easy "look, were adopting AI!" bullet point.

Re: When does MCP make sense vs CLI?

#30

Post by harrall »

SOLAR_FIELDS wrote: post #20
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

Yes but I consider that just a bug in the agents that use MCP servers.

It could just be fixed to compress the context or the protocol could be tweaked.

Switching to CLIs is like buying a new car because you need an oil change. Sure, in this case, the user doesn’t get to control if the oil change can be done, but the issue is not the car — it’s that no one will do the relatively trivial fix.

Post reply on HN