MCP is not dead, it's being misused

Since the end of February 2026, the MCP (Model Context Protocol) has been under heavy criticism.

“MCP is dead, long live the CLI,” titles Eric Holmes in an article that went viral.

Perplexity’s CTO announces the internal abandonment of the protocol.

Garry Tan, president of Y Combinator, tweets bluntly: “MCP sucks honestly.”

The OpenClaw project deliberately chose not to support it.

The grievances are well known:

• Token consumption explosion,
• Immature authentication,
• Questionable operational reliability.

And they are legitimate, within one very specific architectural model: the one we never adopted at Agora.

The real problem: the LLM at the helm of MCP

The pattern everyone is attacking is the LLM-as-router. You inject into the model’s context the schemas of dozens of MCP tools: their descriptions, parameters, constraints. The LLM must then choose which tool to call, with which arguments, and in what order. This is the dominant pattern in the current AI agent ecosystem.

And this is precisely where the criticisms hit the mark.

Cloudflare measured the gap on its own API: 1.17 million tokens to expose its 2,500 endpoints via native MCP schemas, more than the complete context window of the most advanced models. Keeping only the required parameters still leaves 244,000 tokens. Their fix, Code Mode, brings everything down to roughly 1,000 tokens through two generic tools (search() and execute()): a 99.9% reduction.

When every token has a cost in latency, energy, and euros, the native MCP equation no longer holds up.

Not to mention the risk of error: an LLM choosing among 50 tools can make the wrong call, invent parameters, or trigger a destructive action from a simple misreading. This isn’t theoretical: in 2025, an internal agent at AWS deleted and recreated a production environment mid-troubleshooting, causing a 13-hour outage; another documented incident saw an agent wipe an entire Windows system drive after 40 minutes of idle session time (source).

The diagnosis is correct. The conclusion, “we must abandon MCP,” confuses the protocol with an architectural pattern.

Our approach: separating interpretation from execution

A clear separation between interpretation and execution (MCP)

At Agora, we made a fundamentally different architectural choice from the very design of our agentic platform.

The LLM never sees the MCP schemas. It does not choose which tool to call. It does not construct the parameters of an API call.

The flow is as follows:

The LLM intervenes on what it does best: interpreting natural language.

• It classifies the user’s intent (“I want to request time off,” “show my January payslip”),
• It extracts the mentioned entities (dates, names, amounts), and detects conversation follow-ups.

MCP execution driven by a DSL and a dedicated SDK

It is then our SDK, driven by a declarative DSL, that takes over.

A DSL (Domain-Specific Language) is a language built for one specific domain. Unlike a general-purpose language like Python, it expresses business rules concisely and readably.

In our case, this DSL is injected into the LLM’s context as a structured prompt: it describes the intents recognized by the agent, the expected parameters for each intent, and the dialog rules to follow to collect them.

The key difference from the LLM-as-router pattern: instead of injecting hundreds of MCP tool schemas into the context and asking the LLM to choose the right endpoint with the right parameters, we give it a targeted business grammar. The LLM only needs to identify what the user wants to do, not how the API works.

This prompt specialization makes classification more stable and cuts the cognitive load imposed on the model: fewer tokens in context, less ambiguity, fewer errors.

Once the intent is classified and entities are extracted, the SDK, on the code side, knows which intent corresponds to which MCP call. And it orchestrates a collection dialog when information is missing:

• “For which dates would you like to request this time off?”
• “Is this paid leave or a compensatory day off?”

The MCP call is only triggered once all arguments are collected and validated. Not before.

What this changes in practice

Tokens used for interpretation, not for routing

In the LLM-as-router model, most of the token budget is consumed by tool descriptions injected into the context. And that is before the user has even asked a question.

In our system, the LLM’s context contains only the conversation history and the classification prompt. The MCP schemas never appear there, which cuts token consumption per request and directly increases processing capacity on our local inference infrastructure.

Guaranteed argument collection

The classic pattern relies on the hope that the LLM will correctly extract all parameters from the user’s message in a single pass. When a required parameter is missing, the behavior is unpredictable: invented parameter, partial call, or silent failure.

Our automatic dialog system detects missing arguments and engages a structured conversation to collect them.

Disambiguation (“you have two managers, which one?”) and confirmation (“I’m going to request leave from March 15 to 22, is that correct?”) are workflow steps, not emergent model behaviors.

Authentication: a non-problem

Among the recurring criticisms directed at MCP, authentication comes up systematically.

Eric Holmes sums up the prevailing sentiment: “Why should a protocol for giving tools to an LLM need to worry about authentication?”

CLIs rely on proven mechanisms (aws sso login, gh auth login, kubeconfig), and they work.

But this criticism confuses two things:

• the immaturity of auth implementations in the community MCP ecosystem, and
• the protocol’s intrinsic ability to integrate with robust authentication solutions.

MCP, as a protocol based on JSON-RPC, does not need to reinvent authentication. It can, and should, rely on proven standards that already exist: SAML for enterprise SSO, OAuth 2.1 for access delegation, OpenID Connect for federated authentication.

The protocol’s 2026 roadmap is moving in this direction, with OAuth 2.1 integration and support for streamable HTTP transport.

At Agora, MCP call authentication is handled upstream by the platform. The SDK controls the entire chain: user authentication, permission verification, then transmission of a validated identity context to the MCP server.

The conversational agent never directly handles credentials. That is not a limitation, it is a separation of responsibilities, the same principle that keeps a web application’s controller from managing JWT tokens itself: it delegates to an authentication middleware.

Teams that struggle with MCP auth are usually the ones asking the LLM to manage authentication itself, or deploying community MCP servers without an upstream security layer. In a controlled architecture, authentication was solved a long time ago.

MCP as an interoperability standard, not as an agent engine

The current debate pits two caricatured visions against each other: “MCP everywhere” versus “MCP nowhere.” Reality, as usual, sits in between.

MCP remains an excellent interoperability standard between an AI platform and the business applications it must control. It offers a structured, versionable, documentable interface contract.

For an HRIS, ERP, or CRM publisher looking to make their application accessible through a conversational agent, MCP provides a clear framework, far more than “expose a CLI and let the LLM figure it out.”

What is problematic is not MCP as a protocol. It is the architectural pattern of exposing the entire MCP surface to the LLM and entrusting it with routing and parameter decisions.

Separate natural language interpretation from action execution. Give the LLM the role of interpreting the user. Give deterministic code the role of driving the calls. Do that, and MCP does exactly what it was designed for: a reliable integration standard between systems.

MCP is not dead

MCP is not dead. But the naive architecture that leaves the LLM alone at the controls, choosing the tool, guessing the parameters, triggering execution, deserves the criticism it gets.

At Agora, we build conversational agents for business software publishers who process sensitive data on sovereign infrastructure.

Entrusting MCP routing to a probabilistic model was never an option. Our stack relies on an LLM for interpretation, a DSL for routing, dialogs for collection, and MCP for interoperability.

Fewer tokens consumed, reliable actions, protected data, controlled authentication, and a protocol that does what is asked of it: nothing more, nothing less.