Not for every situation. CLI is great for coding agents (and I'd agree, far better in most cases than MCP). But it requires some execution runtime somewhere to actually run. So for app use cases where you don't want to build out your own tools for every integration, MCP can be a solid option.
Also, in my opinion, it's much easier to build a good MCP interface than it is to build a good CLI interface - and afaik there's support for MCP tools to return things like images from an MCP tool call directly to the calling LLM that is a bit tricker to do via CLI.
There is definitely some debate going on on mcp/cli/api etc, but is quite obvious that mcp is being adopted as standard for integrating third party applications to the major clients => chatgpt apps, claude connectors, mistral, cursor etc.. they all connect to external apps using mcp. Of course it's possible for you to tell claude to use some cli directly but it's much easier to connect the mcp with one click
I've been sitting in the same camp recently. We maintain both an internal MCP and CLI for our app which our devs use locally. The CLI so far feels like a much smoother experience both in terms of setup, control and performance.
But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?
CLI certainly is better than local MCP. But nowadays, most MCPs are remote and the comparison fall short, at the notable exception of `gh` in a coding environment. But having CLI already authenticated is not guaranted either!
MCP makes a lot, lot more sense when you think of it as as a auth standard and not a comparison with CLIs. It obviously does more than just auth, but having standardised auth (which CLIs definitely do not) is the real 'killer' feature.
Yep, that was exactly my point with the ask to elaborate.
MCPs and CLIs feel like two wholly different things. Contrasting them feels even more confusing than comparing Skills vs MCPs, which would also be wrong in my personal view. Different runtime requirements, different access patterns, different distribution, different discoverability.
I agree with @martinanld that MCPs, especially with the advent of EMA, are a completely different beast thanks to a structured way for auth and access control.
I am so tired of people repeating this. Usually, this results from conflating two uses of MCP: local, which can indeed be replaced by CLI (and you can argue which one is better), and remote, which is entirely different, and there is no way to replace it with a CLI (note that you are making an implicit assumption that a CLI tool can be used at all, which is not always the case).
Please don't repeat this. It's like saying that apples are dead and oranges are the future.
Explain again why a cli can't access a remote service ?
The only difference that is not superficial is the token count. Everything else : format, doc, auth, discoverability, ... can be made the same (the cli could be an mcp client, and the mcp server could implement a local shell, after all)
> Tell me you don't understand what you're saying without telling me you don't understand what you're saying.
Please don't cross into personal attack, regardless of how wrong someone is or you feel they are.
Your comment would be fine without that last swipe, and even better if you had gone on to say what the two purposes are. Then we could learn something from it.