Past thirty tools, MCP servers' tool descriptions start to blur together

The metric is cheap to reimplement. For each tool, take the content words in its description and count how many appear in no other tool's description on the same server ^[3]. If that count is zero, the descriptions give a model nothing to choose on, and the tool names carry the whole decision ^[4].

It is a lexical test, run per server. Two tools can do entirely different things and still score zero. Four descriptions from a widely installed Gmail server show how: "Delete a draft email using the Gmail API.", "Send a draft email using the Gmail API.", "List all the labels in the user's mailbox.", "Search for threads in the user's mailbox." ^[12]. All four are clear, correct English that no reviewer would flag, and each is built entirely out of words the other tools use ^[13]. "The description tells you what the tool does. It doesn't tell you what this tool does and the others don't," the post's author wrote ^[14].

The post does not report a model evaluation. What it measures is description text ^[3] and missing parameter descriptions ^[15]. It frames the failure as a model's inability to tell sibling tools apart ^[2], and that step is an inference from the words on the page, not a measured selection error rate ^[21].

87,146 tools across 4,951 servers is 17.6 tools per server ^[1], so the thirty-tool threshold sits above the typical server and the collisions concentrate in the tail. The author reports the rise across size buckets as a factor of sixty, monotonic ^[5]; if that span runs from the smallest bucket to the largest, the smallest bucket sits near half a percent ^[6]. The undescribed-parameter rate behaves differently. At 3.1 parameters per tool ^[2] and the reported 20 to 25 percent with no description at all ^[15], roughly 54,000 to 68,000 parameters in this corpus ship undescribed ^[3]. The rate holds from two-tool servers to two-hundred-tool ones ^[15].

The extreme case in the corpus is one server that appends the same 51-word context block to all 275 of its tools ^[9]. That is 14,025 words of identical text in a single tool list ^[4]. "Create a new NFT collection on 3.Land marketplace." and "Purchase an NFT from a 3.Land listing." are different operations, and the opening sentence says so in 8 words out of 59, with the other 51 identical across both and across all 275 ^[10]. Eight of fifty-nine is 13.6 percent ^[5]. That is where the post's rule of thumb comes from: a shared preamble on every tool costs more than it buys, and the distinguishing sentence should not be a seventh of the text ^[19]. The block was added deliberately, to help ^[11], and it arrives identically on all 275 ^[9].

The author's test does not need the corpus. Read your tool list as one block, the way a model receives it, with no README, no repo and no memory of what you meant, then ask which tool you would pick for a request that could plausibly go to two of them ^[18]. If the answer is that you cannot tell, the options are to rewrite for contrast instead of clarity ^[19] or to collapse near-identical tools into one ^[20]. Thirty is a population average ^[17]. A forty-tool server whose tools do genuinely different things to genuinely different objects may be fine; a twelve-tool server where four tools are variations on search fails ^[17].