MCP + CLI > MCP vs. CLI: The Protocol Didn't Lose — Agents Just Used It Wrong

Over the past year, a blunt conclusion has become popular in AI engineering circles: MCP doesn't work, CLI is the future. Perplexity's CTO reportedly announced internally that the company was moving away from MCP toward APIs and CLIs; OpenClaw^Ad deliberately doesn't support MCP; and Garry Tan put it even more directly — "MCP sucks honestly." That tweet racked up 1.6k likes on X, and the sentiment was off the charts.

But this article's position is: they're only half right. The problem is real, but the diagnosis is wrong. What's broken isn't the MCP protocol itself — it's the way most agents use MCP. The solution isn't to throw out the protocol, but to stop using it badly.

The Problem Is in the Harness, Not the Protocol

Most agents treat MCP tools as prompt-time function calls. Connect to a server, and every tool definition gets shoved into the context window immediately; call a tool once, and the full result lands in context too. Ten servers with five tools each means you're paying thousands of tokens every single turn before any work even begins. Results pile up, context rots, the agent gets slower and dumber, and data the model never needed ends up in the model anyway.

None of these bad experiences are written into the MCP spec. MCP itself already offers the fix: Anthropic's tool search tool and Cursor's dynamic context discovery implement progressive tool discovery; Cloudflare and Anthropic have both written about code mode; there are also sub-agents that split context. The problem is that most MCP clients simply don't implement these capabilities. The protocol has outrun the ecosystem.

Conversely, why does CLI work well? Largely by accident. Agents don't load all CLI documentation at once — they read --help when needed; CLIs run naturally as code, so you can chain them with pipes and shell scripts; and every model knows the shell inside out because training data contains fifty years of it. But CLI's weaknesses are equally obvious: it's a local black box with no standard transport, no standard auth, no discovery mechanism, and no way to scope or intercept what it does to external services. That's exactly why agents have MCP connectors but no CLI connectors.

What is a harness? In the agent context, a harness refers to the entire execution framework outside the model that connects the model to tools and the environment — including how tool definitions get stuffed into context, how the model's returned call intents get parsed, and how execution results get fed back to the model. The same MCP server can perform drastically differently depending on the harness: one that spreads all tool schemas across the context window at once makes the model carry thousands of tokens of noise every turn; one that retrieves tools on demand and keeps large results outside the context, returning only summaries, can cut overhead dramatically. So when someone says "MCP is slow/expensive," the real problem is often the harness's design decisions, not MCP's wire protocol.

What is code mode? The core idea of code mode is: rather than having the model make a separate call for each tool — with a round trip through the model's context every time — let the model write a small program (usually a script or code block) that calls multiple tools in sequence inside a sandbox or host runtime, returning only the final result. This has three benefits: first, it saves the token cost of multiple model round trips; second, it naturally supports orchestration logic like loops, conditionals, and pipes; third, intermediate data doesn't have to enter the model's context, avoiding pollution and context rot. Anthropic and Cloudflare have both written about related practices, and mcpc's --json is a concrete form of this idea.

MCP Handles Remote, CLI Handles Local

The right approach is to let each do its job. MCP continues as the standard remote interface: server discovery, auth, access control. CLI becomes the local interface between the agent and MCP. Apify open-sourced mcpc, a general-purpose MCP CLI client with a very clear architecture:

┌──────────┐   Bash()   ┌────────┐    MCP    ┌────────────┐
│ AI agent │ ─────────► │  mcpc  │ ────────► │ MCP server │
└──────────┘            └────────┘           └────────────┘
                                     Sessions, OAuth, Tools,
                                     Resources, Prompts,
                                     Tasks, x402, ...

The agent only needs a single Bash() tool to invoke mcpc, and by learning usage through --help, it can interact with MCP servers. It gets the full MCP protocol out of the box: persistent sessions, OAuth 2.1 (including enterprise SSO), tools, resources, prompts, async tasks, skills, x402 payments, and --json-based code mode. mcpc supports MCP 2026-07-28 and is backward compatible with older versions, contains no LLM internally, starts fast, and has few dependencies. As a bonus: on the same machine, one login and one set of active sessions can be shared across multiple agents.

MCP's transport and auth mechanisms. MCP currently has two mainstream transports: stdio, where a local process communicates over standard input/output, and Streamable HTTP for remote services (there was also the now-deprecated HTTP+SSE). In remote scenarios, the MCP spec delegates authorization to OAuth 2.1, requiring servers to expose protected resource metadata that clients use to complete discovery, the authorization code flow, and token refresh. The value of this mechanism is standardization: any compatible client facing any compatible server can use the same approach to authenticate, scope permissions, and revoke access, rather than writing a separate API key logic for every third-party service. This is the most critical difference between MCP and a bare CLI — CLI runs great locally but struggles to carry enterprise-grade questions like who is authorized to access which remote resource, with what scope, and whether it can be audited.

