How should an MCP host distinguish tools with the same name?

A name is an address within a server

Combining MCP catalogs creates an identity problem before any malicious content is involved. Two tools called search can refer to public documentation and confidential account records. If the host merges them into one dictionary entry, whichever definition is processed last may replace the other.

The MCP tool specification explicitly bounds tool-name uniqueness to a server. Preserve that scope when introducing a global host catalog. A tool’s visible label can be convenient for a model without becoming the system’s authoritative routing key.

Keep discovery claims separate from bindings

Server discovery supplies implementation information and declared capabilities. Your host still needs an admitted binding that identifies which configured service it intended to contact.

Maintain three layers: the binding that selects the endpoint and authorization configuration; the original tool name used on that endpoint; and the catalog revision that records what the host offered. A host alias points to that tuple. Never reconstruct the destination by interpreting a model-produced string as a URL or package identifier.

Two search tools meet a thirty-two-character limit

Imagine a hypothetical engineering assistant aggregating documentation and customer-case servers. Both expose search, and both happen to report company-tools as their server name. A host adds prefixes and then truncates names to thirty-two characters for an internal adapter. Two previously distinct aliases collapse to the same value.

The catalog builder must reject that release before either definition reaches the model. It assigns locally controlled short bindings, docs-a and cases-b, and produces distinct aliases. Each alias resolves through a fixed record; changing catalog order no longer changes its destination.

The test should also reverse input order and insert an unrelated server. An alias that changes meaning under either operation is not stable enough for saved prompts, evaluations, or incident reconstruction.

Store the reverse mapping as the artifact

This hypothetical binding card illustrates host metadata. It is not an MCP request payload, and its identifiers belong to the local catalog service.

catalog_revision: catalog-42
logical_tool_id: knowledge-public-search
host_alias: docs_a_search
binding_id: docs-a
binding_revision: 3
original_tool_name: search
definition_revision: 12
definition_digest_ref: catalog-store/definitions/12
normalization_rule: catalog-json-v2
admission_decision: admission-118
eligibility_profile: public-docs-readers

Store the digest value and canonical definition in the referenced record. The short reference above avoids pretending that an illustrative hash establishes integrity. The catalog builder should demonstrate that exactly one active binding resolves each alias and that the original name survives the round trip.

Review changes to the definition independently

An endpoint may retain its name while changing descriptions, defaults, field constraints, or results. Keep the logical identity stable where the capability remains the same, but assign a new definition revision and inspect the difference.

A description edit can matter even when the JSON schema is unchanged because it changes the information offered at selection time. Test representative competing tools and confirm that the intended alias is chosen. This is an evaluation question; a digest merely tells you which text was evaluated.

Do not collapse two definitions because their schemas match. Input shape says little about corpus, freshness, units, downstream effects, or ownership. Those distinctions belong in the admitted contract.

Resolve execution through the selected snapshot

When a host constructs a decision using catalog revision 42, preserve that revision with its selected alias. At dispatch, resolve through an accepted binding and check whether that revision remains usable. A removed or suspended binding should yield an explicit unavailable result rather than falling through to another search tool.

This check does not require preserving every old executable endpoint forever. It requires an intentional policy for supported old definitions, retired definitions, and unresolved selections. Historical records can retain tombstones after execution is disabled.

Verify ambiguity before investigating intent

Test duplicate original names, duplicate reported server names, case changes, alias truncation, ordering changes, and removal followed by replacement. These deterministic checks should fail closed on ambiguity. Then evaluate whether descriptions and task context lead the model to the intended tool.

The distinct security problem of instruction-like tool content is covered by prompt-injection containment. The next operating problem is migrating hosts with stale catalogs.