The MCP Gold Rush
Every SaaS landing page now has "MCP supported" in the feature list. Whether the MCP server is stable, how much context it eats, or if it actually works — none of that seems to matter. The goal is simple: check the box that says "we do MCP too."
This pattern looks familiar. It's the same playbook we saw with "AI-powered" in 2023 and "blockchain-based" in 2019. The marketing wave crests before the technology proves itself.
What MCP Actually Is
MCP (Model Context Protocol) connects LLMs to external tools — GitHub, Linear, Notion, Slack, databases. Think of it as a standardized API layer between your model and every service it needs to talk to.
The restaurant analogy from the original article puts it well: give LLMs a CLI first, then an API, then docs — in that order. LLMs already learned from man pages and StackOverflow. They can figure things out.
Where MCP Falls Short
When users actually connect to an MCP server, the experience is often underwhelming:
- Token bloat: dozens of tool definitions loaded upfront, eating context windows
- Init failures: authentication and handshake problems that kill sessions
- Mid-session crashes: connections that drop when you need them most
- Stability gaps: servers that work on Monday and break on Tuesday
When MCP Actually Earns Its Keep
MCP isn't useless — it's just oversold. It makes sense when:
- A service has no CLI at all
- You need uniform authentication across a team
- The MCP server is actually maintained and stable
- Your context window isn't the bottleneck
The Real Takeaway
MCP will survive — but not as the universal integration layer it was promised to be. It will settle into specific niches where it genuinely solves a problem that CLI wrappers and direct APIs can't.
The hype cycle is ending. What's left is a tool that developers will use when it makes sense, not because a landing page told them to.
Build for utility, not for the feature list.