Why Is Perplexity Dropping MCP? The Real Reason Explained

Mar 13, 2026

Problem

Perplexity’s CTO announced they’re dropping MCP internally to go back to classic APIs and CLIs. This raises a question many AI engineers are asking: Is MCP fundamentally broken for AI agent tool calling?

I’ve been following the Reddit discussion, and I think the answer is more nuanced than a simple yes or no.

Purpose

In this post, I want to unpack what actually happened, why Perplexity made this decision, and what it means for developers building AI agents. The key insight: this is about internal tooling preferences, not a condemnation of MCP itself.

What Actually Happened

Let me be clear about the facts from the discussion:

Internal Decision Only: Perplexity dropped MCP for internal use. They didn’t say MCP is useless or that others shouldn’t use it.
CTO’s Reasoning: Classic APIs and CLIs work better for their specific AI agent workflows. That’s the stated reason.
Community Reaction: Mixed. Some called it “skill issue,” others pointed out legitimate trade-offs.

Here’s the core quote that caught my attention:

“MCP standardizes auth on OAuth DCR which is better than copy-pasting API keys.”

This tells me MCP does offer real value in some areas. So what’s really going on?

The MCP Promise vs Reality

MCP (Model Context Protocol) promises several things:

Standardized protocol for AI agent tool calling
Consistent interface across different LLMs and tools
OAuth-based authentication (specifically OAuth Dynamic Client Registration)
Automatic discovery of available tools

I’ve used MCP myself, and it does deliver on these promises. But there’s a catch.

Where MCP Can Struggle

Schema Mapping Lossiness

When you wrap an existing API in MCP, you’re creating a schema layer. This can lose precision. Here’s what I mean:

{
  "tools": [
    {
      "name": "search_web",
      "description": "Search the web for information",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string",
            "description": "Search query"
          },
          "max_results": {
            "type": "integer",
            "description": "Maximum results to return",
            "default": 10
          }
        },
        "required": ["query"]
      }
    }
  ]
}

Now compare that to the original API it wraps:

import httpx

async def search_web(query: str, max_results: int = 10) -> list[dict]:
    """Direct API call with full control over request."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            "https://api.search-provider.com/search",
            params={
                "q": query,
                "limit": max_results,
                "include_snippets": True,  # This feature might be lost in MCP schema
                "date_range": "last_week",  # Another feature that needs explicit mapping
            },
            headers={"Authorization": f"Bearer {API_KEY}"},
            timeout=30.0
        )
        response.raise_for_status()
        return response.json()["results"]

The MCP schema abstracts away some of the nuance. For Perplexity, whose agents need precise control over search APIs, this abstraction might have been a friction point.

Why APIs/CLIs Won (For Perplexity)

I think there are three main reasons Perplexity went back to direct APIs and CLIs:

1. Complete Control

With direct APIs, you get:

Full access to every API feature
No abstraction layer hiding capabilities
Transparent request/response handling
Easier debugging

2. Existing Tooling Ecosystem

Many companies have battle-tested CLI tools. Wrapping these in MCP adds complexity:

import subprocess
import json

async def search_via_cli(query: str) -> dict:
    """Use existing CLI tools directly - no protocol translation needed."""
    result = subprocess.run(
        ["search-cli", "--json", query],
        capture_output=True,
        text=True
    )
    return json.loads(result.stdout)

If your internal tools already work well, MCP becomes an unnecessary translation layer.

3. Performance Considerations

Every abstraction adds overhead. For high-throughput AI agents making thousands of tool calls, the protocol translation can add latency. I’m speculating here, but this could have been a factor.

What MCP Still Does Well

Let me not overcorrect. MCP has genuine strengths:

OAuth DCR (Dynamic Client Registration)

This is a real security win. Instead of manually managing API keys:

Traditional approach:
1. Get API key from provider
2. Copy-paste key into config
3. Rotate key manually when compromised
4. Hope no one committed it to git

MCP approach:
1. Client registers dynamically with authorization server
2. Gets unique client credentials
3. Credentials can be scoped and rotated automatically
4. Industry-standard OAuth 2.0 security

Cross-Platform Standardization

If you’re building agents that need to work across multiple LLM providers (Claude, GPT, Gemini), MCP provides a common interface. You define your tools once.

External Integrations

For plugins and third-party integrations, MCP is actually great. It provides a standard way for external tools to expose capabilities to AI systems.

When to Use Each Approach

I’ve put together a decision matrix:

Use MCP When	Use Direct APIs/CLIs When
Building cross-platform AI agents	Optimizing for single provider
Need standardized auth (OAuth DCR)	Have existing API infrastructure
Supporting multiple LLM backends	Require full API feature access
External integrations and plugins	Internal tooling with known APIs
Rapid prototyping across tools	Production systems needing precision

Common Misconceptions

I saw several misconceptions in the discussion. Let me address them:

Misconception 1: “MCP is broken”

No. MCP works for its intended use case: standardization. Perplexity’s internal needs simply don’t align with MCP’s strengths.

Misconception 2: “APIs are always better”

Also no. APIs require domain knowledge and manual maintenance. MCP abstracts complexity for cross-platform integrations. Choose based on your needs.

Misconception 3: “This means MCP is dead”

Definitely not. Claude Desktop uses MCP for tool integrations. Multiple AI companies support it. Adoption is growing, not shrinking.

My Take

I think Perplexity’s decision is pragmatic, not ideological. They have:

Internal tools that work well
Deep domain knowledge of their APIs
Performance requirements that benefit from direct access

For them, MCP added abstraction without clear benefit. But that doesn’t invalidate MCP for everyone.

If you’re building:

Internal-only tools: Direct APIs/CLIs might be better
Multi-provider agents: MCP provides real value
External integrations: MCP is the right choice
Prototyping: MCP’s standardization speeds things up

Summary

In this post, I explored Perplexity’s decision to drop MCP internally. The key takeaway: this is about internal tooling preferences, not a fundamental flaw in MCP. Classic APIs and CLIs offer more control and precision when you have deep domain knowledge and specific performance needs. MCP shines when you need standardization, cross-platform support, and OAuth-based authentication.

The lesson for AI engineers: evaluate your specific needs before choosing a tool calling approach. Don’t assume one size fits all.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion on Perplexity Dropping MCP
👨‍💻 Model Context Protocol (MCP) Specification
👨‍💻 Claude Desktop MCP Documentation

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!