Most MCP servers are answering the wrong question
Figure out what the agent needs to do. Build the server that gives it exactly that.
đ Hi, Iâm Thomas. Welcome to a new edition of Beyond Runtime, where I dive into the messy, fascinating world of distributed systems, debugging, AI, and system design. All through the lens of a CTO with 20+ years in the backend trenches.
QUOTE OF THE WEEK:
âFor me, a focus on software engineering over programming is essential. Those with a core understanding of core principles and fundamentals will still be demand as evolving and maintaining and production quality systems will still be required and likely harder.â - Pat Kua
Iâve been speaking at conferences a lot this year, and I always open with the same three questions from the stage.
How many of you are using coding agents? (Almost every hand goes up.)
How many are using MCP in some form? (Most stay up.)
How many are implementing MCP servers in your team or personally? (A handful of brave souls.)
That gap is interesting. MCP adoption is everywhere. MCP implementation is rare no matter what memes on social media might indicate otherwise. And from what Iâve seen of the servers that do get built, most of them collect dust within a few weeks of shipping.
I think I know why. It comes down to the question teams ask when they start building.
The question most teams ask
When you set out to build an MCP server, the natural starting point is: how do I give the AI access to my data?
So you build a server that exposes your APIs. You mirror your platformâs endpoints. You give the agent a wide surface of tools and trust it to figure out whatâs relevant.
This sounds reasonable. But, ultimately, itâs the wrong question.
We made this mistake at Multiplayer. Our V1 debugging agent mirrored our observability API and gave the coding agent a broad set of tools to choose from. The agent called the wrong tools. Used wrong parameters. Burned through tokens. Produced fixes that looked plausible and failed in production.
What ends up happening
Thereâs solid research on this now, and it matches what we experienced: agents perform worse with more tools. More options make them more confused.
The Berkeley Function Calling Leaderboard measured accuracy dropping from 43% to 2% on scheduling tasks when the tool count expanded from 4 to 51. The RAG-MCP paper found agents facing large tool sets selecting the right tool just 13.62% of the time. And the degradation isnât gradual: performance holds through roughly 10 to 20 tools, then falls off a cliff.
The token overhead compounds the problem. Anthropicâs own testing found that 58 tool definitions consume roughly 55,000 tokens before the user asks a single question. Thatâs a significant chunk of your context window spent describing options the agent will mostly never use, and you pay for those tokens on every turn.
The better agents have gotten smarter about this: lazy loading, tool search, progressive disclosure. But as a server developer you canât control how every client loads your tools. You have to design for the worst-case agent, and the worst-case agent loads everything eagerly and promptly gets confused.
Vercelâs engineering team ran into the same wall we did. Their AI sales agent performed significantly better after they deleted roughly 80% of its tools.
Fewer, more intentional tools produce better outcomes.
The question you should be asking
Hereâs the reframe that changed how we build at Multiplayer.
Stop asking: how do I give the AI access to my data?
Start asking: what does the agent need to understand about this specific problem in order to fix it?
Those questions lead to completely different architectures.
The first question leads to raw data exposure. The second leads to curation. Do the work of understanding what the agent needs before it ever makes a request, and package that as the thing the tool returns.
For us, in the debugging context, that meant a single tool that returns a structured package: the correlated timeline of what broke, where it broke, when it started, what changed recently, what the error looks like when it surfaces, and the request/response context that standard observability tools donât collect. Formatted for an agent to reason about, rather than for a human to read on a dashboard.
What this means beyond debugging
Debugging is our domain, but the principle isnât specific to it.
If youâre building an MCP server for customer support, the question isnât âhow does the agent access the ticket system?â Itâs âwhat does the agent need to understand about this customerâs situation to give a useful response?â That probably means a tool that returns a pre-summarized customer history, recent interactions, and open issues. Raw API access to every field in your CRM gives the agent more to get lost in.
If youâre building for code review, the question isnât âhow does the agent access the diff?â Itâs âwhat does the agent need to understand about the intent of this change to review it correctly?â That might mean surfacing the linked ticket, the relevant test failures, and the architectural context alongside the lines changed.
The pattern is the same everywhere: figure out the agentâs job first, then design the data access around what that job actually requires. The serverâs purpose is to answer a question on behalf of the agent. Itâs not there to hand the agent a library and wish it luck.
The three generations of MCP servers
Iâve started thinking about MCP servers in three generations.
The first generation exposed data. Mirror your APIs, connect AI to your systems, give it access. Most of these are the ones collecting dust. The agent gets confused, burns tokens, and the developer gives up and calls the API directly.
The second generation enables workflows. Answer the right question, curate the right data, give the agent what it needs to do a specific job. These are the servers that actually work. The ones that get adopted and stay adopted.
The third generation, where I think this is heading, will enable agents to work autonomously. Servers that donât just respond to queries but proactively surface the right information at the right time. Triggers that notify agents when something needs attention. Tools that hand off to other tools across server boundaries. The MCP roadmap is building toward this: skills, programmatic tool calling, cross-app access.
The teams whose MCP servers went quiet a few weeks after shipping are there because they started with âhow do I give the AI access to my data?â and never questioned whether that was the right place to start.
đ This newsletter is sponsored by Multiplayer.app, the debugging agent for developers.
đ Interesting Articles & Resources
âCode Review Bench: Towards Billion Dollar Benchmarksâ - Aleksandr Zverianskii, Jacob Clyne, AntĂa Garcia, Fazl Barez, Shriyash Upadhyay
The best AI code review tool still misses a third of known bugs, and the benchmark data proving it is public. Martian's Code Review Bench tracks 200K+ real PRs and compares what review tools claim to catch against what developers actually act on. It's also a sharp read on why AI benchmarks keep breaking (SWE-bench in Feb 2026 died because models memorized the answers) and what it takes to build one that self-corrects. If you're relying on PR review as your quality gate for AI-generated code, the numbers here are worth ten minutes of your time.