The Overhyped MCP Protocol — Now Even YC President Wants Out

The first time I heard about the MCP protocol was in November 2024.

When I saw Anthropic open-source this thing, my social media feed was full of cheers — “TCP/IP for the AI era is here!”, “Unified tool calling standard!”, “All AI applications will be able to interconnect in the future!”

As a coding veteran of several years, my first reaction was — hold the hype.

Not raining on the parade, but I’ve been burned by too many “unified standard” promises.

Look at these years: SOAP was defeated by REST; WebSocket was just getting popular when various private protocols started eating away at it; GraphQL failed to replace REST as the mainstream… When it comes to technical standards, it’s never “technically optimal” that decides, but the result of multi-party games involving ecosystem, business, and politics.

So what’s wrong with MCP?

Recently, Perplexity co-founder Denis Yarats and YC President Garry Tan publicly “jumped ship,” which lifted the lid on this.

The core conflict is one thing — token cost.

Simply put, every time you have AI call a tool through MCP, like querying a database or calling an API, the data transmitted is much larger than directly using the SDK. Why? Because MCP wraps every interaction into a “conversation,” containing system prompts, context, schema descriptions… add these up, and a simple tool call might consume hundreds or even thousands of tokens.

If you’re doing a prototype demo, this doesn’t matter.

But in enterprise scenarios, a business process might involve dozens or hundreds of tool calls. Multiply this token cost by the number of calls, and it becomes substantial.

What’s more frustrating is that MCP’s response latency is also higher than native SDKs. The logic is simple — an extra layer of protocol means an extra serialization and deserialization. In scenarios emphasizing real-time performance, this is fatal.

So Denis Yarats and Garry Tan’s choices are understandable — switch back to APIs and CLI.

This reminds me of a viewpoint: “The best protocol is no protocol.”

You directly call the SDK, no middleman taking a cut, optimal performance, lowest cost. But what’s the cost? — Each tool has to be integrated separately, migration costs are extremely high.

MCP’s logic is — sacrifice some performance and cost in exchange for interconnectivity convenience. This is theoretically correct, but the reality is that most companies’ AI applications haven’t reached the scale where they need “interconnectivity.”

In other words, MCP solves a “problem only big companies have,” while most small and medium teams are still using the most primitive ways to call tools.

That said, MCP’s vision itself isn’t wrong.

In the long run, for AI applications to truly explode, standardization is essential. Just like how USB unified the peripheral ecosystem, MCP’s value lies in lowering collaboration costs across the entire industry.

The question is just — is the timing right, is it mature enough now.

My judgment is that MCP’s direction is correct, but the landing rhythm has been overestimated. Within a year, it will be a protocol that “ambitious big companies are all paying attention to, but very few actual projects are landing.” True large-scale adoption may have to wait two to three years, when token costs truly come down and inference efficiency truly improves.

By then, MCP might achieve a status similar to HTTP — everyone uses it, but no one thinks it’s remarkable.

But for now…

Don’t rush to go all-in.

If you have MCP-related stocks, consider reducing positions on rallies. If your team is pushing an MCP solution, do a POC first to validate ROI. Don’t be misled by clickbait headlines about “TCP/IP for the AI era.”