MCP vs CLI: You're Asking the Wrong Question

There's a debate running through the agent ecosystem that sounds important but is mostly a distraction. On one side: MCP is the future, structured tool invocation is how agents operate at scale, CLI is a hack. On the other: CLI is universal, battle-tested, you're overthinking this.

Both camps are partially right. Neither is asking the right question.

The question isn't which one wins. It's: which loop are you building for?

CLI: the inner loop default

CLI works. That's not up for debate. Every tool already speaks the language, it composes naturally, it's scriptable without a spec or a handshake, and the ecosystem is enormous. For a single agent doing inner-loop work (local dev, tight iteration, fast feedback) CLI is a reasonable default. It's the same reason developers reach for shell scripts before building a service: when the scope is small and the audience is one, the overhead of structure isn't worth it.

It breaks down when you try to push inner-loop tooling into outer-loop problems.

CLI has no strongly typed inputs or outputs. The schema lives in documentation, not in the interface. And that schema can change with every version of the tool. What a command returns in v2.1 might look nothing like what it returned in v1.8. For a human reading a terminal, that's annoying. For an agent, it's a silent regression that compounds across every tool in the stack.

Teams often reach for CLI because it seems leaner, cheaper on tokens. But when your agent is burning tokens recovering from format changes, retrying on unexpected output, or hallucinating structure that no longer matches the current version, the savings are already gone. The brittleness is the cost.

MCP: built for the outer loop

MCP is what you reach for when you're building for the outer loop. Multiple agents, multiple systems, multiple teams operating against shared interfaces in production. The inner loop is about speed. The outer loop is about coordination.

The strong typing isn't bureaucratic overhead. It's what makes coordination possible. Structured inputs, structured outputs, clear error semantics, runtime discoverability. An agent can introspect an MCP server and understand what it can do without reverse-engineering output formats or trusting that the docs are current. In a multi-agent workflow, one badly typed interface breaks everyone downstream. MCP eliminates that failure mode by design.

The shift to runtime capability discovery also matters more than it first appears. You're not hardcoding tool knowledge into prompts anymore. The agent learns what's available from the server itself. At scale, across a fleet of agents working across different systems, that's the difference between a system you can extend and one you have to rewire every time something changes.

The honest reality: most teams aren't there yet

What the debate usually skips: most teams aren't choosing MCP vs CLI on principle. They're in a practical middle ground where MCP infrastructure isn't fully stood up yet. The servers aren't deployed, the interfaces aren't standardized, the tooling is still maturing.

That's not a reason to dismiss MCP. It's a reason to be honest about where teams actually are. CLI isn't just a legacy choice. For a lot of teams right now, it's the pragmatic one because it's the only infrastructure that actually exists. Most teams are still in the inner loop. The path forward is to close that gap deliberately, starting with the interfaces that have the most surface area across agents and systems.

The token problem is upstream

One underappreciated advantage of MCP done well is what it enables at the context layer. But here's the thing: wasted tokens aren't really a CLI problem or an MCP problem. They're a symptom of disorganized retrieved context, regardless of which mode you're in.

An agent stuffed with 40 tools it doesn't need, or raw output it has to parse and infer meaning from, is paying a tax on poor context organization. Switching from CLI to MCP doesn't fix that on its own. What fixes it is understanding the entity the agent is actually operating on, and surfacing only what's applicable to it.

A Kubernetes service exposes a different set of operations than a GitHub repo or a Jira epic. This is something we've built directly into sixdegree: the ontology knows what entity the agent is operating on, and scopes the available tools to match. We call this progressive disclosure: tools and context matched to the entity at hand, not the full catalog. That's where the real token efficiency lives, and it works in both loops.

The remaining gap

Even with good MCP infrastructure and well-scoped tools, there's a ceiling you'll hit. MCP solves the interface problem. It doesn't solve the relationship problem.

An agent that can invoke 20 well-typed, correctly scoped tools is still operating with a map that shows roads but no terrain. It knows what it can call. It doesn't know how those systems relate to each other, what depends on what, who owns what, what changed last week. That relationship layer is what turns a capable agent into a reliable one.

The interface is solved. The context is still the hard problem. As we wrote in MCP Needs Connective Tissue, without relationship data every request becomes trial and error. And that's true whether you're in the inner loop or the outer one.