Forget MCPs, Use CLI Tools Instead.

Kenny Chou · March 25, 2026

When Anthropic released the Model Context Protocol in late 2024, the developer world declared it the “USB-C for AI” — a universal connector between language models and any tool or data source. Within months, thousands of MCP servers appeared on registries. Every SaaS company rushed to ship one. The ecosystem exploded.

Now the tide is turning. Influential developers are ripping out their MCP servers and going back to something they’ve relied on for decades: the humble CLI.

TL;DR

  • MCP’s core problem is token bloat: tool schemas consume enormous chunks of the context window before an agent sees a single user message
  • Garry Tan (YC President), Denis Yarats (Perplexity CTO), and Peter Steinberger (OpenClaw Creator) have all publicly criticized MCP and moved away from it
  • Thoughtworks (tech consultancy) placed “naive API-to-MCP conversion” in the Hold ring of their Technology Radar (Nov 2025)
  • LLMs are already deeply trained on CLI interactions — they can self-document with --help and need no schema
  • CLI tools built as direct MCP replacements have emerged: gstack, Playwright CLI, and the existing gh (GitHub CLI)
  • MCPs still have a place: SaaS products without CLIs, multi-tenant auth, and stateful workflows. If you must use MCPs, consider using tools that make them behave more like a CLI tool or an API call.

Table of Contents

The Promise

MCP was designed to solve a real problem. Before MCP, connecting an AI agent to an external tool meant custom integration code for every combination. MCP proposed a standard: a JSON-RPC protocol over stdio or HTTP that any model could use to call any tool. Build one MCP server per tool, and every agent gets it for free.

The analogy to USB-C was apt. It promised interoperability. And in terms of adoption, it succeeded spectacularly — as of Q1 2026, there are over 17,000 MCP servers indexed across major registries, and OpenAI, Google, Microsoft, and AWS have all adopted the protocol [1].

But adoption and usefulness are not the same thing.

The Backlash

The criticism has come from some of the most credible voices in the industry.

A post titled “MCP is dead. Long live the CLI” hit #1 on Hacker News on February 28, 2026 with ~300 comments [15]. The contributor, Eric Holmes, argued that LLMs are already expert at tools like git, docker, and kubectl — so why build a new abstraction on top of them? “I’ve lost count of the times I’ve restarted Claude Code because an MCP server didn’t come up.” CLI tools are just binaries. They’re there when you need them and invisible when you don’t.

Peter Steinberger, creater of OpenClaw, echoed this sentiment back in January:

Denis Yarats, CTO and co-founder of Perplexity, announced at Ask 2026 (March 11, 2026) that Perplexity is moving away from MCP internally in favor of APIs and CLIs.His stated reason: MCP was consuming up to 72% of available context windows before an agent processed a single user message. Perplexity subsequently launched their Agent API — a single REST endpoint with built-in tools — as their preferred interface [3].

Prominant industry voices echoed in concurrance. Garry Tan, President and CEO of Y Combinator, put it bluntly on X — and the frustration led directly to building gstack’s browser CLI.

“I got sick of Claude in Chrome via MCP and vibe coded a CLI wrapper for Playwright tonight in 30 minutes only for my team to tell me Vercel already did it lmao

But it worked 100x better and was like 100LOC as a CLI”

