Eight MCP servers in one claude_desktop_config.json
. No error on boot. No warning on tool registration. Six days of using the agent before I noticed that "search" was sometimes hitting Brave and sometimes hitting my local filesystem, and "create_issue" had silently routed every issue I created that week into Linear when I thought I was filing them on GitHub.
It turns out MCP, as of the 2026-03 spec, has no built-in namespace for tool names. Two servers can register list_files
and the client (Claude in my case) will use whatever map it built last. There is no collision detection. There is no warning. There is a registry that quietly overwrites.
This post is what I found when I sat down and audited the 8-server registration on day six, what each silent collision actually did, and the three-line config change that has kept me at zero collisions for six weeks since.
For context, this is not a stunt setup. Each server earned its slot for a real task I run weekly.
brave-search
— web search for fact-checkingfilesystem
— read/write inside an Obsidian vaultgithub
— issue and PR ops on my own reposlinear
— issue and project ops on a client repos3
— read access to a private logs bucketfreee
— tax/expense ops (Japanese accounting service)slack
— read-only on two channels for catch-up summariespostgres
— read-only on a personal analytics DBEight servers, totalling 87 tools when Claude finished registering them. Around 4,400 tokens of tool descriptions in the system prompt, which is its own problem (separate post). The thing I want to talk about is the names.
When I dumped the registered tool list and grouped by name, three pairs had collided. Two of them I could have predicted in retrospect. The third I would not have, and it is the one that scared me.
Collision 1: search. Both
brave-search
and filesystem
registered a tool named search
. The Brave one takes a query and returns web results. The filesystem one takes a query and greps the Obsidian vault. They have completely different argument schemas. Claude was choosing based on which definition got loaded last on boot, which in turn depended on file order in the config (alphabetical, then filesystem won). When I asked "search for the latest Anthropic safety paper," Claude ran a regex over my Obsidian vault and confidently told me there was no result. That was the bug that started the audit.Collision 2: create_issue. Both
github
and linear
registered create_issue
. Same name, same overall shape (title, body, labels), incompatible everything else (linear
wants a teamId
, github
wants owner
and repo
). When I asked Claude to "open an issue about the asyncpg regression," it called the second-loaded one, which was Linear. The issue went into a client project where it did not belong, with a body that mentioned my private Postgres schema. I closed it quickly. The fact that I had to is the point.Collision 3: list_files. Both
filesystem
and s3
registered list_files
. When I asked Claude to "list the files in the inbox folder," it ran the s3 version, listed every object in the bucket prefix inbox/
, and stuffed about 31,000 tokens of file metadata into the context. The session was effectively burned. I had to start a new one. The bucket has roughly 40k objects in it. The local inbox/
directory has 12.None of these throw an error. The MCP client (Claude Desktop / Claude Code) sees a flat tool registry. Last write wins. Period.
I went and re-read the Model Context Protocol spec (2026-03-26 revision) to confirm I was not missing something. I was not. The tools/list
response from a server returns tool names as flat strings. There is no namespace
field. There is no server_id
qualifier. The client is expected to flatten the tool lists from all servers into a single map. The spec does not say what to do on collision because, in the spec's mental model, a collision is a configuration problem.
That is technically correct and operationally insufficient. Anyone wiring more than two MCP servers will hit a collision eventually because the names that show up are exactly the names you would pick yourself: search
, list
, get
, create
, delete
. They are not safe by accident.
There is a pending proposal (#287) to add namespace prefixes server-side, dated around early 2026, but as of writing it has not landed and the client implementations have not picked it up. So this is an "until further notice" problem.
Three lines in my agent config. Not pretty. Effective.
{
"mcpServers": {
"brave-search": { "command": "...", "tool_prefix": "brave_" },
"filesystem": { "command": "...", "tool_prefix": "fs_" },
"github": { "command": "...", "tool_prefix": "gh_" },
"linear": { "command": "...", "tool_prefix": "linear_" },
"s3": { "command": "...", "tool_prefix": "s3_" },
"freee": { "command": "...", "tool_prefix": "freee_" },
"slack": { "command": "...", "tool_prefix": "slack_" },
"postgres": { "command": "...", "tool_prefix": "pg_" }
}
}
tool_prefix
is a client-side feature in the build of Claude Code I am running (added in the 2026-04 release; check your version). It rewrites every tool name from a server to {prefix}{tool_name}
before registering. Now search
becomes brave_search
and fs_search
, create_issue
becomes gh_create_issue
and linear_create_issue
, and the registry has 87 unique names.
If your client does not have this feature, the same thing works at the server side: fork the server, prefix the names at the source. Uglier, same result.
I added two checks to my agent boot:
Collision scan. On startup, after all servers register, walk the tool list and assert no duplicates. Fail the boot if a duplicate exists. Three lines of code. It would have caught my problem on day one.
Tool-call attribution log. Every tool call gets logged with {server_name, tool_name, args_summary}
. When something feels wrong, I can grep one day of transcripts and see whether search
calls went to Brave or filesystem. This is also what I used to measure the 22% wrong-server rate before the prefix change. Without attribution logging, you cannot know whether you have this problem.
The attribution log lives in ~/.claude/agent-tool-calls.jsonl
for me. Six weeks of it is about 14 MB and has caught one other subtle bug (a freee server returning data for the wrong fiscal year) that had nothing to do with name collisions. The investment paid for itself twice in six weeks.
I do not run any MCP server with a generic tool name like search
or list
un-prefixed, ever, even if it is the only server registered. The cost of prefixing is around 4 tokens per tool in the description. The cost of a silent collision when you add a second server six months later is one production-shaped incident.
I also do not trust client implementations to add collision warnings on my behalf. The MCP client market is moving fast. Today's "the client warns you on duplicate" feature is tomorrow's "we removed that warning because it was too noisy in this other workflow." The boot-time assertion lives in my repo. It will outlast any specific client.
The lesson, if there is one, is the same as it always is with protocols that started as Just Wire Two Things Together: as soon as you have eight of anything, the assumptions the protocol made when there were two are the things that quietly bite.
The longer version of this story (the OWASP MCP Top 10 in production, the file-upload workaround chain, the 55k-token system-prompt diet I am running on the same 8-server config) is in Practical MCP Security. Chapter 6 is the auth and tool-registration audit playbook I run on every new server now.