docs(tools): discuss tool name conflicts and how to resolve them - #701
Conversation
cliffhall
left a comment
There was a problem hiding this comment.
Seems legit. Other strategies could be added here as they are discovered.
|
I feel ultimately the guidance of that final projection, from MCP-tool-data to client-model, is wholly in control of the client and is complex; depending on use case, prompting and model capability. So isn't something we should proscribe but rather various client share their advice? |
Yes, the newer versions of this documentation update offer a few suggestions rather than prescribing a specific approach, for the reasons you mentioned. |
|
@olaservo At least with Claude 3.7+, the Added another URI-based suggestion because it keeps coming up in the committee - I have more concerns about that in this context, but having more options doesn't hurt (mostly). |
|
@nickcoai Just made the phrasing even less prescriptive, in case it still sounded that way. |

Adds a note to the Best Practices section of the Tools documentation on tool name conflicts and how to resolve them in MCP client applications and MCP server proxies.
Motivation and Context
Helps to codify and establish a convention for dealing with tool name conflicts for application builders.
Useful guidance to follow as a stopgap unless or until #334 moves forward.
How Has This Been Tested?
This approach is used in Q Dev CLI (source), but it's just a simple pseudo-namespacing convention that is broadly generalizable.
Breaking Changes
N/A
Types of changes
Checklist
Additional context