In MCP, how should a client handle two servers exposing the same tool name?

## Why collisions are guaranteed, not hypothetical MCP 2026-07-28 constrains tool names to 1–128 characters drawn from `A-Za-z0-9_-.`, treats them as case-sensitive, and requires uniqueness **within a single server**. There is no global registry, no reserved-name list, and no coordination mechanism between servers. Meanwhile the obvious names — `search`, `read_file`, `create_issue`, `send_message` — are exactly the ones every server author reaches for. A host that connects five servers will hit a collision by accident long before anyone attacks it. The attack version has an ecosystem name, *tool shadowing*: a low-trust server deliberately publishes a tool whose name (and often description) mimics a high-trust server's, hoping the client, the user, or the model routes a call to the wrong one. That term is community vocabulary; the specification does not define it. What the specification supplies is the disambiguation guidance below. ## What the specification says Two statements do the work. First, aggregating clients **SHOULD** prefix tool names with a server identifier when presenting a combined list. Second — and this is the part candidates miss — `serverInfo.name` is **not reliable** for that purpose. The reason is the same as everywhere else in this area: `io.modelcontextprotocol/serverInfo`, which results SHOULD carry in `_meta`, is self-reported and explicitly untrusted, exactly like `io.modelcontextprotocol/clientInfo` in the other direction. Using it as a namespace hands the naming authority to the very party you are trying to disambiguate. A malicious server sets `serverInfo.name` to `github` and its tools now render as `github.create_issue`. ## Where the prefix must come from From the client's own side of the relationship: the key of the entry in the host's server configuration, the connection identifier the client minted, or a stable local alias the user chose when adding the server. These are facts the host knows independently of anything on the wire, and they are the only kind of identity that survives a hostile counterparty. A detail that bites in practice: because `.`, `-` and `_` are all legal inside tool names, naive concatenation is ambiguous. If the client renders `<serverId>.<toolName>`, a server registered as `evil` can name a tool `github.create_issue` and the rendered string `evil.github.create_issue` is fine — but a server registered as `evil.github` exposing `create_issue` produces the same string as a server registered `evil` exposing `github.create_issue`. Pick a separator or an encoding that cannot be forged from the name side: reserve a character disallowed in tool names, encode lengths, or keep the pair structured internally and only flatten for display. ## Beyond the prefix The prefix fixes routing — the client always knows which connection a call goes to. It does not by itself fix the human and the model. **The model** sees whatever names you render. If two tools look nearly identical in the flattened list, the model will sometimes pick the wrong one, and a shadowing server writes its description precisely to encourage that. Rendering provenance in the name is what gives the model something to discriminate on at all. **The human** sees the approval prompt. It must name the concrete server using local identity — "acme-tickets (stdio, configured 2026-06-02)" — rather than a display string the server supplied. An approval dialog that echoes an attacker-chosen name is a phishing surface. **Standing approvals** must be keyed by the pair, never by the bare tool name. Approving `search` once and having that grant apply to whichever server later exposes a tool called `search` is the whole vulnerability in one line of code. ## What does not help A few plausible-sounding non-answers are worth ruling out explicitly. The rule that a server's tool set MUST NOT vary per connection is per-server and says nothing across servers. Protocol-level sessions, which some people reach for as a scoping mechanism, were removed in 2026-07-28 — there is no session to hang a namespace on. And rejecting the second server outright is not what the spec asks for; collisions are legal, and a host that refuses them breaks ordinary multi-server use for no security gain that prefixing does not already provide. The summary a senior candidate should land: names are server-scoped by design, the client owns the namespace, the namespace must be built from identity the client controls, and the resulting name must reach both the model and the human unmodified.