Your MCP Server Is Probably Not Being Called

If you ship an MCP server, here is a number worth sitting with: on the same repository, the same questions, and the same index, we watched a competitor's server go from called on every single question to called on none of them, with nothing changed except which agent harness ran the loop.

We build one of the MCP servers in this story, so treat the rest of this post the way you would treat any vendor's benchmark: check the tables, not the framing. But the finding itself is not a claim about whose tool is better. It is a claim about the ecosystem every MCP server ships into, the one described in our primer on what MCP is and why a codebase needs one, and it applies to yours as much as to ours.

What we ran

We ran the same experiment twice, on the same day: once on Codex (gpt-5.6-sol), once on Claude Code (claude-sonnet-5). Nothing about any server, question, or index differed between the two runs. Only the harness did.

Codex: every tool called on every question

Every question in django's question set, six arms, byte-identical prompts, each tool's full advertised surface, and a freshly built index on the same pinned commit. Every tool was called on every question, so this is like for like.

Codex (gpt-5.6-sol) on django/django at one pinned commit. Correcting for testing five tools at once, three reductions are solid and two are marginal. 5 of the 48 questions are missing from every arm equally because the run hit an API usage cap, so the figures are over the 43 questions all six arms completed; because all arms lost the same 5, the paired comparisons are unaffected.

Claude Code: most tools barely called at all

The same six arms, the same servers and the same indexes, on a different agent harness. The result depends on the harness as much as on the tools.

Claude Code (claude-sonnet-5), 15 questions. Treat the "agent used it" column as unstable, including our own 15 of 15: rerunning the same setup on later days returned 4 of 15 and then 3 of 15 for us, and 2 of 14 for CodeGraph. It is a property of the pairing of tool and harness on a given day, not of the tool. No quality or cost figure may be compared across the two harnesses, which were graded by different judges.

The headline case is code-review-graph. It advertises 30 tools over a built, embedded graph of 40,904 nodes. Under Codex, the agent called it on all 15 questions. Under Claude Code, 0 of 15. Graphify was called 3 times in 15. Serena, which advertises 29 tools, managed 4.

None of that is a story about those servers being weak. It is a story about whether the agent ever considered calling them at all.

The mechanism, measured rather than guessed

Claude Code defers MCP tool schemas. An agent working in that harness does not start with your tools' definitions loaded into context. It has to issue a discovery call, a ToolSearch, before it can call anything you expose. We instrumented this directly rather than inferring it from the adoption numbers: across 30 Claude Code cells in this study, 17 never issued a discovery call at all.

That distinction matters. There are two different ways a tool can go unused: the agent looked at it and declined, weighing it against Grep or Read and deciding it wasn't worth the round trip, or the agent never looked at all, because the schema was never loaded into context. Not a candidate that lost. Not a candidate.

17 of 30 cells were the second kind. If you are debugging low adoption by rewriting tool descriptions or adding usage hints to your system prompt, you are optimizing for the first failure mode, and for most cells here that work never had a chance to matter.

A separate, smaller pilot makes the split concrete. On a second codebase, we appended an accurate one-line description, taken straight from each tool's own schema, to the prompt. Discovery moved: two of three previously silent cells issued a discovery call for exactly the right tools. Adoption did not: all three still declined to call anything, having now read what the tools do. Discovery and adoption are separate problems, and a fix for one does nothing for the other. Diagnose which one you have before you spend an afternoon rewriting descriptions.

Then the part that made us stop trusting our own number

The footnote under that second table gives away the ending, so here is the whole of it, because it is the part of this work that changed how we read every other number we have.

We initially took our own 15 of 15 on Claude Code as a design result: repowise's tools were named and scoped well enough that the agent reliably reached for them. That is a comforting story, and it does not survive a rerun.

We ran the identical setup again, same server, same index, same 15 questions, nothing changed on our side. It came back 4 of 15. We ran it a third time. 3 of 15. CodeGraph, over the same repeats, went from 13 of 15 to 2 of 14.

Nothing changed on anyone's side between runs. Any adoption figure, ours included, is only meaningful with its harness and its date attached.

That is not a rounding difference. It is the same measurement, on the same day's build, moving by a factor of five. Any adoption number you have published, including every one we have published before this post, needs its harness and its date attached to mean anything. A figure with neither is not wrong exactly, it is just not describing a stable property of anything.

Three explanations we killed

Once adoption on one repository collapsed to near zero, the obvious next move is to assume the agent just needs better instructions. We ran three specific tests against that assumption, on a second language and codebase, and all three came back negative or inconclusive.

The agent was already told to use the tools. Every cell's prompt explicitly named the available MCP tools and instructed the agent to start with them before reading source files. Adoption was still 2 of 9 on that run.

The agent could see accurate tool descriptions. Covered above: descriptions moved discovery, not adoption.

A question-framing change might be the cause. We A/B'd two ways of asking the same underlying question, one that reads like a diff question and one that reads like an implementation question. Adoption moved from 2 of 9 to 4 of 9, in the predicted direction, but the pre-registered rule called anything between 2 and 3 cells of movement inconclusive. It landed at 2. We are reporting it inconclusive rather than picking the reading that flatters the hypothesis.

We include the failures because the value here is partly in what did not explain the collapse. If your own adoption is low, "tell the agent to use the tool" and "describe it better" are the first two fixes you'll reach for, and on this evidence neither is likely to be enough by itself.

What this means if you are building an MCP server

