I think that's a fair argument. I'd push back a bit on that being unique to MCP. Agent browser (https://github.com/vercel-labs/agent-browser) handles persistent sessions just fine as a CLI.
Readit Newsejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
They make a big difference. For example if you use the Jira cli, most LLMs aren’t trained on it. A simple MCP wrapper makes a huge difference in usability unless you’re okay having the LLM poke and prod a bunch of different commands
Silly. All it needs is docs. No need to overcomplicate it.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
I hate MCP servers
That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems.
But that's not what happened.
Developers and Anthropic got coked up about the whole thing and extended the concept to nuts and bolts. I always found the example servers useless and hilarious.[0] Unbelievably, they're still maintained.
[0]: https://github.com/modelcontextprotocol/servers/tree/main/sr...
I always get a kick out of seeing MCP wrappers around CLI’s.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
YES, I have been thinking the same and wrote a bit about it: https://vizzly.dev/blog/cli-json-output-llm-friendly/
Thank you so much to the GH CLI for making me realize this, really. The only MCPs I use still are ones that don’t have CLIs. Hell, I even just wrote a CLI for Bear Notes, for LLMs. It’s just better.
Seems like the last MCP use case is model to model communication but I’m sure others have approach’s for that?
Great read. Thanks for sharing. 100% agree, `—json | jq` is where it’s at.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
If the author is just using Claude Code on their own personal computer, they can do whatever they want.
As soon as there is a need to interact with the outside world in a safe, controlled manner at enterprise scale, the limitations of CLI quickly become obvious.
I wish people get more informed about a subject before they write a long blog post about it.
You're right, but it still doesn't mean MCP was a good design even in that space. We could've done better.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
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 they're not token efficient. Take the terraform example from the post. Plan JSON is massive. You're not saving tokens by using a Terraform MCP and shoving an entire plan into context. Composition allows for efficient token use.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
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.
> 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.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
I've come to the same conclusion as op, created a CLI tool to work with Chrome sessions. It works well, and I'm planning to do some token comparison on this vs an MCP approach. https://news.ycombinator.com/item?id=47207790
Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.
ejholmes commented on When does MCP make sense vs CLI? ejholmes.github.io/2026/0... · Posted by u/ejholmes
> 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 that needs babysitting.
the composability argument is the one that should end this debate tbh. you can pipe CLI output through jq, grep it, redirect to files - try doing that with MCP. you can't. you're stuck with whatever the MCP server decided to return and if it's too verbose you're burning tokens for nothing.
> companies scrambled to ship MCP servers as proof they were "AI first"
FWIW this is the real story. MCP adoption is a marketing signal not a technical one. 242% growth in MCP servers means nothing if most of them are worse than the CLI that already existed
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.