Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow change McpClientTool's name property in host with mcp clients #154

Closed
zh6335901 opened this issue Mar 31, 2025 · 6 comments
Closed
Labels
enhancement New feature or request

Comments

@zh6335901
Copy link

In my application, I need intergrate multiple mcp servers for one LLM, So i need add server name prefix to tool name in order to let application know which server the tool comes from.
But the name property in McpClientTool cannot be changed, And it also can't reconstruct McpClientTool with new name.

@zh6335901 zh6335901 added the enhancement New feature or request label Mar 31, 2025
@stephentoub
Copy link
Contributor

Can you elaborate on the scenario?

You're walking up to an MCP server, calling its ListTools to get back a list of the tools it supports, it gives you back a tool named "Something", and then you want to change that name to "PrefixSomething" when you call back to that MCP server? And the server will happily accept "PrefixSomething" even though it told you the name of the tool was "Something"?

@zh6335901
Copy link
Author

Can you elaborate on the scenario?

You're walking up to an MCP server, calling its ListTools to get back a list of the tools it supports, it gives you back a tool named "Something", and then you want to change that name to "PrefixSomething" when you call back to that MCP server? And the server will happily accept "PrefixSomething" even though it told you the name of the tool was "Something"?

In my scenario, the application integrates multiple MCP servers (e.g., Playwright MCP server, Github MCP server). I retrieve all tools from each MCP server using the ListToolsAsync method and pass them combined to the LLM. The LLM then selects and calls appropriate tools based on my needs. However, I'm concerned about potential tool name conflicts making it unclear which server's tool should be called. To address this, I want to add prefixes to distinguish between different tools.

Maybe I don't have to worry about tool name conflicts?

@stephentoub
Copy link
Contributor

Thanks. So it's not that you want to change the name of the tool as it's known to the MCP server, but you want to advertize its name differently to the LLM, and then when the LLM asks for the tool by the modified name, you refer to it by its original name when calling to the MCP server, yes?

@zh6335901
Copy link
Author

zh6335901 commented Mar 31, 2025

Thanks. So it's not that you want to change the name of the tool as it's known to the MCP server, but you want to advertize its name differently to the LLM, and then when the LLM asks for the tool by the modified name, you refer to it by its original name when calling to the MCP server, yes?

Yes, this is what i mean. I would split the modified tool name to get server name and actual tool name, then use server name to get the corresponding mcp client, make a request with actual tool name

@PederHP
Copy link
Collaborator

PederHP commented Mar 31, 2025

Yes, this is what i mean. I would split the modified tool name to get server name and actual tool name, then use server name to get the corresponding mcp client, make a request with actual tool name

It's a very relevant problem, but I think a forced pattern of "server.tool" isn't flexible enough for all cases. LLM tool accuracy is often highly dependent on naming, and I've had cases where I renamed MCP tools (in raw handlers) to get better accuracy. I don't think many (if any) server authors use evaluations to optimize the accuracy impact of their tool names.

@stephentoub
Copy link
Contributor

Addressed by #165

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants