Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

51–60 of 301 posts

Re: When does MCP make sense vs CLI?

#51
As a counter argument to the kubectl example made in the article, I found the k8s MCP (https://github.com/containers/kubernetes-mcp-server) to be particularly usefuly in trying to restrict LLM access to certain tools such as exec and delete tools, something which is not doable out of box if you use the kubectl CLI (unless you use the --as or --as-group flags and don't tell the LLM what user/usergroup those are).

I have used the kk8s MCP directly inside Github Copilot Chat in VSCode and restricted the write tools in the Configure Tools prompt. With a pseudo protocol established via this MCP and the IDE integration, I find it much safer to prompt the LLM into debugging a live K8s cluster vs. without having any such primitives.

So I don't see why MCPs are or should be dead.

Re: When does MCP make sense vs CLI?

#53
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

What non developer would have apt installed on their device though

Re: When does MCP make sense vs CLI?

#54

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…

No, it really matters because of the impact it has on context tokens. Reading on GH issue with MCP burns 54k tokens just to load the spec. If you use several MCPs it adds up really fast.

Re: When does MCP make sense vs CLI?

#55
post #8

Earlier quoted context omitted.

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.

there's a whole world of AI tools out there that don't focus on developers. These tools often need to interact with external services in one way or another, and MCP gives those less technical users an easy way to connect e.g. Notion or Linear in a couple of clicks, with auth taken care of automatically. CLIs are never replacing that use case.

Re: When does MCP make sense vs CLI?

#56

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…

No, it really matters because of the impact it has on context tokens. Reading on GH issue with MCP burns 54k tokens just to load the spec. If you use several MCPs it adds up really fast.

Verbosity of the output seems orthogonal to the cli vs mcp distinction? When I made mcp tools and noticed a lot of tokens being used, I changed the default to output less and added options to expose different kinds of detailed info depending what the model wants. CLI can support similar behavior.

Re: When does MCP make sense vs CLI?

#57
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.

This is excessively cynical, it's a useful tool despite its shortcomings.

Re: When does MCP make sense vs CLI?

#59

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.

Right, but even if this is just a matter of "chasing a trend", it does have a network effect and makes the entire MCP ecosystem much more useful to consumers, which begets more MCP servers.
Post reply on HN