Support for dynamic lists (tools, prompts, etc.)

[manusa]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Relates to #639
Relates to containers/kubernetes-mcp-server#490 (comment)

In the Kubernetes MCP Server, we provide base infrastructure for different Kubernetes teams to implement "toolsets": collections of MCP Tools, Prompts, and Resources exposed to MCP Clients and Hosts.

One key advantage of the Kubernetes MCP Server is its support for multi-cluster access integrated with Kubernetes authorization servers.
This creates a dynamic permissions scenario: each user (MCP server connection) has access to a different combination of Kubernetes clusters and resources based on their RBAC permissions.

i.e. for any given user (MCP server connection), there might be a combination of Kubernetes clusters that they can access and a combination of Kubernetes Resources (within each cluster) that they are authorized to operate on (RBAC).

Currently, this means users might see tools in tools/list that they cannot actually use due to authorization constraints.
When an LLM attempts to call these tools, it receives authorization errors rather than successful responses.

For this scenario, it would be great if the tools/list, prompts/list, resources/list, and so on could be composed dynamically.
Another option could be to provide a dynamic callback to see if the tool should be exposed in the list for the current request (filtering).

From a user experience (UX) perspective, it's my understanding that this would benefit any go-sdk-based project where capability varies by user.
Preventing LLMs from seeing unavailable actions would:

• Improve LLM decision-making by eliminating invalid options
• Reduce unnecessary network calls and authorization checks
• Provide clearer feedback about actual capabilities

I haven't found an easy, performant way to achieve this behavior with the current design/architecture of the SDK.

Does this functionality align with the go-sdk's design goals?
Shall we look into solutions to provide it?

[jba]

Can you use middleware to do the filtering?
You would want this: https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk@v1.1.0/mcp#Server.AddReceivingMiddleware.

[manusa]

Interesting, didn't think of that.

We already have a couple of middlewares e.g. for logging:

https://github.com/containers/kubernetes-mcp-server/blob/b4c20f9265c42556d1f26f504a3aac68c88ea2ca/pkg/mcp/middleware.go#L33-L48

I think we could easily add one for this purpose to do the job, thx!

Nonetheless, I still see the reusability of this functionality since IMO it's a common scenario.

[jba]

We'd prefer not to add convenience functions if something we already have will do the job. But if you get middleware working for you, we would love it if you contributed an example, so others could learn how to do it.

[nieomylnieja]

I also used the middleware to achieve this
I like the idea, but I fear dynamic tools handler would break stateless setups (like mine), unless it would have some underlying storage
I faced an issue where my gateway --> Traefik, only supported sticky sessions via cookies, so no header hashing (not out of the box, probably achievable with custom plugin) so I decided to switch the server to stateless mode
with custom middleware I run the whole dynamic tools logic with each request, sure it's a bit slower, but I have full control and ensure both listTools and tools/call requests are valid
I can't imagine a builtin handler which would (with ease) address the statefulness issues dynamic tools registration poses

I could contribute an example @jba once I have a bit of spare time

[smolinari]

(Reply assisted by AI, but 100% my take on this and also might involve my own lack of understanding 😝)

I strongly support the proposal for a ListTools hook.

Regarding the suggestion to use AddReceivingMiddleware as a workaround:

My understanding is that AddReceivingMiddleware intercepts the request before the default handler runs. To filter the tool list here, we would effectively have to hijack the tools/list method (returning a response immediately and blocking the default handler).

The Structural Challenge:
Unless the Server struct exposes its internal tool registry via a public getter (which standard SDKs usually don't for safety), a middleware defined in an external package **cannot access the tools registered via server.AddTool()**.

This creates a dilemma for any application with dynamic permissions (e.g. distinct Admin vs. User roles):

1. We want to use server.AddTool() for its convenience and standard registration logic.
2. But we cannot read that registry inside a middleware to filter it for the specific connection.

Without a native hook, we are forced to ignore server.AddTool() entirely and maintain a duplicate/parallel tool registry outside the SDK just to support basic visibility rules.

The Solution:
A native Hook allows us to leverage the SDK's internal state management while applying dynamic visibility rules at runtime. It enables the Server to use its internal registry but ask the application: "Which of these tools are valid for this specific connection context?"

Scott