Paweł Huryn, author of The Product Compass (the #3 product management newsletter on Substack with 106K+ subscribers), offered a more measured but equally pointed take: “His reasons are real: tool schemas eat context tokens, auth is clunky, and most MCP features go unused anyway.”

Thoughtworks weighed in institutionally. The global software consultancy publishes a biannual Technology Radar — a report where their senior engineers document patterns and techniques observed across hundreds of client engagements. It’s one of the more credible signals in the industry because it reflects real production experience rather than vendor marketing. Their Vol. 33 (November 2025) placed “naive API-to-MCP conversion” in the Hold ring — their designation for techniques teams should avoid [6]. “There has been a rush to convert APIs to MCP servers, which raises serious issues from both a security and efficiency perspective.”

Key takeaway: This isn’t just hobbyist frustration. The criticism is coming from YC’s president, a major AI company’s CTO, and a top engineering consultancy — all pointing to the same underlying problems.

Why MCPs Break in Practice

The problems cluster around three root causes.

1. Token Bloat

Every MCP server dumps its entire tool schema into the context window at session start. The schemas include parameter types, descriptions, enum values, nested objects, and usage examples — all necessary for the model to know what a tool does, but enormously expensive in tokens.

Real-world measurements are stark:

Task CLI tokens MCP tokens
Check repo language (gh vs GitHub MCP) 1,365 [8] 44,026 [8]
Browser automation (Playwright) ~27,000 [9] ~114,000 [9]
Session start* — GitHub MCP alone ~55,000 (93 tool defs) [7]
Session start* — 3 servers (GitHub + Slack + Sentry) 143,000 of 200,000 (72%) [3]

*Session start = tokens consumed by tool schema definitions loaded before the user sends a single message.

Try it yourself: Start a fresh Claude Code session and run /context. The “MCP tools” line shows exactly how many tokens your servers are consuming before you’ve said a word. Scott Spence measured his setup at 66,000 tokens consumed at conversation start — GitHub MCP alone accounting for 55,000 [7] [14].

This isn’t a configuration problem — it’s structural. MCP requires the schema to be transmitted at every session, regardless of how many tools the agent will actually use.

Cloudflare ran into this head-on. Their API has 2,500 endpoints — a native MCP implementation would consume ~244,000 tokens, exceeding most models’ entire context window. Their solution, which they called “Code Mode” [18], keeps MCP for discovery but replaces tool-calling with code generation: the model writes code against a typed SDK and executes it directly. The result: 2,500 endpoints covered by 2 tools and ~1,000 tokens.

2. Auth Friction

MCP servers need to handle authentication. For a CLI tool, auth is already solved: you run gh auth login once, and the token lives in your OS credential store. For an MCP server, you need to implement an auth flow that works within the JSON-RPC protocol, often requiring custom solutions that are neither standard nor audited.

Holmes put it directly: “MCP is unnecessarily opinionated about auth. Why does a protocol for giving an LLM tools to use need to concern itself with authentication?”

3. Reliability and Quality

MCP servers are background processes. They can fail to start, hang, produce no output, or drop connections mid-session. The MCP registry has what one developer described as “the same quality problem as the npm registry circa 2016 — quantity does not imply reliability.” [10]

Security researchers have found thousands of misconfigured MCP servers publicly accessible on the internet, with vulnerabilities including tool shadowing (one MCP server hijacking another’s behavior) and prompt injection through tool output [11].

Key takeaway: MCP’s token overhead is structural, not configurable. A three-server setup can consume 72% of your context window before you type a word.

Why LLMs Are Already Good at CLIs

The CLI alternative works because of something MCP cannot replicate: training data.

Modern LLMs have been trained on billions of lines of terminal interactions, shell scripts, and documentation pages. When you ask Claude to use git, docker, az, kubectl, or gh, you’re activating deeply learned patterns — not sending a schema it needs to parse.

Self-documentation: Give a coding agent shell access and point it at a CLI it’s never seen before. It runs --help, reads the output, and starts using the tool correctly. No schema required. MCP has no equivalent mechanism.

No overhead: A CLI invocation adds zero tokens to the context window before the agent acts. The tool schema overhead that makes MCP expensive simply doesn’t exist.

No daemon: CLI tools are stateless binaries. There’s nothing to start up, nothing to keep alive, and nothing to restart when it hangs.

Key takeaway: LLMs don’t need MCP to use tools effectively. For tools with good CLIs, the CLI is already the best interface.

CLI Tools Built to Replace MCPs

The movement has produced concrete alternatives.

gstack (★ 10,000+ in 48 hours)

Garry Tan’s gstack [5] is a set of specialized workflows and skills that roleplays a team of opinionated YC advisors. gstack surpassed 10,000 GitHub stars in its first 48 hours after open-source release.

An often overlooked aspect of this repository is its browser CLI — a compiled Bun binary that talks to a persistent local Chromium daemon over HTTP. You get a real browser with real clicks and real screenshots at ~100ms per command, invoked like any other shell tool. No MCP server, no JSON schema, no background process to babysit — the daemon manages itself and shuts down after 30 minutes of idle time.

This is a direct answer to the Playwright MCP problem: instead of streaming entire accessibility trees into the model’s context window, the CLI prints only what the agent asked for to stdout. Plain text, token-efficient, debuggable with echo.

Playwright CLI (official Microsoft alternative)

Microsoft launched Playwright CLI in early 2026 as an explicit companion to — and replacement for — the Playwright MCP server [9]. Rather than streaming accessibility trees and screenshot bytes into the model’s context (as MCP does), Playwright CLI saves everything to disk and lets the agent read only what it needs.

The result: 4× token reduction. A typical browser automation session costs ~27,000 tokens with the CLI versus ~114,000 with MCP. Some users report 10× gaps on longer sessions.

GitHub CLI (gh)

The gh CLI already does everything the GitHub MCP server does — and agents already know how to use it. Community consensus has converged: “prefer using gh over this MCP,” as one developer forum put it [12]. A comparison of the same task shows MCP using 32× more tokens than gh for identical results.

Perplexity Agent API

Perplexity replaced their MCP-based tooling with a single REST endpoint that routes to models from OpenAI, Anthropic, Google, xAI, and NVIDIA with built-in tools like web search. One API key, OpenAI-compatible syntax, no schema overhead [3].

The Existing CLIs You Already Have

For the major cloud and DevOps tools, MCP servers have been built — but they mostly reimplement what the official CLI already does. The agents already know how to use these tools natively. One real-world comparison found a 35× token reduction when switching from MCP to CLI for identical tasks [13]:

Tool MCP server exists? Better approach
GitHub Yes (official) gh CLI — agents know it deeply, 32× fewer tokens
AWS Yes (AWS Labs) aws CLI — already in training data
Kubernetes Yes kubectl — battle-tested, zero schema overhead
Docker Yes docker CLI — universally understood
Terraform Yes (HashiCorp) terraform CLI — though MCP adds live registry docs

The pattern: if the vendor shipped a CLI before they shipped an MCP server, default to the CLI.

Key takeaway: The alternatives aren’t theoretical — they’re shipping and gaining traction fast. And in many cases, you already have them installed.

Where MCPs Still Win

This isn’t an argument to abandon MCP entirely. There are cases where it remains the right tool:

  • SaaS products without a CLI — there’s simply no CLI to use
  • Multi-tenant auth (OAuth per user) — MCP handles per-user auth flows better than CLI credential stores
  • Stateful, long-running sessions — MCP maintains connection state across interactions
  • Sandboxed environments — when the agent has no shell access, MCP is the only option

What I’m cautioning against is treating it as the default answer for every AI integration, which the industry did in 2025. As Thoughtworks put it: the antipattern is naive API-to-MCP conversion, not MCP itself.

clihub — compile any MCP server into a CLI binary

If you must use an MCP, consider adopting clihub. It compiles an MCP server into a standalone CLI binary. Every tool the server exposes becomes a subcommand with flags derived from its JSON Schema. Auth is handled automatically. The generated binary has no runtime dependencies — no config files, no clihub needed at runtime.

This matters for the “SaaS without a CLI” problem. If you’re stuck with an MCP server you can’t replace, clihub gives you the token efficiency of a CLI without rewriting anything.

The Bottom Line

MCP solved a real problem and succeeded at achieving adoption. But the ecosystem over-indexed on it, and the costs are now visible: context windows consumed before a single message, auth friction that adds no security value, background processes that crash, and servers of wildly varying quality.

For tools with solid CLIs — GitHub, Docker, cloud providers, databases — the CLI is already the better interface. LLMs know how to use it, it’s zero overhead, and it doesn’t require a persistent server.

The pattern emerging from gstack, Playwright CLI, and the broader developer community points in one direction: treat MCP as a specialized tool for specific cases, not a default layer for all AI integrations. Reach for the CLI first.

References

  1. MCP’s 2026 Roadmap — WorkOS
  2. MCP is dead. Long live the CLI — Eric Holmes
  3. Perplexity CTO Moves Away from MCP — Awesome Agents
  4. Garry Tan on MCP — X
  5. gstack — GitHub
  6. Technology Radar Vol. 33 — Thoughtworks
  7. Optimising MCP Server Context Usage — Scott Spence
  8. MCP vs CLI: Benchmarking — Mario Zechner
  9. Playwright MCP Burns 114K Tokens — ScrollTest
  10. The MCP Server Crisis — DEV Community
  11. MCP vs CLI: What Perplexity’s Move Means — Repello AI
  12. gh vs MCP Comparison — SmartScope
  13. MCP vs CLI: Benchmarking AI Agent Cost & Reliability — Scalekit
  14. Claude Code /context Command: See Where Your Tokens Go — JD Hodges
  15. MCP is dead; long live MCP — Hacker News
  16. Pieter Levels on MCP — X
  17. Paweł Huryn on Perplexity’s MCP move — X
  18. Code Mode: give agents an entire API in 1,000 tokens — Cloudflare
  19. clihub — Turn any MCP server into a CLI binary — GitHub

Further Reading