Contents
The claim going viral
In March 2026, sparked by Perplexity's move, claims like the following spread rapidly across X, Medium, and DEV.to.
"Perplexity ditched MCP and went back to APIs/CLI." "MCP wastes 72% of the context window." "Garry Tan (YC) built his own CLI too." "The MCP 'standard' is already dying." — therefore betting on MCP is a mistake.
The claim has a factual core, but the conclusion overreaches. We go to primary sources and the latest data and separate it component by component.
Check 1: Did Perplexity really ditch MCP?
Perplexity CTO Denis Yarats said the company is moving internally from MCP to traditional APIs/CLI.
At its own "Ask 2026" conference on March 11, 2026, Yarats said Perplexity is moving internally from MCP toward traditional APIs and CLI tools, citing two issues: high context-window consumption and clunky authentication. The replacement core is the Agent API, generally available since February 2026 — a single OpenAI-compatible endpoint routing to OpenAI, Anthropic, Google, xAI, and NVIDIA models.
What matters here is that this is a shift for an internal workload, not a public denunciation of MCP or a call for the industry to abandon it. For a use case that hits a single in-house product at high frequency and low latency, a dedicated API can be more efficient than a general-purpose protocol — that's rational self-optimization, separate from the death of a standard.
Check 2: Is "72% context waste" true?
MCP consumes up to 72% of the available context window before the agent processes a user message.
Yarats said MCP can consume up to 72% of context before a single user message is processed. One developer reported using 143K of 200K tokens (72%), with 82K coming from tool metadata. The cause is a design that keeps every tool's description, parameter schema, and response format expanded in context at all times.
This figure is close to the ceiling when many MCP servers are connected at once and tool definitions are unoptimized. Conversely, narrowing connected servers, lazy-loading tool definitions, and keeping schemas concise drives it down sharply. It's less an "unavoidable MCP cost" and more an "operational-design and server-implementation problem." We separately verify the context-bloat claim at KanseiLink, confirming with measured data that metadata design ties directly to success rate and token efficiency.
Check 3: Are the big players all going back to CLI?
Garry Tan (YC) built his own CLI too. The big players are uniformly returning from MCP to CLI.
It's true that Y Combinator's Garry Tan reportedly built a CLI instead of using MCP. But generalizing to "uniformly" is an overstatement — over the same period, many platforms newly added MCP support.
If anything, 2026 was the year big-player MCP adoption accelerated. Claude (native), ChatGPT (Apps SDK / Connectors), Google Gemini API and Vertex AI Agent Builder (support added March 2026), Cursor, Windsurf, Zed, JetBrains AI Assistant, the Vercel AI SDK, and the OpenAI Agents SDK all support MCP. "Big players leaving" and "big players newly adopting" are observed simultaneously; cropping to only the former distorts the picture.
Check 4: Is MCP dying?
The MCP "standard" is already dying.
Every adoption metric is climbing. MCP SDK downloads reached about 97 million per month as of March 2026 (about 970x the 100,000 at launch). The public registry surpassed 9,400 servers. In enterprise, 78% of AI teams reported running at least one MCP-backed agent in production as of April 2026.
MCP adoption metrics (2026) — opposite of "death"
downloads (Mar)
servers
prod MCP agent (Apr)
download growth
The clincher is the governance shift. Anthropic donated MCP to the Linux Foundation with OpenAI, Google, and Microsoft as co-sponsors, repositioning MCP from "Anthropic's protocol" to vendor-neutral infrastructure. A donation plus multiple big-player co-sponsorship is not something that happens to a declining standard.
The "context waste" critique is valid, which is exactly why the 2026 MCP roadmap centers on scalability, enterprise auth, and governance, with tool-definition efficiency under discussion. See our coverage of the MCP spec release candidate (2026-07-28). The critique is not a death omen — it's the driver of evolution.
Overall verdict and what it means for builders
Separating the four components yields this.
| Claim | Verdict | Key basis |
|---|---|---|
| Perplexity shifted internally from MCP | ✅ True | Stated at Ask 2026 (3/11), moving to Agent API |
| 72% context waste | ⚠️ Conditional | Worst-case ceiling; design reduces it sharply |
| Big players "uniformly" back to CLI | ⚠️ Overstated | Cases are real, but many new adoptions too |
| MCP is dying | ❌ Overstated | 97M SDK DLs, LF donation, accelerating adoption |
Taken together, the claim is the "has a factual core but overgeneralizes the conclusion — misleading" type. The defection cases and technical critiques are genuine, but deriving "MCP is over" from them does not square with the data. The right question is not "MCP or CLI" but "what to choose for which workload."
- Single-vendor, high-frequency, low-latency repetitive work → a dedicated API/CLI can win on context efficiency (Perplexity's internal-use type)
- Spanning many heterogeneous SaaS, needing discoverability, standard auth, ecosystem compatibility → MCP wins
- If you use MCP: narrow connected servers, keep tool definitions concise, monitor metadata bloat (the practical answer to the 72% problem)
- For SaaS providers: don't stop at "we support MCP" — manage tool-definition token efficiency and discoverability with measured data
MCP is not dead. It has entered a maturing phase where it absorbs criticism and evolves the spec. The viral "MCP is over" narrative is a textbook case of inflating a technically valid point into an excessive conclusion — decisions should be made on workload fit.
FAQ
Q1. Did Perplexity completely abandon MCP?
Not a full abandonment — a shift from the internal default. CTO Denis Yarats announced the move to APIs/CLI at Ask 2026 (2026/3/11), centering on the Agent API (GA in February). Reasons: high context consumption and clunky auth. It's self-optimization for a workload, not a denunciation of the standard.
Q2. Is "72% context waste" true?
True under conditions. It's a worst-case ceiling with many servers connected and tool definitions unoptimized. One report cited 143K of 200K used (82K metadata). Narrowing connections and optimizing definitions reduces it sharply, so it's an operational-design issue, not an unavoidable cost.
Q3. Are the big players all going back to CLI?
Overstated. Individual cases like Garry Tan's (YC) self-built CLI are real, but Gemini API/Vertex (March), ChatGPT, Cursor and others newly added support over the same period. Departures and new adoption run in parallel — not "uniform."
Q4. Is MCP dying?
Overstated. 97M monthly SDK downloads (970x in 18 months), 9,400+ registered servers, 78% of enterprises running it in production. Anthropic donated it to the Linux Foundation with OpenAI/Google/Microsoft co-sponsoring — not something that happens to a declining standard.
Q5. So should I use MCP or CLI?
Decide by workload fit. Single-vendor high-frequency low-latency favors a dedicated API/CLI; spanning many SaaS with discoverability and standard auth favors MCP. It's not either/or.
The factual claims here rest on secondary sources retrieved via web search. Perplexity CTO Denis Yarats's statements (Ask 2026, March 11, 2026; high context consumption, clunky auth, 72%, Agent API) are based on reporting from AwesomeAgents, Repello AI, byteiota, agent-engineering.dev and others. The "143K of 200K used, 82K metadata" figure is one developer's report, not representative of all environments. MCP adoption metrics (97M monthly SDK downloads, 970x, 9,400+ registered servers, 78% enterprise production use, Linux Foundation donation, Gemini/Vertex March support) are based on aggregations from digitalapplied, effloow, cdata and others; definitions and reference dates may differ by source. Garry Tan's self-built CLI is report-based with limited primary confirmation (⚠️). Verdicts (✅⚠️❌) are editorial judgments based on public information available as of 2026-05-26 and the situation may change. Verify the latest primary sources before production decisions.