Prefer CLI When Available

Diving deeper into

Zach Lloyd, CEO of Warp, on the 3 phases of AI coding

Interview
if there is already a CLI, there is not a strong reason to use MCP
Analyzed 5 sources

This points to a simple hierarchy in agent tooling, use the CLI when a system already exposes clean text commands, and use MCP when the system does not. A CLI already gives an agent named commands, flags, outputs, and years of docs, so the model can act immediately with little extra plumbing. MCP matters more when the target system is a GUI app or SaaS product, like Figma or GitHub, where the agent needs structured access to data and actions that do not naturally live in a shell.

  • Warp sees this directly in product usage. Even though Warp supports MCP and users connect third party servers such as GitHub and Figma, the dominant tool category is still CLI apps because they are fast, configurable, and already fit how models operate, which is reading and writing text.
  • Momentic describes the same distribution pattern from the other side. The practical requirement is to meet developers inside local workflows, in the IDE, on localhost, in GitHub, and in pull requests. That is why many developer tools ship both a CLI and an MCP surface rather than betting on MCP alone.
  • The broader implication is that MCP adoption will come first in domains that never had a good command line surface. Anthropic defines MCP as a standard way to connect models to tools and data sources. Figma uses it to expose design files, variables, and selected frames to coding agents, which a normal shell command was never built to represent well.

The next step is not MCP replacing CLIs. It is MCP filling the gaps around them. In developer workflows, the winning pattern is likely a mixed stack where CLIs handle execution in code and infrastructure, while MCP connects agents to design tools, SaaS systems, and shared organizational context that sits outside the terminal.