Short answer: Prefixing tools with a clear, unique namespace (often the service or server name) is a good practice for clarity and collision avoidance, but it isn’t required by the MCP spec. If tools from multiple servers may coexist, using a prefix or consistent namespace helps both humans and models pick the right tool.
- The MCP spec and docs describe tools as server-exposed functions but do not mandate a prefix; effectiveness hinges more on clear names and detailed descriptions than on a specific naming style.[1][2]
- Practitioners highlight ambiguity problems with generic tool names and propose namespacing (e.g., a consistent prefix) to ensure uniqueness across servers and clearer intent mapping by LLMs.[3][4]
- Several best-practice guides recommend sticking to tokenization-friendly, consistent formats (prefer snake_case; avoid spaces, dots, brackets), which improves discoverability and tool-calling reliability across clients and models.[5]
- Community guidance on naming patterns focuses more on server/package names including “mcp,” while tool names themselves are recommended to be snake_case; namespacing for tools is suggested as a practical convention when collisions are possible.[6]
-
When to prefix:
- Multiple MCP servers in one host or client environment, where tool name collisions are possible or likely.[4][3]
- Tools with generic verbs (e.g., get_file, search) that might be confused across services; a service prefix reduces ambiguity (e.g., drive_get_file, jira_search_issues).[3]
-
How to prefix:
- Use a short, unique service namespace, then an action and object in snake_case: service_action_object (e.g., gh_get_repo, jira_create_issue).[5][3]
- Keep names tokenization-friendly: prefer snake_case; avoid spaces and dots; underscores or dashes are acceptable, but snake_case is commonly recommended.[5]
-
What to prioritize besides prefixes:
- Write detailed descriptions explaining purpose, when to use, parameters, and limitations; this is the strongest driver of correct tool use by models.[2]
- Keep tool names specific and unambiguous even with a prefix (e.g., jira_transition_issue vs jira_update).[2][3]
- If the tools will live alongside other servers’ tools now or in the future, prefix all tool names with a concise service identifier and use snake_case (e.g., payments_create_refund, crm_get_contact).[3][5]
- If the environment is guaranteed single-server and the names are already specific and unique, a prefix is optional; still follow snake_case and avoid ambiguous, overly generic names, and provide rich descriptions.[1][2][5]
In short: prefixing is a sensible convention for namespacing and avoiding collisions, especially in multi-server setups, and combine it with snake_case and thorough descriptions for best results.[2][3][5]