{"slug": "i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same", "title": "I Wired 8 MCP Servers Into One Claude Agent. 3 Pairs Quietly Fought Over the Same Tool Name.", "summary": "An engineer who wired eight MCP servers into a single Claude agent discovered that three pairs of tools silently collided due to the protocol's lack of built-in namespace support. The collisions caused \"search\" to sometimes hit Brave and sometimes a local filesystem, \"create_issue\" to route issues to Linear instead of GitHub, and \"list_files\" to dump 31,000 tokens of S3 metadata into a session. The MCP 2026-03 spec provides no collision detection or warning, relying on a flat tool registry where the last server to register a name wins.", "body_md": "Eight MCP servers in one `claude_desktop_config.json`\n\n. 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.\n\nIt turns out MCP, as of the 2026-03 spec, has no built-in namespace for tool names. Two servers can register `list_files`\n\nand 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.\n\nThis 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.\n\nFor context, this is not a stunt setup. Each server earned its slot for a real task I run weekly.\n\n`brave-search`\n\n— web search for fact-checking`filesystem`\n\n— read/write inside an Obsidian vault`github`\n\n— issue and PR ops on my own repos`linear`\n\n— issue and project ops on a client repo`s3`\n\n— read access to a private logs bucket`freee`\n\n— tax/expense ops (Japanese accounting service)`slack`\n\n— read-only on two channels for catch-up summaries`postgres`\n\n— 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.\n\nWhen 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.\n\n**Collision 1: search.** Both\n\n`brave-search`\n\nand `filesystem`\n\nregistered a tool named `search`\n\n. 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\n\n`github`\n\nand `linear`\n\nregistered `create_issue`\n\n. Same name, same overall shape (title, body, labels), incompatible everything else (`linear`\n\nwants a `teamId`\n\n, `github`\n\nwants `owner`\n\nand `repo`\n\n). 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\n\n`filesystem`\n\nand `s3`\n\nregistered `list_files`\n\n. 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/`\n\n, 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/`\n\ndirectory has 12.None of these throw an error. The MCP client (Claude Desktop / Claude Code) sees a flat tool registry. Last write wins. Period.\n\nI went and re-read the [Model Context Protocol spec](https://modelcontextprotocol.io/specification) (2026-03-26 revision) to confirm I was not missing something. I was not. The `tools/list`\n\nresponse from a server returns tool names as flat strings. There is no `namespace`\n\nfield. There is no `server_id`\n\nqualifier. 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.\n\nThat 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`\n\n, `list`\n\n, `get`\n\n, `create`\n\n, `delete`\n\n. They are not safe by accident.\n\nThere is a [pending proposal (#287)](https://github.com/modelcontextprotocol/specification/issues) 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.\n\nThree lines in my agent config. Not pretty. Effective.\n\n```\n{\n  \"mcpServers\": {\n    \"brave-search\": { \"command\": \"...\", \"tool_prefix\": \"brave_\" },\n    \"filesystem\":   { \"command\": \"...\", \"tool_prefix\": \"fs_\" },\n    \"github\":       { \"command\": \"...\", \"tool_prefix\": \"gh_\" },\n    \"linear\":       { \"command\": \"...\", \"tool_prefix\": \"linear_\" },\n    \"s3\":           { \"command\": \"...\", \"tool_prefix\": \"s3_\" },\n    \"freee\":        { \"command\": \"...\", \"tool_prefix\": \"freee_\" },\n    \"slack\":        { \"command\": \"...\", \"tool_prefix\": \"slack_\" },\n    \"postgres\":     { \"command\": \"...\", \"tool_prefix\": \"pg_\" }\n  }\n}\n```\n\n`tool_prefix`\n\nis 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}`\n\nbefore registering. Now `search`\n\nbecomes `brave_search`\n\nand `fs_search`\n\n, `create_issue`\n\nbecomes `gh_create_issue`\n\nand `linear_create_issue`\n\n, and the registry has 87 unique names.\n\nIf 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.\n\nI added two checks to my agent boot:\n\n**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.\n\n**Tool-call attribution log.** Every tool call gets logged with `{server_name, tool_name, args_summary}`\n\n. When something feels wrong, I can grep one day of transcripts and see whether `search`\n\ncalls 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.\n\nThe attribution log lives in `~/.claude/agent-tool-calls.jsonl`\n\nfor 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.\n\nI do not run any MCP server with a generic tool name like `search`\n\nor `list`\n\nun-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.\n\nI 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.\n\nThe 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.\n\nThe 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](https://kenimoto.dev/books/mcp-security-practice?utm_source=devto&utm_medium=article&utm_campaign=8-mcp-tool-collision). Chapter 6 is the auth and tool-registration audit playbook I run on every new server now.", "url": "https://wpnews.pro/news/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same", "canonical_source": "https://dev.to/kenimo49/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same-tool-name-46ff", "published_at": "2026-05-27 11:00:00+00:00", "updated_at": "2026-05-27 11:10:25.886696+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "large-language-models", "ai-products"], "entities": ["Claude", "Brave", "GitHub", "Linear", "Obsidian", "Slack", "Postgres", "MCP"], "alternates": {"html": "https://wpnews.pro/news/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same", "markdown": "https://wpnews.pro/news/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same.md", "text": "https://wpnews.pro/news/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same.txt", "jsonld": "https://wpnews.pro/news/i-wired-8-mcp-servers-into-one-claude-agent-3-pairs-quietly-fought-over-the-same.jsonld"}}