When does MCP make sense vs CLI?

Original Article ↗ Hacker News Discussion ↗

Overall framing

  • Thread debates when to use Model Context Protocol (MCP) vs CLI + skills as the main tool interface for LLM agents.
  • Most agree both are just tool‑calling mechanisms; the real tradeoffs are around composability, security, auth, context cost, and who the end user is.

Arguments favoring CLI + skills

  • Excellent for developer‑centric, local agents (terminal IDEs, OpenClaw‑style): models already “know” common Unix tools, curl, jq, gh, etc.
  • Strong composability: pipes, filters, redirects, scripts, and chaining multiple tools is natural; MCP calls are typically non‑composable and single‑shot.
  • Easy debugging: humans can re‑run the exact command and see the same output.
  • No extra always‑on server or protocol to manage; can wrap REST/APIs with a thin CLI and describe it via skills/markdown.

Arguments favoring MCP

  • Better fit for non‑technical users in chat UIs: click‑to‑connect services (email, Jira, Notion, Sentry, calendars, design systems, Figma) with OAuth handled consistently.
  • Works when the agent has no shell or cannot install binaries (web/mobile agents, hosted backends, 3rd‑party platforms).
  • Provides a machine‑readable tool schema (args, types, read vs write) and centralized policy: easier to expose only safe, read‑only or limited tools.
  • Useful encapsulation unit in enterprise: can be turned into microservices, service‑mesh components, or internal “agent gateways”.

Token and context tradeoffs

  • Pro‑MCP view: single JSON‑RPC interface with explicit schemas can be token‑efficient and reduce hallucinated flags/arguments.
  • Anti‑MCP view: large tool specs (e.g., GitHub/Jira/Playwright) burn tens of thousands of tokens; multiple MCPs quickly exhaust context and bust prompt caches.
  • Skills + CLI can load instructions only when needed; some see that as strictly more efficient, others argue current MCP usage is just “held wrong” and could be fixed.

Security and governance

  • CLI critics: giving an LLM shell access, even in a container, complicates isolation and secrets handling; whitelisting commands robustly is hard.
  • MCP supporters: easier to define and enforce read/write boundaries, log calls, and avoid giving agents raw API keys; good fit for conservative enterprises.
  • Others counter that OS users, containers, and carefully designed CLIs can provide equivalent guardrails.

Adoption, UX, and hybrid patterns

  • Many note MCP server counts are rising, but some attribute this to trend‑chasing and marketing checkboxes.
  • Common pragmatic pattern: MCP for stateful, externally hosted, OAuth‑heavy services; CLI + skills for local files, build/test tools, data exploration, and scripting.
  • Several commenters predict the MCP vs CLI debate will fade as better context management, skills, and new protocols emerge.