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 notice...
For further actions, you may consider blocking this person and/or reporting abuse
Tool-name collisions are one of those boring problems that become serious once agents act automatically. Names need namespaces, ownership, and intent. Otherwise the model sees two plausible tools and the wrong one can still look semantically correct.
Yeah, intent is the part the prefix doesn't actually fix. The tool_prefix config killed the name clash, but it just turned one ambiguous "search" into two valid options. The model still has to know fs_search is the vault and brave_search is the web. If the descriptions are vague, you've basically moved the collision from the name to the reasoning step.
What helped more than the prefix was rewriting the descriptions to say where each tool acts, not just what it does. "Searches the local Obsidian vault" vs "Searches the public web." The prefix stops the silent overwrite, the description is what stops the wrong-but-plausible call.
Yes, exactly. Names solve routing only at the first layer. The model still needs semantic boundaries: local vs web, read-only vs mutating, private vs public. I think the best tool descriptions are almost permission labels, not marketing copy.
Awesome write-up, Ken! That create_issue glitch—where your private Postgres data accidentally went into a client’s Linear account—is a perfect example of the hidden security risks in MCP right now.
Using tool_prefix is a great temporary fix for a local setup. However, as soon as teams start sharing MCP servers or using them across a whole company, managing all those different files and prefixes by hand becomes a full-time job.
This exact mess is why I’ve been building vectoralix.com. We are creating a platform to host and manage MCP servers. It handles things like namespacing and server discovery automatically. That way, you don't have to waste time manually changing tool names or worrying about your system prompts getting way too long.
I'm really looking forward to your next post on MCP security—we definitely need more practical guides like this!
Thanks Eugene! Yeah, prefix-per-config is really just a personal-grade workaround. Once two people edit the same config, the manual side scales badly.
Curious how vectoralix handles collisions when two upstream servers ship the same tool name. Does one win, or do both stay exposed with disambiguated names?
Thank you for asking. Let me explain that in a few words:
Vectoralix isn't an aggregating MCP client, so there are no "upstream servers" whose tools get merged.
Each Vectoralix McpServer exposes only the tools explicitly bound to it via the mcp server tool pivot. A client hitting /mcp/{serverUid} sees that one server's tools, not a union across servers.
Basically responsibility on naming and tool description is on the user. More clear name of the tool will be - better experience user will have with his data and llm processing.
Got it, that makes sense. Single endpoint, single namespace, naming on the user is a clean model for that scope. The collision I wrote about really only bites once you flatten several servers into one agent, which sounds like a different layer from what Vectoralix targets. Thanks for walking through it, and good luck with the build.
This is gold. The silent collision problem is exactly the kind of issue you only discover after week 2 of running multi-server setups. We hit something similar in our multi-agent Hermes setup — two agents registering overlapping tool names and quietly clobbering each other.
Your routing table approach is clever but feels like a workaround for something the MCP spec should address. Did you consider prefixing tool names at the server level (e.g. github_list_files, fs_list_files) vs the client-side routing?
Yeah, that was my first instinct too. The catch: I don't own the GitHub or Postgres servers, so renaming their tools means forking and maintaining a patch forever. Client-side routing was the only layer I actually control. Agree the spec should handle namespacing, not me.
This seems even more worrying to me than a hard error! Having writes land on the wrong system is wild.
Namespacing feels like a smart way to wrangle our multi-tool setups. Love it!
Exactly. A hard error at least pages you. The create_issue one scared me most because nothing failed: the write went through fine, just into the wrong tenant. By the time you notice, the data's already sitting in someone else's project.