When a host connects to three MCP servers simultaneously and two of them expose a tool called `search`, how does the host typically handle the collision? Is this enforced by the protocol?
MCP only guarantees unique tool names within one server, so the host must namespace tools across servers, usually by prefixing names with the server id.
Imagine two coworkers both named Alex. Inside their own teams, there is only one Alex, so first names work fine. But the moment they join one big meeting, saying 'Alex' is ambiguous, and the chair has to say 'Alex from Sales' or 'Alex from Support'. MCP is the same. Each server promises its own tool names are unique, but it knows nothing about the other servers in the room. The host is the meeting chair. When it pulls tools from several servers at once, it relabels them with the server name, like `github:search` and `web:search`, before handing the list to the model. The protocol never forces this, so it is the host's judgment call.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Multi-server MCP is where a lot of candidates discover the protocol is thinner than they assumed. A host can connect to a filesystem server, a GitHub server, and a web-search server at the same time. Each one answers tools/list with its own catalog. The natural question an interviewer probes is, what happens when two of those catalogs contain a tool with the same name?
The instinct is to say MCP must prevent this. It does not. The spec scopes name uniqueness to a single server's response and stays deliberately silent about collisions between servers. That silence is not an oversight. It is a layering decision that pushes aggregation, and therefore disambiguation, up to the host.
This deep dive unpacks exactly what the protocol guarantees, why collisions are the host's problem, the server-qualified prefixing pattern that solves it, and the shadowing risk that turns a naming nit into a security boundary.
What the protocol actually guarantees
The MCP spec defines a server as exposing a list of tools through the tools/list method. Within that one response, names must be unique. A server cannot advertise two tools both called search, and a host can reasonably reject such a catalog.
That is the whole guarantee. The protocol models each server connection as an independent namespace. It has no concept of a global registry spanning every server a host happens to connect to. A web server author writing a search tool has no idea a GitHub server author also chose search, and the spec never asks them to coordinate.
The consequence is direct. As soon as a host fans out to more than one server, the union of their catalogs can contain duplicate names. Nothing in the wire protocol detects or resolves that. The collision is well-formed at the protocol layer: each server is internally valid. The clash only exists in the host's merged view.
It helps to be precise about why the spec is scoped this way. MCP servers are authored independently, shipped by different vendors, and connected in combinations the authors never anticipated. Demanding global uniqueness would force a central naming authority or a coordination handshake between servers that have no channel to talk to each other. The protocol instead keeps each server simple and self-contained, and accepts that the merged view is somebody else's responsibility. That somebody is always the host.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | Within one server | Across multiple servers |
|---|---|---|
| Name uniqueness | Guaranteed by spec | Not guaranteed, host's problem |
| Who disambiguates | Server author | The host application |
| Typical mechanism | Plain tool names | Server-prefixed names plus allowlists |
| Failure if ignored | Schema validation error | Silent shadowing or security bypass |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code aggregate tools from every server in their config and namespace them so two servers exposing `search` stay distinct.
- Cursor lets users enable or disable individual MCP servers, which sidesteps collisions by trimming the active tool set the model sees.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you design a host's tool-routing layer so a malicious server cannot shadow a trusted server's tool?
Pin trust per server, namespace before merge, never allow last write to win, and validate that a call's resolved server matches the prefix the model used.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Assuming the MCP spec guarantees globally unique tool names. It only guarantees uniqueness inside one server, so collisions across servers are the host's problem to solve.
60 second bullets to scan on the way to the call.
What the MCP spec guarantees about tool name uniqueness
Why cross-server collisions are not a protocol violation
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.