Quick answer: When a host connects several MCP servers, generic tool names such as search, get, or read can collide across servers. Give each tool a stable prefix tied to its server or domain, like github_search or drive_read_file, so the name carries its own namespace and the model routes the call correctly. Prefixing is a convention the server or host enforces; the protocol does not guarantee unique names across servers.
Why names collide
Each server describes its tools with a name and a short description, and servers built independently tend to pick the same plain verbs. A document server, a ticket server, and a repository server can all expose search, and a storage server plus a database server can both offer read. When those tools sit in one host, the model sees duplicate names, and a call that looks unambiguous in isolation can be routed to the wrong server. The input schema may even differ between the two, so the same name accepts different arguments depending on where it lands.
Prefix as a namespace
The direct fix is to make the name include its origin. A server can name its tools with a product or domain prefix from the start, or a host can register each server's tools under a namespace and rewrite the name the model sees. Either way, the prefix should be stable, readable, and unique to one server; two servers sharing a prefix recreate the same problem one level up. The description still matters because the prefix handles routing, not the choice between two tools that do similar work.
Naming patterns
| Pattern | Example | Notes |
|---|---|---|
| Bare name | search |
Collides across servers |
| Server prefix | github_search |
Clear origin, set in the server |
| Host namespace | linear__search |
Added by the host, host-dependent |
| Prefixed plus description |
drive_read_file plus detail |
Best for close-but-different tools |
Server-side or host-level
The two enforcement points have different trade-offs. Setting the prefix in the server means the name is correct everywhere it is used, including any other host that connects later, and it does not depend on a host feature. The cost is that the server author has to choose and maintain the naming scheme. Relying on a host namespace keeps each server's names short and centralizes the mapping in one place, but the rewritten names are only as good as that host, and a different host may present the same tools without any namespace. If you do not control every host that will connect, prefer the server-side prefix so the origin travels with the tool rather than being added later.
Honest limits
The protocol sets no required namespace and does not promise that a host will add one, so behavior varies across hosts and some may surface bare names unchanged. A prefix removes exact-name collisions but not semantic overlap: two differently named tools can still do nearly the same job, and the model can pick the wrong one based on description. Renaming a tool also breaks saved prompts and agent configs that reference the old name, so the change needs a migration window rather than a hard swap. Before relying on any scheme, inspect the names the host actually registers; Powerduck lets you send a real request and review the exact tool names and descriptions in play rather than assuming the prefix took effect.
Frequently asked questions
Why not keep short names and let the host sort it out? Not every host namespaces tools, and duplicate names can be routed to the wrong server. Baking the origin into the name works regardless of host behavior.
Does the protocol enforce unique names? No. Each server names its own tools, and cross-server uniqueness is a convention, not a guarantee.
Does prefixing stop the model from choosing the wrong tool? It stops exact collisions, but two distinct tools with overlapping purposes still require clear descriptions.
What happens to existing references after a rename? Saved prompts and configs using the old name fail until they are updated, so keep the old name working during a migration window.
The bottom line
Treat the tool name as a namespace: prefix it with a stable, server-specific term, avoid generic bare verbs, and keep descriptions precise for tools that overlap. For more on operating these servers, see the MCP server guide hub.
Top comments (0)