.png)
1 hour ago
1
I’m going to say something that’ll piss off half of tech Twitter: MCP is fundamentally broken, and we’re all acting like it’s not.
Anthropic published a blog post celebrating how they made MCP “efficient.” They reduced token usage from 150,000 to 2,000. Incredible! Except… they did it by essentially not using MCP the way MCP was supposed to work.
The solution to MCP being inefficient is to… bypass MCP.
The Part Nobody Wants to Say Out Loud
Here’s what’s actually happening: MCP loads every single tool definition into your context window upfront. Every. Single. One. If you connect to a few servers with hundreds of tools, you’re burning through 150,000 tokens before Claude even reads your actual question.
Then, when you ask Claude to do something simple like “grab this doc from Google Drive and attach it to Salesforce” the data flows through Claude’s context twice. Once to read it. Once to write it somewhere else.
A 2 hour meeting transcript? That’s 50,000 tokens. Twice. For one task.
This isn’t a bug. This is how MCP works.
And Anthropic’s solution? Don’t let Claude call the tools directly. Instead, have Claude write code. That code calls the tools. Run the code somewhere safe. Filter what comes back. Show Claude only the parts that matter.
You see the problem, right? We built a thing to connect AI to tools. Now we’re connecting AI to code that connects to the thing that connects to tools.
We’re Building an Industry on Quicksand
Here’s what kills me: while MCP is still figuring out how to not burn your entire token budget on tool definitions, people are already building startups around it. Entire companies. With funding. With roadmaps.
The protocol launched in November 2024. It’s barely a year old. And we’re treating it like HTTP.
Thousands of MCP servers have been built. SDKs in every language. The “MCP ecosystem” is exploding. But here’s the uncomfortable question nobody’s asking: are people building these because they solve real problems, or because MCP exists and they want to be part of the wave?
I’ve seen this pattern before. GraphQL was going to replace REST. Microservices were going to kill monoliths. Everyone ripped apart working systems because the conference talks said to.
How’d that go? Most teams added complexity they didn’t need and spent two years undoing it.
The Code Execution “Fix” Is Admitting Defeat
Anthropic’s blog post is fascinating if you read between the lines. They’re essentially saying: “MCP as originally designed doesn’t scale, so here’s a completely different way to use it.”
Now, instead of:
- Load tool definitions
- Let Claude call tools
- Get results back
You do:
- Generate a fake filesystem of all your tools
- Let Claude browse the filesystem
- Let Claude write TypeScript code
- Run that code in a sandboxed environment
- Only return the final result to Claude
This isn’t iteration. This is admitting the original design was wrong.
And sure, it works better. It’s clever even. But it’s clever in the way that duct taping a spoiler onto a Toyota Corolla is clever. Like, technically it’s doing something, but maybe you bought the wrong car?
The Real Cost Nobody’s Talking About
Here’s what really bothers me: all these MCP startups and side projects and “ecosystem plays” they’re building on sand. They’re betting their time, their money, sometimes their companies on a protocol that needs workarounds to function.
And when someone points this out, the response is always: “Well, it’s just v1, it’ll get better.”
Will it though? Because the fundamental problem isn’t implementation details. It’s the core assumption that you need a universal protocol for tool calling in the first place.
Maybe the reason direct API calls feel clunky isn’t because we need MCP. Maybe it’s because:
- AI models need to get better at using APIs
- APIs need to be designed with AI in mind
- We need better libraries, not better protocols
But that’s boring. That’s incremental. That doesn’t get you on stage at conferences talking about “the future of AI infrastructure.”
The Only Question That Matters
If the best way to use MCP is to write code that doesn’t directly use MCP’s core feature (direct tool calling), what exactly is MCP doing?
I don’t know the answer. But I know we should be asking it before we build an entire industry on top of a protocol that needs to be worked around to function.
Maybe I’m wrong. Maybe in five years, MCP will be everywhere and this will read like someone complaining about HTTP in 1995.
But I don’t think so.
I think we’re building on quicksand and calling it bedrock. And when it eventually gives way, a lot of people are going to lose their footing.
The question is: will we see it coming, or will we be too busy celebrating our 98.7% token reduction to notice?
