Is MCP dead on arrival? The internet is furiously debating this after Perplexity CTO Denis Yarats said the company was moving away from MCP in favor of APIs and CLIs. Garry Tan, the President of Y Combinator, echoed the sentiments in a recent tweet. Now, developers are picking sides on whether MCP is overkill or necessary to realize AI agents for enterprise teams.
The critics have merit; something is broken right now. Context overhead and auth friction are real problems for devs, but the root cause lies in tooling and implementation. MCP detractors will tell you otherwise, but many are evaluating this standard based on the quality of open-source servers in the wild today. Servers that haven’t yet caught up to MCP’s current state.
Take a closer look at the protocol’s adoption, contributor quality, and ecosystem momentum, and the data tells a different story: MCP has already won.
The Right Problem, But the Wrong Target
The frustration devs are experiencing is real. Vague tool definitions, missing schemas, broken error handling. Most MCP servers are thin API wrappers that dump raw responses into the context window regardless of what the agent actually needs…these are all symptoms that lead to genuinely bad experiences. But these are all indictments of specific implementations.
That’s in part because the loudest criticism is aimed at versions of MCP that no longer exist. The protocol has evolved significantly, and in a space that moves this fast, last year’s spec is already obsolete. The target has moved.
Casting a final judgment on MCP based on poor open-source server experiences is like judging USB-C by the cheapest third-party cable on Amazon. The protocol sets the standard, and the ecosystem decides how well it’s met. The ecosystem always lags behind the protocol; it’s par for the course for any standards adoption curve.
Yes, it’s true that MCP is heavier than it needs to be in places, and it does some things well while handling others less elegantly. Open-source server quality is genuinely variable, and many MCP clients are still catching up. But these are engineering problems to be solved. If the tooling can be fixed, then the overhead will disappear.
What the Data Actually Shows
Anthropic recently donated MCP to the Agentic AI Foundation (under the Linux Foundation), a deliberate signal of what MCP is and is not. The protocol has been designed as a neutral standard, not a proprietary bet, and it’s open across the dev community. Major platforms like Figma and Linear are already shipping high-quality first-party MCP servers. These companies are making it easy for AI agents to work with their platforms: no special permission needed, and no proprietary hoops to jump through. Stripe went a step further. Just last month, the company debuted the Machines Payments Protocol, a new open standard that lets AI agents transact autonomously. MCP is simply one of the many endpoints Stripe’s protocol can work with, and how new open source standards can coexist shows us where the industry is heading.
I speak with dozens of enterprises each month, and recent conversations all echo the same bet on MCP. At a recent CIO event, I didn’t meet a single enterprise moving away from MCP. No one is debating whether they need a connectivity standard. The debate has moved past protocol selection entirely. What enterprise security and platform teams are wrestling with now is operationalization: how to enforce least-privilege scoping across hundreds of agent-to-system connections, how to maintain audit trails that satisfy their compliance teams, and how to do all of it without rebuilding auth infrastructure from scratch for every new tool. The protocol question is settled. The implementation question is wide open. That gap is exactly why we built Arcade.dev.
Not everyone sees that as an opportunity. The holdouts on MCP also help tell the story. Companies like Slack (Salesforce), talent platforms like Workday and LinkedIn, and social giants like Meta and Discord are making it harder (sometimes deliberately!) for AI agents to work with their platforms. I recently spoke with Laura Bratton at The Information about why these companies are resisting their customers’ AI agents. They say the lockdown on agents is to protect security and privacy, but the elephant in the room is that open agents could hurt SaaS companies’ ability to keep users contained and paying for their proprietary features and products.
But resistance from incumbents isn’t evidence of protocol weakness. It’s evidence of protocol power. It’s hard to imagine that SaaS’s biggest darlings would have this kind of reaction to a protocol that’s losing. Standards don’t win on immediate technical perfection. TCP/IP wasn’t perfect, and neither was HTTP. They won out because they crossed the threshold where switching costs exceeded the benefits of any alternative. At the protocol level, this is how MCP is running away with the lead. Other standards, like Google’s competing A2A, have struggled to gain traction as MCP’s spec has expanded to cover much of the same ground. To date, no credible challenger has emerged with real usage, heavyweight contributors, and ecosystem momentum to match MCP.
Protocol Is Not Implementation
The debate raging over whether MCP is the right standard misses the forest for the trees. The core friction driving the conversation is that most MCP implementations simply aren’t that good (yet).
Arcade.dev’s new MCP benchmark, ToolBench, makes this clear. It evaluates MCP servers across definition, protocol readiness, and real-world support, and the variance ToolBench surfaces is enormous. Many open-source servers aren’t running on the current protocol state. Compound this lag with poor open-source MCP support from popular enterprise tools, and you can see why MCP’s critics are becoming more vocal. However, their real grudge is against builders who haven’t yet implemented MCP well.
A similar confusion crops up in how people talk about competing standards. Agent Skills and MCP solve different problems and work better together than apart. MCP is how an agent connects to Gmail, and skills are the knowledge layer that tells the agent how to write that email once it’s there. They’re orthogonal, and actually pair well together, which is why conflating them leads to exactly the kind of bad architectural decisions that make poor MCP implementations underperform.
Setting the Bar
New standards will continue to emerge, but they’ll solve different problems. Even callbacks to CLI, touted by Perplexity and Garry Tan, make sense. Developers want to type a command, but ultimately that command still has to hit Salesforce, GitHub, or a healthcare system, where something has to handle auth, scope permissions, and log the action.
In fact, our Head of Engineering, Evan Tahler, got tired of this exact type of problem and built MCPX, curl for MCP. With MCPX, the developer types a command and the infrastructure handles the rest. Tools like this prove that long-running, tool-calling agents that can access and act across business systems today run on MCP. No other standard can do this right now.
If you want to see what production-ready MCP actually looks like in practice, that’s what we built Arcade.dev for. Come build on it.