A feature list is not a capability if the agent never reaches for it. Thirty tools over a 40,904-node graph and zero calls in fifteen questions is a real number about that pairing of tool and harness, worth knowing before you lead a pitch deck with your tool count. Measure adoption, the fraction of questions where the agent actually issued a successful call, not surface area.

Count adoption per arm, over that arm's own non-error cells, never over a paired set. We got this wrong once ourselves. Our analysis script computed adoption over the set of cells where both the treatment and control arm completed successfully. When a control-arm cell hit a turn-limit exhaustion and dropped out of the paired set, it silently deleted a treatment-arm cell that had actually adopted the tool. We reported 2 of 15 where the true figure, counted correctly per arm, was 3 of 15. The error was small in absolute terms and wrong in a way that would have compounded across every future comparison built on it.

Before you record a zero, prove the detector works and the server was alive. A silent zero and a real failure look identical unless you instrument the difference. We log the served tool list, the error count, and the response size on every call, so we can always tell whether "not called" means the agent declined or the server never got a chance to answer. This habit has caught bugs on the other side of the table, not just our own: one competing tool scored near-zero on a coverage metric because our extraction regex required whitespace before a file path and that tool writes references as [src=path], no space. Its real number was near the top of the field. Another returned an error on every call because its tool names carry a _tool suffix we hadn't accounted for. In both cases the zero was ours to catch, because the extractor's assumptions were built around our own output format and nobody else's. The arm that gets silently zeroed in your harness is never the one you wrote the harness for.

Schema size does not predict adoption, in either direction. Serena advertised 29 tools at 29,050 characters of schema and got called 4 times in 15 questions. CodeGraph advertised a single tool at 1,567 characters and got called 13 times. repowise advertised 10 tools at 17,561 characters and got called all 15 times. If there is a clean relationship between how much schema you ship and how often an agent reaches for it, this data does not show one, and we are not going to imply an ordering that isn't there.

What this is not

This is not a Claude Code hit piece, and we want to be specific about why.

We used Sonnet under Claude Code, and Codex ran gpt-5.6-sol. Harness and model are confounded by construction here: no vendor's CLI lets you run the identical model under both harnesses, so we cannot separate "Sonnet reaches for MCP tools less" from "the discovery gate suppresses calls" from this data alone. Both plausibly contribute. Operator experience points at the harness: Claude Code needs to be told explicitly to use an MCP server, Codex reaches for one unprompted.

We are not rounding that uncertainty away. We have said publicly that we plan to rerun the Claude Code half on Opus specifically to pull the two apart, and that run is in flight as of this writing. Until it lands, the honest claim is: this is a real, measured defect in the pairing of the most popular coding agent harness with the model we tested, and it deserves attention regardless of which of the two is doing more of the work.

The takeaway

If your MCP server's adoption number looks bad on Claude Code, that is not necessarily a verdict on your tool. Check whether the agent ever issued a discovery call before you touch a single tool description. If it didn't, you have a discovery problem, and no amount of description tuning will fix it. If it did look and still declined, you have a different problem, and the fix is somewhere in your tool's fit to the actual question, not its schema.

And whatever number you publish next, publish it with its harness and its date. Ours will keep moving, and so, almost certainly, will yours.

For the full methodology, every arm, and the numbers we are not claiming, see the benchmarks page. If you're setting up an MCP server for the first time, our setup guide for Claude Code, Cursor, and Cline covers the mechanics this post assumes.

FAQ

Why does Claude Code call MCP tools less often than Codex?

Claude Code defers MCP tool schemas rather than loading them into the agent's initial context, so the agent has to issue a discovery call before it can call anything you expose. In our measurement, 17 of 30 Claude Code cells never issued that call at all. Codex mounts the full tool surface up front, and under an identical setup it called every tool in the field on every question.

Is this a bug in Claude Code, or just how it's designed to work?

It's a real, measurable behavior on the most widely used coding agent harness, worth knowing about regardless of intent. We can't say whether it's a defect or a deliberate tradeoff (deferred schemas plausibly mean smaller initial context and faster cold start), but it changes MCP adoption dramatically compared to a harness that doesn't defer.

If my MCP server has low adoption on Claude Code, how do I know why?

Instrument the difference between "never issued a discovery call" and "issued one and declined to call the tool." They need different fixes. Never looked means a discovery and prompting problem, not a description problem. Looked and declined means the tool didn't fit that question, and that's where description or design work actually helps.

Does writing better tool descriptions fix low adoption?

It can fix discovery. In our pilot, accurate one-line descriptions moved two of three previously silent cells into issuing a discovery call. Adoption did not move: all three still declined to call anything after reading what the tools do. Treat description work as a discovery-layer fix, not an adoption-layer one, until you've measured which one you actually have.

Is a bigger tool schema better or worse for adoption?

Neither, based on what we measured. A 29-tool, 29,050-character schema got called 4 times in 15 questions; a single-tool, 1,567-character schema got called 13 times; our own 10-tool, 17,561-character schema got called 15 times. There's no clean relationship between schema size and adoption in this data, in either direction.

Why should I trust a number repowise publishes about its own adoption rate?

You shouldn't trust it more than anyone else's, which is the point of this post. Our own 15 of 15 on Claude Code fell to 4 of 15 and then 3 of 15 on identical reruns with nothing changed. We publish that instability rather than the flattering first number, and any adoption figure without a harness and a date attached deserves the same skepticism, ours included.

Where can I see the full data behind this?

The full methodology, every arm's numbers, and what we are explicitly not claiming from this run are on the benchmarks page. If you're weighing whether an MCP-based approach makes sense for your codebase at all, see how AI agents get codebase context without prompt stuffing.