Analysis of 4,951 MCP servers finds tool descriptions lose distinctiveness past ~30 tools

The number, and where it came from

Anyone who maintains an MCP server eventually wonders how many tools it should expose, and until now there has been almost no evidence to answer with. An analysis published on dev.to by the developer building MCPulse, an SDK intended to report what models actually do with tools once real traffic arrives, parsed the schemas of 4,951 public servers — 87,146 tools and 270,487 parameters in total — and landed on a figure: around thirty. Beyond that point, the argument goes, the concern shifts from whether the server works to whether a model can still tell its tools apart.

Measuring distinctiveness

For each tool, the author computed what they call its distinctive share: the content words in its description that appear in no other tool's description on the same server. A tool scoring zero gives the model nothing in the prose to choose between, so the tool's name has to carry all the differentiation on its own.

Grouped by server size, the share of zero-distinctive tools rises steadily: 0.5% on servers with one to three tools, 1.6% at four to seven, 4.3% at eight to fifteen, 7.7% at sixteen to thirty, 16.3% at thirty-one to sixty, and 31.3% on servers with more than sixty tools — nearly one tool in three with no distinguishing word at all. Across the buckets that is roughly a sixty-fold increase.

Why the curve steepens around thirty

Part of the trend is arithmetic: more tools simply means more chances for two descriptions to overlap. But the author attributes the sharper bend near thirty to a change in authoring behaviour. Past that size, descriptions stop being written one at a time and start being generated from a pattern, and templated text produces tools that read alike. The starkest example in the corpus is a server that appends an identical 51-word context block to all 275 of its tools, leaving a create-collection tool and a buy-NFT tool differing in only eight of fifty-nine words.

Well-written is not the same as distinguishable

The analysis makes a counterintuitive point using a widely installed Gmail server. Tools for deleting a draft, sending a draft, listing labels and searching threads are each described in plain, correct English that no reviewer would flag — yet every word in those descriptions, from delete and draft to email, API, list, search and mailbox, recurs across the set. A description can say what a tool does without saying what this tool does that its siblings do not, and the second property is what a model needs at the moment it picks.

Splitting the server fixes only one failure

A second metric in the data, the share of parameters with no description at all, barely moves with server size: between roughly 20% and 25% at every level above the smallest bucket, where it is 14.8%. A two-tool server has the habit about as much as a two-hundred-tool one. The conclusion is that the two problems are independent — splitting a large server reduces description collisions but does nothing for undescribed parameters, which need their own fix.

What maintainers should actually do

The recommendation is to split when collisions are real, not because a threshold was crossed. Thirty is a population average; a forty-tool server of genuinely distinct operations may be fine, while a twelve-tool server with four near-identical search variants is not. The proposed test is to read the tool list as one block, the way a model receives it, without README or repository context, and ask which tool you would pick for a request that could plausibly go to two of them.

When the answer is unclear, three remedies follow. Rewrite descriptions for contrast rather than clarity, dropping shared preambles that dilute the one distinguishing sentence. Collapse near-identical tools into a single tool with a mode parameter, which moves the model's choice from picking a tool to picking a value that an enum can constrain. Or split the server, worthwhile when the tools genuinely belong to different domains and less so when it merely halves an arbitrary list.

Known limitations

The study is static analysis: no model was run against these servers, so it cannot say how often a zero-distinctive description actually causes a wrong choice, or how much an unambiguous tool name compensates. Ranking the signals against real mistakes requires a model in the loop, which the author identifies as the next study. The parameter figure also measures absence only — a description that merely restates the parameter name still passes, a gap flagged by a server author after publication — so the reported share is a floor. The dataset and analysis scripts have been published on GitHub, and a free browser-based checker scores an individual server's tool list against the corpus.

Why it matters

MCP is becoming a standard interface between models and external software, and this is among the first population-scale evidence on how server design shapes what a model can see. Its most useful contribution is a reframe: the constraint is not raw tool count but whether descriptions discriminate, a property that degrades predictably with size and with templated authoring. It also punctures the easy fix by showing that splitting addresses only one of two independent failure modes. For anyone shipping MCP servers that agents will browse at runtime, writing descriptions is interface engineering with measurable failure modes, not documentation polish.