MCP Tool Name Collisions: What Happens When Two Servers Share a Tool Name

Connect two MCP servers that each define a tool called search, and you’ve created a naming collision the Model Context Protocol itself has no required answer for. What happens next depends entirely on whoever is holding the merged tool list — your AI client, or a gateway in front of it — because the spec says how a single server should name its own tools, not how anything downstream should resolve two servers claiming the same name. Here’s what the collision actually looks like, why it’s a different problem than the “shadowing” attacks you may have read about, and how a gateway closes it by construction instead of by detection.

How common this actually is

It’s more common than the search example suggests, because generic verbs are exactly the names tool authors reach for by default: search, get, list, create, update, delete. Connect a handful of servers from gate’s server directory — a CRM, a ticketing tool, a docs search server — and the odds that at least two of them expose a tool literally named search or list climb fast. Nobody is doing anything wrong here. Two tool authors who never talked to each other independently reached for the obvious word, which is exactly how name collisions happen in every namespacing problem, not just this one.

What actually happens when it collides

Nothing in the protocol forces a particular outcome, so it’s worth being honest about the range of things a client could do when two identically-named tools show up in the same merged tool list: keep only one and silently drop the other, let the model call whichever one happened to survive the merge with no obvious sign of which server is actually handling it, or — worse, for anything with real side effects — have the model intend a call to one server’s delete tool and have it land on a different server’s tool that just happens to share the name. Which of these a given AI client actually does is client-specific, and this isn’t a claim we can verify across every client on the market. The honest answer is: check, don’t assume, especially before you connect a server with a destructive tool alongside one you already trust.

Why this isn’t the same as tool shadowing

It’s worth separating this from tool shadowing, because the two get confused for good reason — both involve two servers interacting in a way a single-server review would miss. Shadowing is when one server’s tool description contains text instructing the model to behave differently toward a tool on another server; the tools themselves stay perfectly distinct, it’s the model’s behavior that gets hijacked, and it requires deliberately hostile text. A name collision needs no hostile text at all. Two completely well-behaved servers can clash just because their authors independently picked the same obvious verb. One is a security problem; the other is a plumbing problem. But a plumbing problem that produces ambiguous behavior around a destructive tool is still worth treating seriously.

How a gateway avoids it instead of detecting it

The fix that actually works isn’t smarter conflict detection at merge time — it’s not having a shared namespace to collide in. Prefix every tool with the server it came from before it ever reaches the client, and two tools named search simply become two different names. That’s the approach gate takes: every tool a connected client sees is exposed as <server>__<tool>, so a search tool on one connection and a search tool on another show up as two distinct, addressable names instead of one contested one. Server names get the same treatment — connect two servers that would otherwise share a name inside one gateway and the second one picks up a numeric suffix automatically, so the uniqueness holds all the way up the chain. There’s no “collision resolved” branch running anywhere, because the merge that would need it never happens.

It’s worth being precise about what this does and doesn’t cover. It solves collisions between servers. It doesn’t do anything about a single server returning two tools with the literal same name in its own tool list — that’s a bug in that server, not something a gateway can namespace its way out of, and the fix there is on the server author’s side.

What to check if you’re not using a gateway

• List every tool name across every server you’ve connected directly to a client, and scan for exact duplicates. Most clients will show you the merged list somewhere in settings, even if they don’t call attention to a clash.
• Pay the most attention to duplicates among consequential tools — anything that writes, deletes, or sends — before duplicates among read-only ones. Two colliding search tools are an annoyance; two colliding send_message tools are a real risk.
• If a client doesn’t tell you which server a tool call actually landed on, that alone is worth flagging before you rely on it for anything with side effects.
• Prefer connecting fewer, more deliberately chosen servers at a time rather than everything available — the same curation argument from how many tools an MCP server should expose applies to how many servers you stack into one session, and it shrinks the collision surface along with everything else it helps with.

The bottom line

Two MCP servers sharing a tool name isn’t an edge case — it’s what you get the moment you connect more than a couple of servers with ordinary, generic tool names, and the protocol leaves the outcome entirely up to whatever sits between the servers and the model. That can mean a silently dropped tool, an ambiguous call, or worse, depending on the client. The reliable fix isn’t catching the collision after it happens; it’s namespacing tool names by server before a collision is even possible, which is what a gateway sitting in front of every connection can do by default.