Live data from Hacker News

When does MCP make sense vs CLI?

ejholmes.github.io

91–100 of 301 posts

Re: When does MCP make sense vs CLI?

#91

This is like comparing OpenAPI and strings (that may be JSON). That is, weird, and possibly even meaningless. MCP is formally defined in the general sense (including transport protocols), CLI is not. I mean, only specific CLIs can be defined, but a general CLI is only `(String, List String, Map Int Stream) -> PID` with no finer semantics attached (save for what the command name may imply), and transport is “whatever…

CLI tools are designed to provide complete documentation using —help. Given LLMs are capable of fully understanding the output then how is the MCP standardization any better than the CLI —help standardization?

Re: When does MCP make sense vs CLI?

#92

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

Fully agree.

MCP servers were also created at a time where ai and llms were less developed and capable in many ways.

It always seemed weird we'd want to post train on MCP servers when I'm sure we have a lot of data with using cli and shell commands to improve tool calling.

Re: When does MCP make sense vs CLI?

#94

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…

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

MCP tool calls aren't composable. Not the same capabilities. Big difference.

Re: When does MCP make sense vs CLI?

#97
Very good points, but, I think this blog is pretty focussed on the developer use case for LLMs. It makes a lot more sense in chat style interfaces for connecting to non-dev tools or services with non technical users, if anything just from a UX perspective.

Re: When does MCP make sense vs CLI?

#98
post #35

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.

Making those tools first-class primitives is good for (human) UX: you see the diffs inline, you can add custom rules and hooks that trigger on certain files being edited, etc.

I’ve found that humans are pretty good at reading through the output of bash commands. And Claude Code keeps insisting on truncating the output for some reason.

Re: When does MCP make sense vs CLI?

#99

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process…

Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.

MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.

Re: When does MCP make sense vs CLI?

#100

This is like comparing OpenAPI and strings (that may be JSON). That is, weird, and possibly even meaningless. MCP is formally defined in the general sense (including transport protocols), CLI is not. I mean, only specific CLIs can be defined, but a general CLI is only `(String, List String, Map Int Stream) -> PID` with no finer semantics attached (save for what the command name may imply), and transport is “whatever…

I would spend less time with theory and more time with practice to understand what people are getting at. MCP and CLI could, in theory, be the same. But in practice as it stands today, they are not.

> MCP is just a way to write this in a structured way,

Nope! You are not understanding or are actively ignoring the difference which has been explained by 20+ comments just here. It's not a controversial claim, it's a mutually agreed upon matter of fact by the relevant community of users.

The claim you're making right now is believed to be false, and if you know something everyone else doesn't, then you should create an example repo that shows the playwright CLI and playwright MCP add the same number of tokens to context and that both are equally configurable in this respect.

If you can get that right where so many others have failed, that would be a a really big contribution. And if you can't, then you'll understand something first-hand that you weren't able to get while you were thinking about theoretically.

Post reply on HN