Add a way to customize default request handlers for Stateless server

[mikegron]

Expected Behavior

Currently using the Stateless server. We need a way to override the behavior of a single request handler, for instance the tools/list request to provide custom tool descriptions.

Current Behavior

The McpStatelessAsyncServer constructor currently creates a DefaultMcpStatelessServerHandler as mcpHandler for the ServerTransport with private methods as handlers with private variables.
We can currently override the mcpHandler after-the-fact using McpStatelessServerTransport::setMcpHandler, but it would be nice to override only a single handler, for example adding a couple of getters:

var serverTransport = WebMvcStatelessServerTransport.builder() [...] .build();
...
var server = McpServer.sync(serverTransport).tools(tools) [...] .build();

// Override default request handler
serverTransport.getMcpHandler()
               .getRequestHandlers()
               .put(McpSchema.METHOD_TOOLS_LIST, myCustomToolsList(tools));

What do you think?

Context

We want customizable tool descriptions per-user with minimal code duplication of the SDK.

[jpdivya123]

Hi,

We do also in need of this feature on McpAsyncServer

We need to filter which tools are visible to clients in the tools/list response based on runtime conditions (user roles, session context, etc.) while keeping all tools available for execution. Currently, this is not possible because:
The tools field in McpAsyncServer is private with no public getter
The toolsListRequestHandler() method is private and cannot be overridden
io.modelcontextprotocol.spec.DefaultMcpStreamableServerSessionFactory , do not have mutable methods to add more request handlers .
There's no mechanism to customize tool visibility without completely rebuilding the server.

[nmiguezg]

Hi,

We do also in need of this feature on McpAsyncServer

We need to filter which tools are visible to clients in the tools/list response based on runtime conditions (user roles, session context, etc.) while keeping all tools available for execution. Currently, this is not possible because: The tools field in McpAsyncServer is private with no public getter The toolsListRequestHandler() method is private and cannot be overridden io.modelcontextprotocol.spec.DefaultMcpStreamableServerSessionFactory , do not have mutable methods to add more request handlers . There's no mechanism to customize tool visibility without completely rebuilding the server.

+1. I think making the methods toolsListRequestHandler(), toolsListRequestHandler(), resourcesListRequestHandler(), and so on protected would make the McpAsyncServer class much more extensible. I don't understand the need for making all those methods private preventing proper inheritance.

[mikegron]

I agree, extending the class would be fairly easy then!

[bcersows]

Seconding this. :)