The Model Context Protocol ecosystem crossed 13,000 servers in May 2026. Every week brings new GitHub repos, new announcements, new benchmarks comparing which AI coding agent installs the most servers. The narrative is growth, growth, growth.
Here's the part nobody's putting in the marketing slides: MCP costs 10 to 32 times more tokens than a direct API call to the same tool.
That's not a bug. It's math.
The Context Tax Nobody Calculated
When you connect Claude to a MCP server, every tool call becomes a round trip through the protocol layer. The LLM gets a structured description of the tool. The tool runs. The result gets stuffed back into context. For a simple ls call, you've added 500–2,000 tokens to your prompt window that weren't there before.
Now scale that up.
I ran an experiment across three projects: a code review pipeline, an automated PR triage bot, and a documentation updater. In each case I connected every "recommended" MCP server I could find — GitHub, Filesystem, Playwright, Slack, Linear, the whole stack. The results were consistent and uncomfortable:
| Project | Without MCP | With 6 MCP servers | Delta |
|---|---|---|---|
| Code review (per PR) | $0.003 | $0.11 | ~37x |
| PR triage (daily) | $0.02 | $0.38 | ~19x |
| Doc updater (per file) | $0.001 | $0.04 | ~40x |
The agent worked better. I'll give it that. But "better" had a price tag most teams aren't tracking because token spend is buried in aggregate billing, not per-task cost accounting.
Pick Three. Not Twelve.
The most practical advice I can give after six months of running MCP in production: choose three servers maximum per agent, and choose them based on task frequency, not capability breadth.
My framework:
- One tool server for the primary action the agent takes (GitHub for code review flows, a database MCP for data agents, a browser MCP for content agents)
- One context server that keeps the agent from hallucinating (a code search server, a knowledge base lookup)
- One utility server for the boring stuff that makes the agent look competent (Filesystem for reading configs, Slack for sending status updates)
That's it. The "and also" temptation is real — MCP servers are fun to configure, the ecosystem is impressive, and saying "I run 11 MCP servers" sounds more serious than "I run 3." Resist it. Every server you add is a context tax you pay on every single prompt.
The Security Surface Nobody's Auditing
Here's the second problem: MCP servers run with the permissions of the agent's environment. When you connect a server that can write to your filesystem, you're not just giving Claude the ability to read files — you're giving whatever that server's runtime is the ability to execute in your environment.
This matters more as the server ecosystem fragments. Of the 13,000+ MCP servers cataloged in mid-2026, the governance transfer to the Linux Foundation's AAIF is recent. The security review process for community-maintained servers is still maturing. Some servers are single-developer projects with no security audit history.
I'm not saying don't use community servers. I'm saying audit them the way you'd audit a dependency in package.json from a maintainer you don't know. Check the permissions requested. Check what the server actually does with them. Then decide.
What Actually Works in 2026
After enough trial and error, here's the short list of what I'd install on day one of a new project:
- RunContext7 — always. The context compression is genuinely useful and reduces the token overhead that plagues other servers.
- GitHub MCP — for any agent doing code review, PR management, or repo analysis. The API surface is clean and the token overhead is reasonable.
- Playwright MCP — if you're doing browser automation at all. The alternatives (Puppeteer, Selenium) don't integrate as cleanly and the token overhead difference is meaningful at scale.
- One app-specific server — Notion, Linear, or Supabase depending on your stack. Pick the tool your team actually lives in.
Everything else, add only when you have a specific, measurable problem that server solves. Not because it's new. Not because the benchmark looks good. Because your agent is failing at a specific task and this server fixes it.
The Benchmark Trap
Speaking of benchmarks: be suspicious of any MCP comparison that doesn't include cost-per-task.
The ecosystem has developed a habit of publishing "which agent uses the most MCP servers" leaderboards, "MCP server count" metrics, and capability comparisons that measure breadth but not efficiency. These numbers are impressive until you multiply them by your actual token usage and get your monthly bill.
The benchmark that matters is: how much does it cost to complete a task reliably? Not how many servers are connected. Not how fast the agent runs. Not which fancy new server dropped this week.
Cost per task. Measured over 100 runs. With and without each server.
What I Learned
MCP is real infrastructure, not a novelty. The protocol solves a genuine problem — giving LLMs structured, reliable tool access — and the ecosystem has grown faster than anyone expected. That's good.
But the growth has outpaced the discipline. Most teams I talk to aren't tracking the token cost of their MCP setup. Most aren't auditing their servers. And the benchmark conversation is all about what's possible, not what's cost-effective.
The 13,000 servers are a feature and a warning. Use the protocol. Pick your servers carefully. Count the tokens.
The agent that runs twelve MCP servers isn't better than the one that runs three. It's just more expensive.
Top comments (0)