When does MCP make sense vs CLI?

lukol

Couldn't agree more. Simple REST APIs often do the job as well. MCP felt like a vibe-coded fever dream from the start.

phpnode

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.

orange_joe

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.

CuriouslyC

There's been an anti-MCP pro-CLI train going for a while since ~May of last year (I've been personally beating this drum since then) but I think MCP has a very real use case. Specifically, MCP is a great unit of encapsulation. I have a secure agent framework ( https://github.com/sibyllinesoft/smith-core ) where I convert MCPs to microservices via sidecar and plug them into a service mesh, it makes securing agent capabilities really easy by leveraging existing policy and management tools. Then agents can just curl everything in bash rather than needing CLIs for everything. CLIs are still slightly more token efficient but overall the simplicity and the power of the scheme is a huge win.

mt42or

I remember this kind of people against Kubernetes the same exact way. Very funny.

recursivedoubts

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.

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

ako

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.

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

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

AznHisoka

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

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.

p_ing

Tell my business users to use CLI when they create their agents. It's just not happening. MCP is point-and-click for them. MCP is far from dead, at least outside of tech circles.

lasgawe

I don't know about this. I use AI, but I've never used or tried MCP. I've never had any problems with the current tools.

dnautics

what honestly is the difference between an mcp and a skill + instructions + curl. Really it seems to me the difference is that an mcp could be more token-efficient, but it isn't, because you dump every mcp's instructions all the time into your context. Of course then again skills frequently doesn't get triggered. just seems like coding agent bugs/choices and protocol design?

Nevin1901

This is actually the first use case where I agree with the poster. really interesting, especially for technical people using ai. why would you spend time setting up and installing an mcp server when u can give it one man page

ddp26

I don't understand the CLI vs MCP. In cli's like Claude Code, MCPs give a lot of additional functionality, such as status polling that is hard to get right with raw documentation on what APIs to call.

whatever1

First they came for our RAGs, now for our MCPs. What’s next ?

the_mitsuhiko

> OpenClaw doesn’t support it. Pi doesn’t support it. It's maybe not optimal to conclude anything from these two. The Vienna school of AI agents focuses on self extending agents and that's not really compatible with MCP. There are lots of other approaches where MCP is very entrenched and probably will stick around.

mudkipdev

This got renamed right in front of my eyes