What It Looks Like in the Shell

Here's an actual shell workflow showing the whole process from installation to progressive tool discovery:

brew install apify/tap/mcpc          # or: npm install -g @apify/mcpc

mcpc login mcp.apify.com             # OAuth once; token stored in OS keychain
mcpc connect mcp.apify.com @apify    # establish persistent session
mcpc @apify                          # view server info, capabilities, instructions
mcpc @apify grep "crawler"           # progressive tool discovery
mcpc @apify tools-get search-actors  # fetch a tool's schema only when needed
mcpc @apify tools-call search-actors keywords:="tiktok scraper"

And code mode matters even more — the agent writes a script instead of round-tripping through its own context for every call:

mcpc @apify tools-call search-actors keywords:="tiktok scraper" limit:=1 --json \
  | jq -r '.content[0].text | capture("`(?<actor>[^`]+)`").actor' \
  | xargs -I {} mcpc @apify tools-call fetch-actor-details actor:="{}" --json

This means that regardless of whether an agent's own MCP client supports progressive discovery and code mode, it can use both capabilities through mcpc.

Progressive tool discovery refers to a mode where tool definitions are loaded on demand: the agent doesn't initially stuff all tool names, descriptions, and parameter schemas into context. Instead, it first gets a tool list or finds relevant tools through retrieval, and only fetches the full schema for a tool when it actually needs to use it. This contrasts with the naive "load everything on connect" approach. For scenarios with multiple connected servers, each with dozens of tools, progressive discovery can shrink the tokens permanently resident in context from thousands to hundreds. Anthropic's tool search tool and Cursor's dynamic context discovery are both doing this, and mcpc @apify grep "crawler" plus tools-get expose it in the form of CLI commands, so agents without that capability can benefit too.

What the Benchmarks Say

Apify built connector-bench to quantify mcpc's efficiency relative to CLI and naive MCP implementations. Each run gives the agent the same cross-server task, but using three different harnesses: native MCP with all tools loaded into context, a native CLI for the same service, and mcpc. The benchmark tracks cumulative cost against wall-clock time.

In an Actor discovery scenario comparing an Apify MCP server against the Apify CLI, mcpc completed tasks faster than the native CLI in many tests, though sometimes at higher cost. The authors are candid about the explanation: natively optimized CLIs are typically leaner and more token-efficient than a general-purpose MCP CLI wrapper. But they believe there's significant room for optimization, and mcpc performance will gradually converge toward native CLI levels.

connector-bench's evaluation methodology. The core of this kind of benchmark is controlling variables: give the same agent exactly the same task, and only swap the harness behind it — native MCP (all tools in context), the corresponding native CLI, and the mcpc wrapper layer. The metric isn't just "time" or "cost" in isolation, but the curve of cumulative cost over wall-clock time, because in real usage an agent might execute dozens of steps in sequence, and any single point's speed or savings can be overtaken by accumulated overhead in later steps. This design reveals a fact that's easy to overlook: a faster harness isn't necessarily more token-efficient, and a more efficient one isn't necessarily faster — the two must be weighed against the specific task distribution. The authors accordingly acknowledge that natively optimized CLIs often have the advantage in token efficiency, while mcpc's advantages show up more in completion speed and out-of-the-box support for the full MCP capability set.

Stop Shouting CLI Beats MCP

The conclusion is actually quite modest: MCP + CLI beats either one alone. Even OpenClaw, which is said to "deliberately not support MCP," is actually using MCP through mcporter — an MCP-to-CLI converter — which itself confirms this. The problem was never the protocol; it's that agents implemented MCP poorly.

MCP officially has SDKs in ten languages — TypeScript, Python, Go, and more — but none for shell, which happens to be the most universal programming language. mcpc aims to fill that gap, letting any agent with a code runtime use the full MCP.

For developers, the takeaway isn't about picking sides, but about distinguishing the layers of the interface: remote connection, auth, and discovery go to MCP; local orchestration, scripting, and token savings go to CLI. Setting the two against each other is itself a bad abstraction.

One-line Summary

MCP is being dismissed because it's badly implemented; MCP for remote and CLI for local is the right answer.

Paragraph Summary

The article pushes back against the popular narrative that "MCP doesn't work, CLI is the future," arguing the problem isn't the MCP protocol itself but that most agents' harnesses treat MCP tools as fully loaded prompt-time function calls, causing context bloat and soaring costs. The MCP spec already offers fixes — progressive tool discovery, code mode, sub-agents — but most clients don't implement them. The author argues MCP and CLI should each do their job: MCP handles remote server discovery, auth, and access control, while CLI serves as the local interface between the agent and MCP. Apify's open-source mcpc is the concrete realization of that idea: the agent needs only a single Bash() tool and learns usage through --help to access the full MCP capability set. Benchmarks show mcpc is faster than native CLI on many tasks, though token efficiency still has room for optimization.