MCP Isn't the Problem
I've spent four posts building the case for MCP as a semantic data layer, a headless capability surface, a foundation for negotiated integrations. Then Perplexity's CTO said they're dropping MCP for APIs and CLIs. Here's the thing: most of the criticism is right.
Thesis: MCP has five real problems that make it painful in practice. Acknowledging them honestly matters more than defending the protocol. But the conclusion most people draw — "just use CLIs" — is a category error. The problems are real. The diagnosis is wrong. And the one thing almost everyone gets wrong about MCP changes how you evaluate every criticism.
This is Post 7 of 7 in The Interface Inflection series. The arc: Interfaces Are Changing → MCP: The Semantic Data Layer → Headless AI → Negotiated Integrations → Democratizing AI Builders → The Interface Forecast. This post stress-tests the MCP layer against its best critics.
The Case Against MCP
The case has been building for months. Mario Zechner benchmarked MCP servers against CLI equivalents and the numbers weren't close: Playwright's MCP server consumes 13,700 tokens (21 tools), Chrome DevTools MCP takes 18,000 tokens (26 tools), versus 225 tokens for a set of CLI scripts doing the same browser automation. A 60x difference.
Connect three or four MCP servers to your coding agent and you've consumed 20–30% of context on tool schemas alone. As conversations grow, it compounds. Every message carries the full tool list. Agent accuracy degrades. Soham Shah at Ema described it plainly: "significant slowdown as the conversation continues."
The criticisms stack up. Let's take them seriously.
Problem 1: Schema Overhead Is Real
Every tool schema gets loaded into context at connection time. Twenty tools with detailed descriptions can consume 7–9% of a context window before any work begins. The schema tax is worst when servers expose many tools (the Playwright pattern), multiple MCP servers connect to the same agent, conversations are long-running, and the agent uses only a fraction of available tools per session.
This isn't theoretical. It's the single most common complaint from practitioners, and the benchmarks back it up.
Problem 2: Auth Is Immature
OAuth flows, token refresh, credential storage, multi-tenant isolation — MCP's authentication story is a work in progress. The spec defines a transport layer. It doesn't define how you handle token expiry mid-session, rotate secrets without dropping connections, or scope access per-user in a multi-tenant environment. Every team solving this is solving it independently.
CLIs and REST APIs benefit from decades of auth infrastructure — ~/.netrc, credential helpers, bearer token patterns, OAuth libraries that handle every edge case. MCP is starting from scratch. The ecosystem will mature, but "the ecosystem will mature" isn't an answer for the team shipping this quarter.
Problem 3: Training Data Favors Shell
Models have seen millions of bash sessions, curl invocations, and git workflows in training data. They've seen comparatively little MCP interaction. The result is measurable: agents compose shell pipelines more reliably than they navigate unfamiliar MCP tool schemas.
Zechner's benchmarks showed equivalent success rates between MCP and CLI approaches, but CLI runs cost less — fewer retries, less exploration, more direct execution. The model already knows gh pr create. It has to learn your custom MCP tool mid-conversation. This advantage is temporal — training data will catch up — but if you're shipping next week, today's constraint is today's constraint.
Problem 4: Composability Is Weak
Unix pipes are the original composition primitive. curl ... | jq '.items[]' | xargs -I{} ... works because every tool speaks text streams. The output of one command flows directly into the next — no intermediary, no context window, no token cost.
MCP breaks this model. Results pass through the agent's context window to reach the next call. That detour adds latency, consumes tokens, and makes the agent the bottleneck in every composition chain. For tasks that are naturally sequential pipelines, this is a real penalty.
Problem 5: Most MCP Servers Are Poorly Designed
This is the uncomfortable one. The MCP ecosystem is full of servers that expose too many tools, return too much data, provide no guidance, and ignore token efficiency entirely. Many are proof-of-concept wrappers that became "production" through inertia.
The anti-patterns we see repeatedly:
- Tool proliferation: 20+ tools when 5–9 would suffice
- Kitchen-sink responses: Returning full objects when the agent needs one field
- No progressive disclosure: Full detail on every call, no slim mode
- No guidance: The agent gets data but no hint about what to do next
- Intent parsing: The MCP server tries to understand natural language instead of returning structured data
People evaluate "MCP" by interacting with bad MCP servers. They conclude the protocol is the problem. It's like evaluating REST by hitting a poorly designed API that returns 50MB JSON with no pagination.
The One Thing Everyone Gets Wrong
Here it is: MCP is not a product. It's an interface.
The debate treats MCP as a thing you're either using or not using — like switching from MySQL to Postgres. But MCP is a wire protocol. JSON-RPC with tool schemas and discovery. It's an interface contract, not an implementation.
A CLI is an interface. A REST API is an interface. MCP is an interface. They all describe how a consumer discovers and invokes capabilities. They differ in discovery mechanism, transport, and assumed consumer — but the backend is the same.
When someone says "we're moving away from MCP to CLIs," they're saying "we're changing which interface their consumers use." That's a valid architectural decision. It's not a verdict on the protocol.
Now re-read the five problems through this lens:
| Criticism | Actual problem | Protocol's fault? |
|---|---|---|
| Schema overhead | Too many tools with verbose descriptions | No — server design choice |
| Auth immaturity | Spec gap in credential lifecycle | Yes — real spec gap |
| Training data bias | Models undertrained on MCP patterns | No — temporary ecosystem gap |
| Weak composability | Agent-as-bottleneck in pipelines | Partially — different composition model |
| Poor server quality | Bad implementations, not bad protocol | No — ecosystem practice |
Four of five are implementation or ecosystem problems. One is a real spec gap. The protocol itself is sound. The ecosystem around it needs discipline.
Who Wins Where
The right framing isn't MCP or CLI. It's: who is consuming your capabilities?
CLIs win when the developer is the user, the task is single-turn, composability is essential, and training data advantage matters. Perplexity is a company where engineers are the agents' operators. They know every API endpoint. Their tasks are well-defined retrieval operations. Of course CLIs work better. That's not an indictment of MCP — it's a statement about their consumer.
MCP wins when the agent doesn't know what's available (the discovery gap), the task is multi-turn (most real operations aren't "get foo"), the consumer is unknown (any MCP client can connect), and governance matters (validation, guardrails, audit at the protocol layer).
| Consumer | Needs discovery? | Needs guidance? | Needs composability? | Best interface |
|---|---|---|---|---|
| Developer writing scripts | No | No | Yes | CLI / API |
| Developer in AI coding tool | Sometimes | Sometimes | Yes | CLI + light MCP |
| Agent on behalf of end user | Yes | Yes | Less critical | MCP |
| Agent on behalf of agent | Yes | Yes | Via protocol | MCP |
Perplexity's engineers are in row 1. Most enterprise integration scenarios are in rows 3–4. The protocol choice follows from the consumer.
MCP's cost is schema overhead. MCP's value is that the agent can figure out what to do without reading your documentation.
How We Designed Around Every Problem
At Ema, we built an MCP server for managing AI Employees on the platform. We hit every criticism above — and then designed around them.
| Problem | How we address it |
|---|---|
| Schema overhead | 9 tools (down from 45), domain-scoped with method parameter |
| Auth | Shared auth layer with CLI via SDK; credentials managed once |
| Token efficiency | slim=true mode strips 60–70% from large payloads |
| Composability | Response actions (_actions) provide pre-filled next tool calls |
| Server quality | Blocking validation — bad operations fail before they execute |
| Guidance gap | _next_step, _tip, _warning in every response |
The interface-not-product principle in practice. Our MCP server and CLI call the same SDK. Same handlers. Same validation. Same business logic. The MCP server adds structured discovery and contextual guidance. The CLI adds shell composability and human ergonomics. Neither replaces the other because they serve different consumers. If someone told us "just use the CLI," we'd say: we already do. The MCP wraps it for discovery.
Progressive disclosure over kitchen-sink responses. Workflow definitions can be 70KB of JSON. slim=true strips display settings, truncates long inline values, and preserves only structural wiring — 60–70% smaller. Knowledge search returns document IDs by default. Add detail="excerpts" for relevant passages. Add detail="answer" for an AI-generated summary. The agent pays for exactly the depth it needs.
Blocking validation over documentation. Deploying a workflow without a fingerprint? Blocked. Search node without uploaded data? Blocked. Missing fallback category? Blocked. LLMs can ignore documentation. They can't ignore a 400 error.
Structured guidance over raw data. Every response includes _next_step (what to do after this call), _tip (contextual advice), _warning (known issues), and _actions (pre-filled tool calls the agent can execute directly). A few tokens of guidance saves hundreds of tokens of exploration.
The result: agents manage the full platform — personas, workflows, knowledge, debugging — through 9 tools with manageable context overhead. The CLI manages the same platform through the same SDK. Both exist because they serve different consumers — not because one is better.
What This Means for the Semantic Data Layer
Four posts ago, I argued that MCP is emerging as an enterprise semantic data layer — the ESB done right, because the intelligence lives in the consumer, not the layer. Does the criticism invalidate that thesis?
No. It sharpens it.
The ESB failed because it tried to be smart. MCP servers fail for the same reason — when they parse intent, manage state, auto-fix errors, or return more data than the consumer needs. The servers that work stay thin: describe capabilities, validate inputs, return structured data, provide guidance. That's what "semantic data layer" means. Not a smart layer — a legible one.
The five problems are consistent with MCP succeeding as a protocol and failing as an ecosystem practice. Auth will mature. Training data will catch up. Composability will evolve. But ecosystem quality — too many bad servers — requires something harder than spec revisions. It requires discipline.
The Convergence Nobody's Talking About
CLIs will grow MCP-like features. MCP servers will slim down to CLI-like simplicity. The gap will shrink.
Peter Steinberger's mcporter already bridges them — wrapping MCP servers as standalone CLI tools. That tool exists because the boundary is thinner than the debate suggests. A well-designed MCP server is a CLI with structured discovery. A CLI with machine-readable schemas and capability enumeration is an MCP server missing the wire protocol.
The protocol isn't the point. The abstraction — structured, discoverable capability description for AI consumers — is the point. Whether that's called MCP, an extended OpenAPI spec, or something else, the need isn't going away.
Common Misconceptions
- "Perplexity dropped MCP, so it's dying." Perplexity optimized for developer-operator workflows. Meanwhile, Google, Microsoft, OpenAI, Anthropic, and the Linux Foundation are standardizing it.
- "MCP is token-heavy by nature." The protocol is JSON-RPC. The overhead comes from server design, not wire format.
- "CLIs are more composable." For text pipelines, yes. For conditional multi-step workflows with error handling, the agent-as-compositor is stronger.
- "Just use APIs directly." APIs lack discovery. The agent needs to know which endpoint to call before it can call it. That knowledge has to come from somewhere.
- "MCP is just a fad." The pattern — structured capability description for AI consumers — will persist regardless of what the protocol is called.
What to Do Next
- Audit your MCP server's token footprint. Count tools, measure schema size, benchmark against a CLI equivalent.
- Apply the consumer test. Developer writing scripts? CLI. Agent discovering capabilities? MCP. Both? Both — same SDK underneath.
- Design for progressive disclosure. Default to minimal data. Let the agent request depth when needed.
- Use blocking validation. Don't document rules the agent should follow. Make bad operations fail.
- Keep the layer thin. Your MCP server should be a routing shim on your SDK, not a second application.
- Embed guidance in every response. Next steps, warnings, tips — a few tokens of guidance saves hundreds of tokens of exploration.
- Share the backend. MCP and CLI should be two interfaces on the same SDK. The interface is the variable, not the logic.