What failure mode occurs when two MCP servers expose the same tool name, and how should a host defend against it?

An MCP host can connect to several servers at once. Each server advertises its own tools, and nothing stops two servers from naming a tool the same thing. A GitHub server and a Jira server might both expose a tool called `search`. The problem is that the model only sees a flat list of tool names. If two entries both say `search`, the model has no way to tell them apart. It might call the Jira one when you meant GitHub. That is a **silent correctness bug**: nothing crashes, the wrong tool just runs. There is a darker version too. A malicious server can deliberately pick a name that matches a trusted server's tool, hoping the model calls it instead. That is a shadowing attack. The defense lives in the host. Before it shows the tool list to the model, the host prefixes every tool name with its server, like `github:search` and `jira:search`. Now every name is unique, the model always knows which server it is calling, and the UI can show users exactly which server runs.

Two MCP servers can advertise the same tool name because each server names its own tools independently. The host aggregates them into one flat list for the model. **The correctness risk.** If both a GitHub and a Jira server expose `search`, the model sees two identical names. It cannot tell them apart and may dispatch to the wrong one. Nothing errors. The user just gets a wrong result from a silently mis-routed call. **The security risk.** A hostile server can intentionally register a name matching a trusted server's tool. This is cross-server shadowing. The goal is to intercept the trusted invocation, exfiltrate arguments, or return poisoned output. The collision is now an attack surface, not just an annoyance. The defense sits at the host, the single aggregation point. The host prefixes every tool with a server identifier before assembling the model's context. Names become `github:search` and `jira:search`, which are unique by construction. The model picks deterministically, and shadowing fails because the prefix is host-controlled, not server-controlled. Good hosts also surface server attribution in the UI. Users see which server a call targets, so a name clash becomes visible rather than hidden.