A city permitting office connects two MCP servers to the same Claude assistant. The legacy building-permit system's server and the new fire-inspection system's server each expose a tool named get_status. Staff report that status lookups are returning results from the wrong system. What is the appropriate architectural fix?

A model selects a tool by name from a single flattened list assembled across every connected server. When two entries collide on get_status, the identifier stops identifying anything: whichever entry the client resolves to wins, and the model has no way to express which system it meant. The misrouted status lookups permitting staff are reporting are that ambiguity surfacing.

Namespacing removes the collision at the layer where it exists. Qualifying each tool with its server, giving building_permits.get_status and fire_inspections.get_status, makes the name itself carry the target so selection becomes unambiguous. Many MCP clients do this automatically, and Claude Code exposes MCP tools as mcp____. Distinct names also make audit logs readable, since an entry records which system was actually queried.

A system-prompt hint cannot resolve the collision, because the model still emits the one ambiguous name and the client still has to guess; disconnecting a server discards needed capability to work around a naming problem a rename solves; and merging the backends behind one view is a large integration project that puts two permitting domains with different access rules behind a single tool while leaving the naming defect untouched.

Exam caveat: unique names fix addressing rather than selection, since two clearly named status tools with vague descriptions will still be confused, so each description must say which system and which records it covers. Operational check: list the assistant's resolved tool names, confirm no duplicates remain, then run a known permit and a known inspection lookup and verify each reached the right backend in the server logs.