Twelve servers, one flat list

Lesson 3 of 5 in Tool Selection at Scale: Forty Tools, One Context.

MCP made tool catalogs composable, and composition is where large catalogs actually come from. Nobody writes forty tools; a host connects to nine servers that each export a handful, and the pile assembles itself. Which raises a question the protocol answers precisely — and not in the way people assume.

Read that carefully, because two different namespaces are in play and only one of them is protected. Server identity is verifiable through the registry. Tool names inside a server are whatever that server says they are — and when your host flattens nine servers into one array for the model, collisions are not a hypothetical. Two servers exporting search. Three exporting create_issue. Your client must pick a rule, and the rule leaks into the model’s prompt, because the prefixed name is what the model reads and reasons about.

Disambiguation strategies your host can adopt, and what each does to the model’s job
Strategy	What the model sees	Verdict
First server wins	`search` — with no hint that a second `search` was silently dropped	Avoid. The dropped tool becomes a ghost: present in the catalog, unreachable, and invisible in any audit. Connection order becomes load-bearing configuration
Server prefix	`github__search`, `confluence__search`	The default worth adopting. Collisions become impossible, provenance becomes readable in the trace, and the prefix is a genuine routing signal — the model learns which system it is talking to
Prefix only on collision	`search` and `confluence__search`	Tempting, and unstable: adding a server silently renames a tool the model was already using. Tool names are part of your prompt surface — treat a rename as a change that needs testing
Curated aliases	`search_code`, `search_docs` — names you chose, mapped to servers in config	Best routing quality, highest maintenance. Worth it for the ten tools that carry your core workflows; not worth it for the long tail

Sprawl multiplies your prompt-injection surface, one server at a time

Every connected server contributes text that lands in your model’s context on every call: tool names, descriptions, parameter descriptions. That text is instructions the model reads. So each new server is a new party with write access to your prompt — the mechanism behind tool-description poisoning, and one the model cannot distinguish from instructions you wrote.

Two consequences specific to scale. First, descriptions can change between calls — the rug pull: a server that was benign at install time serves different text next week. Hash the tool list you accepted and diff it on reconnect; alert on drift rather than trusting install-time review forever. Second, a retriever makes this worse in a subtle way: a poisoned description written to match many queries gets itself retrieved for everything, so a hostile server can buy prominence on your menu. Score anomalies — one tool winning retrieval across unrelated request types — are worth an alert.

The structural answer is a single choke point. A tool gateway that aggregates every server, applies the prefix rule, enforces the allowlist, logs the description hash, and records which server served every call gives you one place to answer what could the model see, and who supplied it? Without it, that answer lives in nine configs and one person’s memory.

Provenance is the other half. When create_issue fires, three questions should be answerable from the trace alone: which server executed it, which credential it used, and what description was in context when the model chose it. The first two are ordinary span attributes. The third is the one teams omit and later wish they had, because it is the only way to reconstruct why a past run made a choice that today’s catalog would not produce.

Key terms: namespace, tool gateway, tool-description poisoning, rug pull, tool sprawl, provenance

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.