modelcontextprotocol
Proposal: provide a Server.SetTools method
Description
The design document clearly states that one of the differences between the official SDK and Mark3Labs mcp-go is that only Server.AddTools is provided and that the rest of Tool-management functions are deemed unnecessary:
https://github.com/modelcontextprotocol/go-sdk/blob/9ef2b2742ea1b6fed83b8ae40a96d0006e45d739/design/design.md?plain=1#L670
There are also some comments in the code regarding the batch notification of tool changes:
https://github.com/modelcontextprotocol/go-sdk/blob/9ef2b2742ea1b6fed83b8ae40a96d0006e45d739/mcp/server.go#L229-L235
Problem
The AddTool logic allows for an upsert (adding or replacing) of a tool based on the name.
However, this seems insufficient when we want to completely replace the list of available tools. The problems are mainly two:
- The additional pressure on the client for each tool addition (a new notification is sent for each).
- The requirement to track the tools that have been exposed in the server in case we no longer want to expose one of them.
In the Kubernetes MCP Server we require this functionality to be able to replace the complete tool list that is exposed to the client, which at some point be more more restricted. This forces us to first remove all the tools and then add them again.
Alternatives
At the moment we've implemented the workaround in our repository by tracking the tools and doing the removal and then the addition:
https://github.com/containers/kubernetes-mcp-server/blob/b4c20f9265c42556d1f26f504a3aac68c88ea2ca/pkg/mcp/mcp.go#L129-L166
This works, but if others find it useful I think it might be better to provide the feature in the SDK itself.
Additional Context
I actually created the original SetTools method in the mcp-go repository, the reasoning exposed in the PR is the same for this feature request:
https://github.com/mark3labs/mcp-go/pull/24
Kubernetes MCP Server related issues and PRs:
- https://github.com/containers/kubernetes-mcp-server/pull/385
- https://github.com/containers/kubernetes-mcp-server/issues/219
If you're interested on this feature I can work on its implementation.
Thanks for filing this issue.
As you noted, we've resisted adding any batch API for tools, because it creates yet another mechanism for binding tools. But more generally, we didn't know what people would need, and wanted to wait before adding more API.
Some people have requested the ability to filter tools, others have requested the ability to AddTools in a batch. In our own use cases on the Go team, we have a small number of static tools, so I'd really like input from other users about what would work best.
An advantage of 'SetTools' is that it handles both Add and Remove, as well as providing a batch API. It might be the smallest change that meets all of the various requirements around tool management.
But again, I'd really like to hear from others here.
