Draft
TL;DR
A contrarian take: instead of adopting MCP everywhere, treat the
CLI as the universal tool interface for agents—it’s
debuggable, composable, and already “native” to how LLMs learned to
operate.
What this is about
The post argues MCP adds a new layer of complexity (servers,
lifecycle, transport logs, auth wrappers) for many tasks that already
have a solid interface: command-line tools. LLMs have seen endless
examples of shell usage, man pages, and scripts, so giving them a CLI
often works immediately.
Key points
- Debuggability: humans and agents can run the
same command to reproduce issues. - Composability: pipes/filters/redirection
(|,jq, files) are a mature ecosystem. - Auth: many CLIs already integrate with common auth
flows (SSO, profiles, kubeconfigs). - Reliability: binaries are often simpler than
long-running protocol servers. - The author still concedes MCP can help when there’s no good
CLI equivalent.
Why it matters
This is really a debate about where “tool semantics” should live: –
In a dedicated protocol/schema layer (MCP), or – In the existing human
tool interface (CLI) with decades of iteration.
For builders, the practical implication is: ship the interface that
is easiest to operate, audit, and debug under real production
constraints.
Practical takeaways
- If you’re building tools for agents, consider shipping a
first-class CLI even if you also expose an API. - For safety/permissions, CLIs can enable granular
allowlisting (read vs write commands) when paired with
policy. - If you do adopt protocol servers, invest in operational maturity:
lifecycle, logging, auth, and versioning.
Caveats / what to watch
- CLIs aren’t always ideal for high-throughput machine-to-machine
calls. - Schemas/protocols can reduce ambiguity and improve
validation—especially for complex structured inputs.