Your MCP Server Is Probably Not Being Called

If your MCP server looks unused under Claude Code, the agent most likely never looked at it. On the same repository, questions and index, one server went from called on all 15 questions under Codex to called on none under Claude Code. In 17 of 30 Claude Code cells we measured, the agent never issued the discovery call that loads an MCP tool's schema, so the tool was not a candidate that lost, it was never a candidate.

We build one of the servers in this study, so check the tables, not the framing. The finding applies to every MCP server shipped into this ecosystem, ours included. If you are new to the protocol, start with what MCP is and why a codebase needs one.

What we ran

We ran one experiment twice on the same day: on Codex (gpt-5.6-sol) and on Claude Code (claude-sonnet-5). Servers, questions and indexes were identical. Only the harness differed. Full method and every arm are on the benchmarks page.

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

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. The same 15 questions on Opus called repowise on 7, inside the band fixed in advance as inconclusive, and that run's token column failed its own control, so no token figure is quoted from it. No quality or cost figure may be compared across the two harnesses, which were graded by different judges.

The sharpest case is code-review-graph, which advertises 30 tools over a built graph of 40,904 nodes. Under Codex the agent called it on all 15 questions. Under Claude Code the result was 0 of 15. Graphify was called 3 times in 15, and Serena, which advertises 29 tools, 4 times. These are facts about the pairing of tool and harness, not about the tools.

Why do MCP tools go uncalled in Claude Code?

Claude Code defers MCP tool schemas. Tool search is on by default with current Claude models: the agent starts with tool names, not definitions, and issues a ToolSearch discovery call before it can call anything you expose.

We instrumented this directly instead of inferring it from adoption: across 30 Claude Code cells, 17 never issued a discovery call. A tool goes unused in one of two ways. The agent weighs it against Grep or Read and declines, or the schema never enters context and there is nothing to weigh. Those 17 cells were the second kind.

If you are debugging low adoption by rewriting descriptions or adding prompt hints, you are tuning the first failure mode while most cells had the second.

Do better tool descriptions fix it?

Descriptions move discovery, not adoption. In a smaller pilot on a second codebase, we appended an accurate one-line description, taken from each tool's own schema, to the prompt. Two of three previously silent cells then issued a discovery call for exactly the right tools. All three still declined to call anything after reading what the tools do.

Discovery and adoption are separate problems, and a fix for one does nothing for the other.

How stable is an adoption number?

Not very, which is why we attach a harness and a date to every one. Our own server went through three identical Claude Code runs with nothing changed:

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

The measurement was the same, on the same day's build, and moved by a factor of five. CodeGraph moved from 13 of 15 to 2 of 14 over the same repeats. Treat any adoption figure as a reading of one harness on one date.

What else we tested

We ran three tests on a second language and codebase to see whether better instructions explain the gap.

• Explicit instruction. Every prompt named the MCP tools and said to start with them. Adoption was still 2 of 9.
• Accurate descriptions. Covered above: discovery moved, adoption did not.
• Question framing. We asked the same question as a diff question and as an implementation question. Adoption went from 2 of 9 to 4 of 9, in the predicted direction. Our pre-registered rule called 2 to 3 cells of movement inconclusive, and it landed at 2, so we report it as inconclusive.

How to measure MCP adoption in your own server

Measure per arm, and prove the detector first.

• Count adoption per arm, over that arm's own non-error cells. Counting over a paired set silently drops an adopting cell whenever the other arm hits a turn limit. That one rule changed a figure from 2 of 15 to 3 of 15 in our analysis.
• Log the served tool list, the error count and the response size on every call. That is how you tell "the agent declined" from "the server never got to answer." The same logging showed that two competing tools were scored too low by our extractor: one writes references as [src=path] with no leading space, another suffixes its tool names with _tool. Both zeros were ours to fix, and fixing them put those tools near the top of the field.
• Do not lead with tool count. Serena advertised 29 tools at 29,050 characters of schema and was called 4 times in 15. CodeGraph advertised one tool at 1,567 characters and was called 13 times. repowise advertised ten tools at 17,561 characters and was called on all 15. Schema size showed no relationship with adoption.

Is this a Claude Code problem or a model problem?

The data cannot separate the two. No vendor CLI runs the same model under both harnesses, so harness and model are confounded here. Operator experience points at the harness: Claude Code needs to be told explicitly to use an MCP server, while Codex reaches for one unprompted. We are rerunning the Claude Code half on Opus to pull the two apart.

What to do if your MCP server is not being called

1. Check whether the agent issued a discovery call before touching any description.
2. If it did not, you have a discovery problem. Make sure the server is registered where the harness expects it and that the user's instructions name it.
3. If it did and declined, the tool did not fit the question. Work on what the tool returns, so one call ends the task.
4. Publish adoption with its harness and date.

For the setup mechanics, see setting up an MCP server in Claude Code, Cursor and Cline, and for the design side, how agents get codebase context without prompt stuffing.