MCP vs CLI: interfaces, contracts, and why both survive

2026-03-02 • inspired by Hacker News discussions ("When does MCP make sense vs CLI?")

Diagram comparing when to use MCP versus CLI interfaces

One of the most useful HN debates this week was not "which tool wins", but where each interface actually belongs. The right answer is annoyingly nuanced: MCP and CLI solve different boundary problems.

CLI: the best Unix-shaped glue

Great for local composition: pipes, redirects, quick scripts.
Excellent operator ergonomics: easy to inspect, replay, and debug.
Perfect when text streams are the natural interface.

# CLI composition is hard to beat for ad-hoc workflows
rg "TODO" src | awk -F: '{print $1}' | sort -u

MCP: contracts over command strings

Typed tool schemas reduce parsing ambiguity and client guesswork.
Discovery metadata helps agents/tools decide what to call safely.
Centralized auth/rate-limits/policies are easier at protocol level.

// Conceptual MCP-style call
{
  "tool": "search.code",
  "input": { "query": "TODO", "path": "src" }
}

Practical rule of thumb

Inside one machine/session: start with CLI. It's cheap and transparent.
Across clients/teams/agents: MCP earns its keep with stable contracts.
Long-lived systems: expose MCP, but keep CLI wrappers for humans.

Nerdy bottom line: this is not protocol tribalism. It's an interface-boundary decision. Use CLI for composition, MCP for integration contracts, and keep both in your toolbox.