The unqualified name is not enough. MCP tool calls identify a tool by name on a particular server connection. Once a host merges several servers into one catalog, it owns the mapping between the model-visible choice and the actual destination. If it flattens everything into a map keyed only by search, the last registered server may replace the first, or a human review may authorize the wrong destination. The exact behavior depends on the host implementation. The protocol does not make a global cross-server namespace safe by itself.

I would give each offered capability a stable host identity bound to the server connection, authenticated server identity where available, tool name and definition version. Display the destination and data that will be sent on the review screen. Authorize against that resolved capability and the current user's scope, then execute through the same binding. Audit both the model-visible alias and the resolved destination. Do not use a server-supplied display title as the security identity. A malicious server can choose a reassuring title or description. A tool's annotations are also untrusted unless the server is trusted, as the MCP specification warns.

Now press on the hard case: a server reconnects or its tool schema changes between approval and execution. Re-resolve and compare the bound identity and definition. Material changes to destination, arguments or capability need a fresh decision, not a silent fallback to another search. Test two same-name tools with incompatible schemas, a swapped registration order, a reconnect and a forged friendly title. The expected outcome is either the reviewed destination or a stopped call, never whichever entry won a map collision.

A tool catalog changes while an agent is running already asks what happens when a tool catalog changes during a run. Here the sharp edge is the identity of one capability across servers, even when each server's own list is stable. A name by itself is a useful label for a person. It is not a sufficient authorization key.