CLI vs MCP (IBM Technology)
climcpagentstoolingclaude-code
CLI vs MCP (IBM Technology)
Martin Keen (IBM) gives a more nuanced take on the CLI-vs-MCP debate than the partisan version in Printing Press (Nate Herk video). Conclusion: use both — CLI when commands map to the job, MCP when abstraction or governance justifies the cost.
Key claims
- CLI argument (echoes Printing Press): models trained on millions of CLI examples (Stack Overflow, man pages). Don't need a schema for
grep -norgit log. MCP injects every tool's schema into context at session start — a few thousand tokens before the agent does anything. - GitHub MCP server example: 80 tools, ~55,000 tokens of definitions injected on every session, even if you only need 1–2.
- CLI fails when the raw tool doesn't return what you need. Demo: fetching
modelcontextprotocol.io(a Next.js SPA).- MCP Fetcher (headless browser): single tool call, ~250 tokens, a few seconds, works.
- CLI curl approach: curl gets only the JS bundle (no rendered HTML). Agent then improvises — strips HTML, looks for embedded JSON, eventually writes a Python script to reverse-engineer Next.js's streaming format. Several minutes, 2,000+ tokens.
- "If the agent ever starts reverse-engineering a JavaScript framework just to read a webpage, that's a good sign it picked the wrong one."
- CLI wins when:
- File ops, git, text processing, scripts
- Knowledge already in training data
- Composability via pipes (MCP tool calls are independent)
- MCP wins when:
- Raw tool gap is wide (rendered web pages, complex APIs)
- Auth needed (OAuth tokens, channel IDs, refresh) — server manages it, agent just declares intent
- Per-user access control + audit trails — built into the protocol; very hard to bolt onto CLI later. Critical for org-level deployment.
- Verdict: not either/or. The best agents (and the user who prompts them) pick the right tool per job.
Cross-source resonance & contradictions
- Important nuance against Printing Press (Nate Herk video)'s CLI > MCP > API tier list. The Printing Press argument is largely about single-user, local dev workflows. IBM's argument adds enterprise/auth/audit dimensions where MCP wins. Both can be right in their own scope.
- Echoes Boris Cherny's "to the model, it's just tokens" view from Boris Cherny on Coding Is Solved (Sequoia AI Ascent) — Boris also says use whatever fits, MCP, CLI, computer use, doesn't matter.
- Confirms the GitHub-MCP-bloat anecdote that's becoming canonical in this discourse.
Cross-links
- IBM Technology · CLI vs API vs MCP (this source updates the comparison page)