Why every MCP server you're using is probably broken.
Gil Feig, Co-Founder & CTO at Merge
The MCP hype cycle is real. Anthropic released the standard. GitHub exploded with implementations. Everyone wanted to be first to market with their MCP server. Which is exactly why most of them don’t work.
“I think it started with marketing,” Gil Feig, CTO of Merge, told me. “Everyone just wanted to have something out there to kind of, yeah, be first to market and say, we support MCP and all of that.”
That’s not a jab at individual teams. It’s a pattern. When you’re shipping to claim feature parity, you ship first, test later. Or you don’t test at all.
“And I think the problem was they didn’t expose a lot of tools. They didn’t make things super reliable. They didn’t test really deeply. And so ultimately, you end up with all these tools out there that people tested once and were like, this doesn’t work super well. I’m not going to use this.”
You’ve probably experienced this. You see an MCP server that looks relevant to your use case. You install it. You try to use it. It works once. The next request fails differently. You dig into the issues on GitHub and find six months of unanswered questions. You move on. The tool becomes abandoned middleware in your stack.
Why reliability isn’t optional
MCP is conceptually clean. “It’s like an API built for agents,” Gil said. The idea is that you expose discrete tools to an agent, the agent calls them, and you get deterministic behavior. No API key exposure. No scope creep. Just a narrow interface.
The execution is another story.
Most MCP servers are side projects. They’re shipped to add credibility to a larger product or to experiment with the standard. They’re not built by teams who make integrations for a living. They’re not tested against edge cases. They’re not maintained when the upstream API changes.
“Auth is not super easy with MCP,” Gil noted. That’s understating it. Authentication, permissions, scoping, error handling, retries on failure — these are the boring engineering problems that separate a prototype from a product. Most MCP servers skip them.
When you have too many broken tools connected to an agent, the problem compounds. The agent’s performance degrades. It starts confusing one tool with another. It sends requests to the wrong endpoint. It fails silently because the error handling was an afterthought.
“You end up with all these tools out there that people tested once and were like, this doesn’t work super well. I’m not going to use this. Also, auth is not super easy with MCP. And so actually getting connected and making it all work is just difficult.”
What Merge does differently
At Merge, they rebuilt the integration layer from scratch. They don’t use any official MCP servers. They built their own. For every service that matters.
“We rebuild all of them,” Gil said. “We cover all tools. So we basically cover anything that’s needed for common use cases because again, we’ve become experts in this space over six years.”
That’s not paranoia. That’s having shipped hundreds of integrations across thousands of customers and learned what breaks. They know that Jira APIs behave differently depending on whether you’re using Cloud or Server. They know that Salesforce custom fields vary wildly per customer. They know that error messages are often nonsense and you have to dig deeper.
“And then lastly, we train over all of the ticketing data that we have from customers who have ever reported bugs or edge cases.”
That’s the key. They’re not just building integrations. They’re building them informed by years of production failures. Every edge case a customer hit becomes a data point. Every broken integration becomes a test case.
That level of rigor costs something. It’s not a weekend project. It requires a team. It requires testing. It requires ownership. Most MCP servers don’t have that.
The gap between shipped and useful
Anthropic did something valuable by releasing the MCP standard. It gave a shape to how agents should interface with external tools. But a standard isn’t an implementation. And there’s a huge gap between implementing a standard and implementing it reliably.
“A lot of the APIs at these big companies haven’t been touched in years. And so you have people trying to tack on MCP servers with no real connection to the problem.”
When you ship an MCP server as a checkbox feature, you inherit that gap. You inherit the maintenance burden. You inherit the support load when users hit edge cases. Most teams aren’t positioned for that.
The responsible move is to either commit to owning the integration or use an integration platform that has. Gil’s team chose the latter for their own use cases. Not because MCP is bad. Because reliability requires depth, and depth requires commitment.
If you’re evaluating an MCP server before you connect it to production, that’s the question worth asking: Did the team who built this actually commit to reliability, or did they ship a demo?
FAQ
Is MCP itself broken? No. MCP is a useful standard. The problem is the ecosystem of implementations. Most servers exist but aren’t production-grade. Anthropic didn’t promise to maintain all MCP servers — they released the spec. The burden is on the teams shipping them.
How do I know if an MCP server is reliable? Look at the test coverage. Look at whether the team is actively maintaining it. Look at error handling. Look at whether they’ve handled the weird edge cases (different API versions, custom fields, rate limits). If they’ve built just the happy path, it will fail in production.
Should we build our own MCP servers? Only if you’re willing to maintain them. That means testing against different configurations. Handling errors. Updating when the upstream API changes. If you’re not, use an integration platform that has that expertise.
Why did Merge rebuild everything from scratch? Because they wanted to guarantee reliability at scale. They have thousands of customers with wildly different setups. They couldn’t afford to ship a half-baked integration. For a smaller team with fewer customers, the cost-benefit might be different.
Are some MCP servers getting better? Yes. Gil mentioned that some platforms have shipped better MCP servers over time. But the vast majority are still unusable. If you’re looking to use one, assume it’s broken until proven otherwise.
What’s the difference between MCP and a unified API platform? MCP gives you a standard way for agents to call tools. A platform like Merge gives you that interface backed by years of integration expertise. MCP is the shape. The platform is the substance.
Can we just wait for MCP to mature? You could, but reliability isn’t something that comes from waiting. It comes from people actually maintaining the servers. If you need reliability now, don’t bet on the ecosystem improving.
If MCP servers are broken, why are people using them? They’re testing them. Most teams that try MCP servers find they work for simple use cases, then hit edge cases and abandon them. The server isn’t fully dead — it’s just not trusted for production.
Full episode coming soon
This conversation with Gil Feig is on its way. Check out other episodes in the meantime.
Visit the Channel