Measurement
122 servers have a tool called search
We read the tool list of every MCP server that would answer us, 97,472 tools in all. The most common names are not distinctive at all: 122 different publishers ship a tool called search, and 62 ship one called fetch. An agent choosing between them cannot use the name, because the name is the same.
The collision
We connect to every MCP server we index and read the tool list it returns. Not the README, not the registry description: the server's own tools/list response. That is 97,472 tools across 5,079 servers that answered.
Sorted by how many distinct publishers ship a tool of that exact name:
| Tool name | Publishers shipping it |
|---|---|
| search | 122 |
| fetch | 62 |
| get_product | 52 |
| search_products | 52 |
| list_categories | 51 |
| get_pricing | 39 |
| get_article | 35 |
| list_projects | 30 |
Nobody did anything wrong here. Each publisher named their tool the obvious thing, without seeing anybody else's. This is simply what an uncoordinated namespace looks like once it is large enough, and it will get worse rather than better.
Why this is a discovery problem, not a naming problem
The instinct is to want namespacing, and the protocol already effectively has it: tools are scoped to the server you connected to, so there is no collision at call time. Your agent is talking to one server and its search is unambiguous.
The collision happens one step earlier, at the moment nobody has connected yet. An agent that needs to search something has to choose a server first. If 122 candidates offer a tool with the same name, the name has contributed nothing to that choice.
Names disambiguate at call time and are useless at discovery time. Discovery has to run on everything except the name.
What actually separates them
Four signals, in roughly increasing order of how much work they take to produce and how much they are worth.
1. The description the server returned
Not the marketing sentence. The string the server hands a client in tools/list, which is what the model will actually read. A large share of them describe the mechanism rather than the job: sends via the configured channel, queries the backing store, returns results. Those are accurate and they do not tell a chooser anything.
2. The parameter names
Consistently the most underrated signal in the whole stack. A tool named send with a description of sends a message tells you almost nothing. The same tool with parameters to_phone_number and message_body tells you it is SMS, without reading a word of prose.
Parameter names are written by engineers for engineers, which makes them unusually honest. They are rarely marketing. It is why we put them into the searchable document rather than indexing names and descriptions alone, and the measured effect on retrieval was positive.
3. What the publisher says the resource is for
The representativeQueries field of an ARD manifest is the one place a publisher states, in plain language, the requests their resource answers well. It is the only statement of intent in the whole chain that is not our inference, and it is the single highest leverage thing an author can write.
Most are wasted. The common failure is a category label: document processing, payments infrastructure, AI-powered search. Those match everything and therefore nothing. What works is a sentence with a verb that somebody would actually type: extract line items from a scanned invoice.
4. Which publisher it is
Whether the manifest asserting a resource was served by the domain it names is checkable, and it is the difference between a claim and a credential. It does not tell you a tool is good. It tells you who is responsible for it, which is often the deciding factor when two candidates look equally plausible.
What this means if you publish a tool
- Assume your tool name is taken. If it is search, fetch or get_<noun>, dozens of others have it. Do not rename it, that is not the fix. Make everything around it carry the meaning.
- Write the description for a stranger. The reader is a model that has never seen your product and will not visit your site. Say what job it does, not how it is implemented.
- Name parameters like they are documentation, because at discovery time they are. to_phone_number beats recipient beats arg1.
- Write representativeQueries as sentences. Three to eight, each with a verb, each describing something you are genuinely one of the better answers to.
What it means if you build a client
Do not match on tool names. It feels like the precise thing to do and it is the least informative field available at the moment you need to choose. Rank on the whole document: the description, the parameters, the publisher's stated queries, and the publisher itself.
And expect ties. When 122 candidates offer the same capability, the honest answer is often several, ranked, with the evidence attached, rather than one confident pick.
Method
Tool records come from live tools/list responses over streamable HTTP, one read-only introspection per server, no retries, no tool invoked. Counts are distinct publishers per exact tool name across 97,472 tools from 5,079 responding servers, as of 5 September 2026. Names are compared exactly, so search and search_docs are separate rows, which makes these figures a floor rather than a ceiling.
Use Neuronto from your agent
One call searches this index and every other public ARD registry. No key, no signup. Or install it as an MCP server and let the agent search from the interface it already speaks.
curl -s https://neuronto.com/search \
-H 'content-type: application/json' \
-d '{"query":{"text":"scrape a website"},"federation":"auto"}'
claude mcp add --transport http neuronto https://neuronto.com/mcp