Spot the error in this multi-server MCP host configuration
Click any words you think contain an error. Click again to unmark.
Two servers expose a tool named the same; without server-qualified prefixes the model cannot pick the right one, and routing by first-responder is non-deterministic.
Imagine two coworkers in an open office both named Sam. You shout 'Sam, file this!' and whoever turns around first grabs the document. Sometimes the right Sam takes it, sometimes the wrong one files it in the wrong cabinet. The fix is to use full names, 'GitHub Sam' and 'Jira Sam'. In an MCP host, two servers each expose a tool called search. If the host hands both to the model under the bare name search, the model has no way to say which one it means. Worse, routing the call to whichever server answers first is a coin flip. The host should rename the tools with a server prefix before the model ever sees them, so every call names exactly one target.
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.
This is a multi-server MCP question disguised as a config review, and it is rated hard because two distinct bugs hide in three sentences. A host connects to a GitHub server and a Jira server. Both expose a tool named search. The host passes everything to the model under bare names, then routes a search call to whichever server answers first.
The instinct is to flag one thing. Strong candidates flag two. The first defect is a naming collision: the model has no way to address one server when two tools share a bare name. The second defect is the chosen tie-breaker: first-responder routing is non-deterministic and, for side-effecting tools, unsafe. They are independent failures. Fixing only the routing leaves the model unable to express intent; fixing only the name leaves a host that still needs a deterministic dispatch rule. A complete answer addresses both and ties them to the same root cause: the host treated tool aggregation as a pass-through instead of a responsibility.
This deep dive separates the two failures, shows why the tool name is the only routing key the model controls, walks through where in the host pipeline the fix belongs, and then layers in the parts that separate a senior answer: clear descriptions and the shadowing attack surface that careless naming opens up.
The tool name is the only routing key the model controls
When a host fans out to several MCP servers, it calls tools/list on each, then merges the results into one catalog. That merged catalog is what the host renders into the model's prompt as tool definitions. From the model's point of view there are no servers, only a flat list of named tools. The host-to-server topology is invisible at the prompt layer by design, which is part of what makes MCP composable, but it also means the host alone is accountable for keeping that flat list unambiguous.
That flatness is the crux. The single piece of information the model emits to invoke something is the tool name. When it decides to call a tool, the wire payload is essentially { name: "search", arguments: {...} }. There is no server field. There is no connection handle. There is no out-of-band channel where the model could whisper which provider it meant. The name is the entire address.
So if two servers both contribute a tool literally named search, the address space has collapsed. The name search now resolves to two targets. The model can reason all it wants about wanting GitHub, but the only thing it can actually transmit is the ambiguous string. The host has thrown away the very information needed to route, before the model ever spoke.
This is why the bug is structural rather than a tuning problem. No amount of better prompting or a smarter model recovers a piece of addressing information that the protocol payload simply does not carry. The host collapsed two distinct capabilities onto one identifier, and identifiers are the contract.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Approach | How the model addresses a tool | Routing outcome |
|---|---|---|
| Bare colliding names | Emits search, which maps to two servers | Ambiguous, host must guess |
| First-responder routing | Emits search, host picks fastest server | Non-deterministic, can mutate wrong service |
| Server-qualified prefixes | Emits github:search, names one server | Deterministic, one unambiguous target |
| Prefixes plus clear descriptions | Names one server and picks by capability | Deterministic and correct tool chosen |
Real products, models, and research that use this idea.
- Claude Desktop and Claude Code both connect to multiple MCP servers at once and must disambiguate same-named tools before building the model prompt.
- Cursor and Zed aggregate tools from many MCP servers, where a GitHub server and a Jira server can each ship a generic search tool.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhere exactly in the host pipeline should the prefix be applied, and why not at dispatch time?
At catalog-assembly time before the prompt is built. The name is the routing key the model emits, so it must already be qualified when the model chooses, not patched after.
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.
Letting the host route a colliding tool call to whichever server responds first. That is non-deterministic and can mutate the wrong service silently.
60 second bullets to scan on the way to the call.
Why a bare colliding tool name leaves the model unable to address a server
Why first-responder routing is non-deterministic and unsafe
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.