Perplexity CTO Moves Away from MCP Toward APIs and CLIs
At Ask 2026, Perplexity CTO Denis Yarats announced a shift from Anthropic's MCP toward APIs and CLIs, citing high context usage and authentication friction, alongside the launch of their multi-model Agent API.

At the Ask 2026 conference on March 11, Perplexity CTO Denis Yarats announced the company is moving away from Anthropic's Model Context Protocol (MCP) in favor of traditional APIs and command-line interfaces. Yarats cited high context window consumption and clunky authentication as the core issues driving the shift. Alongside the announcement, Perplexity launched its Agent API - a single endpoint that routes to models from OpenAI, Anthropic, Google, xAI, and NVIDIA with built-in tools like web search, all accessible under one API key using OpenAI-compatible syntax.
TL;DR
- Perplexity CTO Denis Yarats says MCP's context overhead and authentication friction make it impractical at scale
- New Agent API offers a single endpoint for models from 6 providers (OpenAI, Anthropic, Google, xAI, NVIDIA, Perplexity) with built-in web search
- OpenAI SDK compatible - switch by changing the base URL and API key
- Y Combinator's Garry Tan built a CLI instead of using MCP, signaling a broader trend
- MCP defenders argue dynamic tool discovery and standardization still matter for complex agent ecosystems
What MCP Is and Why It Matters
MCP (Model Context Protocol) is an open standard Anthropic released in late 2024 that defines how AI agents connect to external tools and data sources. It uses a client-server architecture: MCP servers expose tools (search, databases, APIs), and MCP clients (AI applications) discover and call them through a standardized protocol. The promise is interoperability - build a tool once and any MCP-compatible agent can use it.
The protocol gained rapid adoption. Claude, Cursor, VS Code, Windsurf, and dozens of other AI applications added MCP support. Perplexity itself shipped an MCP Server in November 2025 with tools for search, research, and reasoning.
Yarats' Criticism
Yarats' objections are practical, not philosophical. MCP's tool definitions consume context window tokens - every tool description, parameter schema, and response format eats into the model's working memory. For agents making many tool calls across long conversations, this overhead compounds. The authentication model, which requires each MCP server to handle its own auth flow, creates friction when connecting to multiple services.
These aren't niche concerns. Any team running multi-tool agents at production scale has hit the same walls: bloated system prompts full of tool schemas, context windows exhausted before the actual work begins, and authentication flows that break across service boundaries.
The Agent API
Perplexity's alternative is the Agent API, generally available since February 2026. Instead of connecting to separate MCP servers for each capability, developers hit a single endpoint with one API key:
| Feature | Details |
|---|---|
| Endpoint | POST https://api.perplexity.ai/v1/agent |
| Models | GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro, Grok 4.1 Fast, Nemotron 3 Super, Sonar |
| Built-in tools | Web search ($0.005/call), URL fetch ($0.0005/call), function calling (free) |
| Compatibility | OpenAI SDK format - change base URL and key |
| Pricing | Direct provider rates, no markup on third-party model tokens |
The design is deliberately simple. You pick a model, optionally enable web search or URL fetching, and the API handles tool execution internally. No tool schemas in the system prompt, no separate auth per tool, no MCP server management.
For teams already using the OpenAI SDK, switching requires changing two lines:
client = OpenAI(
base_url="https://api.perplexity.ai/v1",
api_key="your-perplexity-key"
)
The Broader Signal
Yarats isn't alone. Y Combinator CEO Garry Tan built a CLI for his use case rather than working through MCP, pointing to reliability and speed as the deciding factors. The pattern is showing up across the developer ecosystem: when teams hit production requirements - uptime, latency, predictable costs - they tend to reach for APIs and CLIs over protocol-level abstractions.
MCP defenders counter that this misses the point. The protocol's value is in dynamic tool discovery - agents that can find and use tools they weren't explicitly programmed to call. A CLI works when you know exactly what tools you need. MCP works when the agent needs to figure that out at runtime. Progressive discovery, where agents explore available tools incrementally, is a capability that hardcoded API integrations can't replicate.
Both sides have a point. For well-defined production pipelines where the tool set is known and stable, a direct API is simpler, faster, and cheaper. For open-ended agent systems that need to adapt to new tools without code changes, MCP's standardized discovery layer solves a real problem. The tension isn't about which approach is better in absolute terms - it's about which tradeoffs matter for a given use case.
What This Means
Perplexity's move is pragmatic, not ideological. They still run an MCP Server for developers who want it. But their flagship product for agent builders is now a traditional API that absorbs the complexity internally rather than pushing it to the client.
The bigger question is whether MCP's adoption momentum survives as more companies build API alternatives that are easier to integrate. The protocol has institutional support from Anthropic and broad IDE adoption, but developer tooling tends to converge on whatever ships fastest with the fewest integration headaches. Right now, that's a REST endpoint with a bearer token.
Sources:
Last updated
