Describe the security and correctness risks when two MCP servers expose a tool with the same name. What must a well designed host do to prevent the failure?
When two MCP servers expose the same tool name, the host must namespace each name by server. Otherwise the model calls the wrong tool, or a malicious server shadows a trusted one.
Imagine two coworkers both named Alex. You ask 'Alex, send the report' and have no idea which one acts. Worse, a stranger could rename themselves Alex to intercept your request. MCP tools have the same problem: two servers can both offer a tool called search, and the model only sees the bare name. The fix is to give everyone a full name tagged by where they work, like github-Alex and jira-Alex. The host adds this server prefix to every tool before showing the list to the model. Now each name is unique, the model always picks the right one, and no stranger can impersonate a trusted tool just by copying its name.
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.
Modern MCP hosts rarely connect to just one server. Claude Desktop, Claude Code, Cursor, and Zed all fan out to several servers at once: a filesystem server, a GitHub server, a Jira server, a Postgres server. Each server is written independently, by different authors, and each names its own tools. Nothing in the protocol coordinates those names across servers, and nothing in the spec promises that a tool name is globally unique.
That sets up a collision. Two servers can both expose a tool called search, or read, or create. The host merges every server's tools into one flat catalog and hands that catalog to the model. The model sees names, not servers, unless the host does something about it. The naming question looks trivial until you realize the model's entire routing decision rides on the string it is given.
This deep dive works through why collisions are inevitable, the two distinct failure modes they cause (one a quiet correctness bug, one an active security exploit), and why the only correct place to fix it is the host. We finish with how disambiguation has to compose with the rest of the MCP trust model, because prefixing alone does not make a multi-server host safe.
Why collisions are inevitable
Each MCP server owns its own tool namespace. The author of a GitHub server picks search because, inside that server, it is unambiguous. The author of a Jira server independently picks search for the same reason. Neither author knows the other exists, and the protocol gives them no shared registry to coordinate against.
The host is where the two worlds meet. When a host connects to multiple servers, it calls tools/list on each, then concatenates the results into a single catalog for the model. At that moment, two perfectly reasonable local names become one global clash.
This is not an edge case you can wish away. Common verbs like search, read, list, create, and query recur across almost every server. The vocabulary of useful tools is small and convergent, so independent authors land on the same words constantly. As soon as a host supports more than one server, overlapping names are the expected state, not the exception. The host has to plan for it.
The birthday-problem intuition makes this concrete. As the number of installed servers grows and each contributes a handful of generically named tools, the probability that some pair collides climbs fast toward certainty. A user running five or six servers in a single session is no longer rare. Designing as if collisions are improbable is designing for a world that does not exist.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | No disambiguation | Host server-prefixing |
|---|---|---|
| Tool name seen by model | Bare search, duplicated | github:search, jira:search |
| Correctness | Silent wrong-tool dispatch | Deterministic, unique routing |
| Shadowing attack | Malicious server can collide | Prefix is host-owned, not spoofable |
| User visibility | Which server ran is hidden | Attribution can be shown in UI |
| Who owns the namespace | Each server, independently | The host, the aggregation point |
Real products, models, and research that use this idea.
- Claude Code and Claude Desktop namespace tools by their configured server name, so two servers each exposing search stay distinct in the model context.
- Cursor and Zed both aggregate multiple MCP servers and must disambiguate overlapping tool names like search or read at the host layer.
What an interviewer would ask next. Try answering before peeking at the approach.
QServer prefixing gives unique names, but does it change how the model reasons about which tool to pick?
Prefixes remove ambiguity but add tokens and can leak server identity into reasoning; you still need clear, distinct descriptions so the model selects by capability, not by guessing the prefix.
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.
Treating a name clash as a cosmetic UX nit. It is both a silent wrong-tool bug and a shadowing attack vector when one server is hostile.
60 second bullets to scan on the way to the call.
Why multi-server hosts make name collisions inevitable
The silent wrong-tool correctness failure mode
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.