MCP Doesn’t Suck. Your Architecture Might.
Perplexity’s MCP Pivot Shows Where Model Context Protocol Actually Belongs
Perplexity rolled out Computer in Feb end, and yesterday did an AMA in SFO, and While i have much to say about their roadmap and the whole orchestration layer, I just wanted to pick on the drama they flared up in the event, which obviously is trending on twitter today.
the company’s CTO Denis Yarats says they’re “moving away from MCP internally” in favor of APIs and CLIs, X obviously went immediately back to “MCP sucks,”debate which is been going on for a while IMO. As usual, both sides the “MCP is dead” camp side and “MCP is the future and definitely not dead” side, are wrong in interesting ways. MCP neither sucks nor saves you; it’s just a protocol.
The real story is about where you try to use it.
The Perplexity spark: MCP as the wrong layer
Perplexity is a good bellwether because they’ve gone deeper into agentic infrastructure than most, and this is exactly why I wanted to add perplexity example here.. Perplexity Computer as a multi‑agent orchestrator, Comet as the browser shell, and Personal Computer as an always‑on Mac mini host wired into local files and apps. Now against that backdrop, if Denis is saying “we’re ditching MCP internally” is not a random hot take, it’s a signal that, at scale,
MCP is the wrong substrate for the guts of their AI OS.
Internally, they lean on boring APIs and CLIs because that’s where latency, observability, and security matter most for big customers. Externally, they still ship an official MCP server and first‑class MCP connectors in the Mac app so Claude Desktop, OpenClaw‑style agents, and local tools can plug in with minimal glue. In one sentence:
Perplexity didn’t kill MCP, they pushed it back to where it belongs. at the edges of their AI OS, not at the core.
The “MCP sucks” camp - real problems, wrong conclusion
its not all fluff. there are enough substantive critiques behind the memes. and Security and operational people have been yelling about them for a year -
weak default security,
tool poisoning and prompt injection,
messy identity and auditing, and
non‑trivial cost and latency overhead.
Malicious or sloppy servers can embed harmful instructions or shadow tools. if your platform treats MCP servers as trusted extensions, you’ve just expanded your attack surface in ways that are hard to reason about.
Beyond security, high‑volume streaming, batch ETL, or rich interactive flows often map more cleanly to event buses or normal APIs than to MCP’s tool‑call mental model. From that angle, it’s easy for infra‑minded teams and some VCs to conculde that “MCP is bloated, let’s roll it back and replace it with lighter ‘agent skills’ or plain APIs.” but jumping straight to “MCP is dead” means, you miss where it’s actually working.
The “MCP is maturing” camp: not dead, just leaving the hype peak
On the other side, you have the “MCP is fine, your implementation sucks” crowd, and they have receipts too. One‑year retrospectives show a growing ecosystem of MCP servers and SDK downloads, with IDEs, local agents, and commercial platforms all converging on the spec. Case studies from vendors point to higher task completion and lower integration costs when teams standardize on MCP for agent‑to‑tool interaction instead of inventing bespoke plugin formats.
“State of MCP” posts now frame 2025–26 as the classic hype‑cycle move, from “use it for everything” to “use it where interoperability and real‑time context actually matter.”
Their main claim is that MCP is moving from flashy demo material into boring enterprise plumbing at the edge of systems, not at the core and that’s exactly what maturation looks like.
What’s happening is the scope correction!
if you put Perplexity’s move next to these broader signals, a pattern emerges.
MCP is bad as your internal micro-service fabric, your primary security boundary, or a mandatory wrapper around every existing API. But It’s good as a standard way for agents to talk to tools and data sources you don’t fully control, as a publishing format for reusable capabilities across IDEs and local agents, and as a connector layer on desktops and “AI PCs” reaching into local apps and services.
In other words, MCP’s natural home is at the edges of an AI system. between your orchestrator and the messy outside world, not as the core nerve system inside your own infra. Perplexity’s decision is best read as a high‑profile scope correction, not a death sentence.
So where should you use MCP?
Strip away the noise and a simple rule of thumb emerges:
Use MCP when:
You want third‑party agents to call your capabilities with minimal custom glue.
You need a single tool interface that can be reused across multiple LLM vendors and runtimes.
You’re connecting to local tools or self‑hosted services from a desktop or always‑on box and want a consistent agent‑friendly protocol.
Avoid MCP when:
You’re wiring together your own micro-services, data pipelines, and long‑running jobs inside one company.
You need strong, audited, fine‑grained security and governance as the primary control plane.
You can already expose a clean API/SDK and don’t need cross‑vendor agent interoperability.
MCP doesn’t suck. Overusing it does.
Perplexity isn’t killing MCP. they’re just refusing to build an entire AI OS on top of a protocol that was never meant to be the foundation in the first place.
If you’re building your own AI lab, copy this lesson - make MCP a plugin layer, not your nervous system.
[ In this newsletter you get sharp, unfiltered short essays; for full‑length, deep‑dive analysis on AI, subscribe to our companion publication, Intelligent Founder AI. ]