Yesterday, Garry Tan tweeted that "MCP sucks honestly".
He cites two concerns with MCP: context-window bloat and bad authentication. Specifically, it was a quote tweet reporting on how Denis Yarats, CTO of Perplexity, announced that they're transitioning from MCPs to APIs/CLI.
These criticisms of MCP aren't new. However, they're misguided, poking blame at a flexible protocol instead of a poor implementation. APIs and CLI tools are, by design, the bare bones option. The goal of MCP, meanwhile, is to improve agent success when integrating with third-party products, enabling agents to think independently.
Two myths about MCP (and a CLI fact)
Myth: "MCP eats too much context window"
If your MCP implementation is eating too much of your context window, then you have a poor harness. A naive implementation of MCP is shoving all tool calls into a window. The protocol technically allows for that, but it's the equivalent of creating a single API route where copious meta-parameters are needed to steer the request.
MCP's context cost becomes extremely manageable with a single-tool MCP architecture. Instead of loading dozens of tool schemas into context, you expose one tool that accepts input in a familiar programming language like Python or JavaScript. The agent generates code in a language it was trained on rather than guessing newline placement or shell argument sequences. This keeps context lean and avoids the composition issues that arise from handling multiple tools. Because MCPs are inherently stateful, this setup lets the agent retain variables, ongoing sessions, and cached results that build domain knowledge over time.
CLIs meanwhile have an actual context window issue. They are hardly zero context, requiring --help flags and documentation.
Rhys Sullivan made a great point in response:
CLIs might appear simple, but they don't escape the same criticisms levied on poor MCP implementations. And with CLIs, you're building something less capable and less composable, justifying it by just calling it simpler.
Myth: CLI is simpler to set-up
CLIs are easy to set-up in the short-run. If you are a single developer working on a side-project, then using a CLI and stitching it together with Claude Code is likely the move.
However, for companies with hundreds of engineers, depending on CLI tools is not scalable. You'll have dozens to hundreds of CLI tools installed across thousands of machines with no central visibility into what's being called and by whom. Robust permissions systems suddenly lost hold with CLI.
MCP provides a single surface with auditable and controllable authentication and authorization. CLI tools do not and APIs are, often by design, limited at extending complex permissions.
Fact: CLIs break agents in production
The “simplicity” of CLIs also ignores a fundamental issue: CLI tools were designed for humans, not agents. What a human can easily infer becomes a major source of failure for an AI agent.
Agents do not treat all CLIs the same. Popular tools like the GitHub CLI work well because agents were trained on them. But internal CLIs lack that familiarity and good documentation, leading agents to improvise interactions that produce cascading failures. This is amplified by CLIs that depend on non-ASCII strings or unconventional arguments, which models frequently mishandle. Even small models can struggle to consistently transmit newline characters through shell arguments, causing repeated execution failures (even Claude Code, an incredibly well-designed product, struggles with this).
Multi-step workflows make it worse. It's difficult to maintain state across commands. Due to failures, agents often restart from scratch or stop using the tool entirely. Consider a simple request: build a backend image, run it, exec into the container, and create a database user. If the build fails, the agent often ignores the error and moves on. Then the run fails because the image doesn't exist. Then exec fails because the container never started. Then the database command fails because earlier steps never succeeded.
A single-tool MCP sidesteps this entirely. Instead of chaining fragile shell commands, the agent writes in a language it knows, maintains state between calls, and composes operations into reusable scripts.
Why is MCP best for enterprises at scale?
MCP excels at Auth
Garry Tan believes that MCP has poor auth. But MCP has strong auth. It just looks more cumbersome because it's doing more.
CLI relies on long-lived API keys or user:password combos baked into config files. MCP meanwhile implements auth via OAuth with scoped, revocable tokens. Long-lived API keys create incidents, especially after employees move to new organizations or stay long enough to have their machine exploited. Additionally, giving an agent CLI access is equivalent to giving it full user access with no way to limit certain commands or track request sequences. Untrusted input can prompt-inject the agent, and once compromised, it can run any CLI command with potentially disastrous consequences.
But in an MCP setup, a security layer like Runlayer can analyze input before executing any commands. CLI alone gives you no structured interception point.
Enterprise controls are nearly impossible with CLIs
It's significantly harder to enforce enterprise-grade access controls over CLI calls. MCP, meanwhile, provides a structured layer to apply RBAC, audit logging, and policy enforcement. David Soria Parra, co-creator of MCP, said it best:
"No enterprise would want a set of CLIs on users' machines without a common logging and introspection mechanism."
Non-technical users can't use CLIs
MCP with OAuth is the only path for business users (GTM, finance, ops teams) to use agents. At many companies, non-technical employees are actually driving agent adoption at scale.
Conversely, they don't have the skillset to operate CLIs. They need one-click connectors and a dashboard. In fact, the OpenClaw developer, despite being vocal about CLI over MCP, still used MCPs via mcporter.
Closing thought: our position
We're not anti-CLI. Soon, we will support any agent execution mode via hooks, including full conversation capture for CLI calls.
But CLI at enterprise scale will still need MCP underneath for auth and controls. The Runlayer CLI itself can pull MCPs as code. It's not either/or at the protocol level. But CLI lacks a governance layer and that doesn't work for real companies.