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

61–70 of 301 posts

Re: When does MCP make sense vs CLI?

#61

Post by bear3r »

ako wrote: post #16
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.

the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.

Re: When does MCP make sense vs CLI?

#62

Post by someguy101010 »

simonw wrote: post #58

MCP makes sense when you're not running a full container-based Unix environment for your agent to run Bash commands inside of.

yep! thats the motivation behind https://github.com/r33drichards/mcp-js

I want to be able to give agents access to computation in a secure way without giving them full access to a computer

Re: When does MCP make sense vs CLI?

#63

Post by sebast_bake »

The opposite is true. CLI based integration does not exist in a single consumer grade ai agent product that I’m aware of. CLI is only used in products like Claude Claude and OpenClaw that are targeting technically competent users.

For the other 99% of the population, MCP offers security guardrails and simple consistent auth. Much better than CLI for the vast majority of use cases involving non-technical people.

Re: When does MCP make sense vs CLI?

#64

Post by ejholmes »

Hi friends! Author here. This blew up a bit, so some words.

The article title and content is intentionally provocative. It’s just to get people thinking. My real views are probably a lot more balanced. I totally get there’s a space where MCP probably does actually make sense. Particularly in areas where CLI invocation would be challenging. I think we probably could have come up with something better than MCP to fill that space, but it’s still better than nothing.

Really all I want folks to take away from this is to think “hmm, maybe a CLI would actually be better for this particular use case”. If I were to point a finger at anything in particular, it would be Datadog and Slack who have chosen to build MCP’s instead of official CLI’s that agents can use. A CLI would be infinitely better (for me).

Re: When does MCP make sense vs CLI?

#65

Post by nextaccountic »

jeremyjh wrote: post #54
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…

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.

In the front page there's a project that attempts to reduce tje boilerplate of mcp output in claude code

Eventually I hope that models themselves become smarter and don't save the whole 54k tokens in their context window

Re: When does MCP make sense vs CLI?

#67

Post by ako »

bear3r wrote: post #61
ako wrote: post #16

Earlier quoted context omitted.

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.

the output format (ascii/json/markdown) is one piece, but the other side is input schema. mcp declares what args are valid and their types upfront, so the model can't hallucinate a flag that doesn't exist. cli tools don't expose that contract unless you parse --help output, which is fragile.

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.

Re: When does MCP make sense vs CLI?

#68

Post by sophiabits »

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…

> the MCP server is automatically launched when the Agent loads that skill

The main problem with this approach at the moment is it busts your prompt cache, because LLMs expect all tool definitions to be defined at the beginning of the context window. Input tokens are the main driver of inference costs and a lot of use cases aren't economical without prompt caching.

Hopefully in future LLMs are trained so you can add tool definitions anywhere in the context window. Lots of use cases benefit from this, e.g. in ecommerce there's really no point providing a "clear cart" tool to the LLM upfront, it'd be nice if you could dynamically provide it after item(s) are first added.

Re: When does MCP make sense vs CLI?

#69

Post by goranmoomin »

goodmythical wrote: post #36
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…

>as long as it provides the same capabilities. That's fine if you definition of capabilities is wide enough to include model understanding of the provided tool and token waste in the model trying to understand the tool and token waste in the model doing things ass backwards and inflating the context because it can't see the vastly shorter path to the solution provided by the tool and... There is plenty of evidence to…

> model understanding of the provided tool and token waste in the model trying to understand the tool and token waste in the model doing things ass backwards and inflating the context because it can't see the vastly shorter path to the solution provided by the tool and...

> But even then, throw them a tool they don't understand that has the same capabilities as a tool they do understand and you're going to burn a bunch of tokens watching it try to figure the tool out.

What I was trying to say was that this applies to both MCPs and CLIs – obviously, if you have a certain CLI tool that's represented thoroughly through the model's training dataset (i.e. grep, gh, sed, and so on), it's definitely beneficial to use CLIs (since it means less context spending, less trial-and-error to get the expected results, and so on).

However if you have a novel thing that you want to connect to LLM-based Agents, i.e. a reverse enginnering tool, or a browser debugging protocol adapter, or your next big thing(tm), it might not really matter if you have a CLI or a MCP since LLMs are both post-trained (hence proficent) for both, and you'll have to do the trial-and-error thing anyway (since neither would represented in the training dataset).

I would say that the MCP hype is dying out so I personally won't build a new product with MCP right now, but no need to ditch MCPs for any reason, nor do I see anything inherently deficient in the MCP protocol itself. It's just another tool-calling solution.

Re: When does MCP make sense vs CLI?

#70

Post by csheaff »

ejholmes wrote: post #64

Hi friends! Author here. This blew up a bit, so some words. The article title and content is intentionally provocative. It’s just to get people thinking. My real views are probably a lot more balanced. I totally get there’s a space where MCP probably does actually make sense. Particularly in areas where CLI invocation would be challenging. I think we probably could have come up with something better than MCP to fill…

Thank you for writing this. I've had similar thoughts myself and have been teetering back and forth between MCP and skills that invoke CLI. I'm hoping this creates a discussion that points to the right pattern.
Post reply on HN