API: Generalize notifications for SDK server classes

I'm building an extension that uses the Java sdk that uses notifications to send 'tool add/delete/update' data to clients (e.g. when new tools are added to an MCP server at runtime).

For this extension to work, it's necessary to provide a new topic string and non-null data to the following transport-level call:

Line 510 in current McpAsyncServer

	public Mono<Void> notifyToolsListChanged() {
		return this.mcpTransportProvider.notifyClients(McpSchema.METHOD_NOTIFICATION_TOOLS_LIST_CHANGED, null);
	}

There is currently no way for the extension to add a custom param to this notification, nor to define a new value for the topic...both of which are required for the extension...e.g.:

public/protected Mono<Void> notifyToolsListChanged(String topic, Object param) {
	return this.mcpTransportProvider.notifyClients(topic, param);
}

Where my extension wishes to call via something like:

server.notifyToolsListChanged("myorg/update", myData);

In a issue #793 I suggested allowing inheritance of the McpAsyncServer class, so that the notifyToolsListChanged() could be overridden by subclasses (via public or protected constructors, constructor args, and member variables) and call the transport directly with desired arguments.

Although I still believe inheritance of core classes is sometimes reasonable for an SDK, it seems that composition is currently favored for this case. There is no way that can see for this to be done through composition currently.

This extension also needs to have some way to prevent the existing notification notifyToolsListChanged() from being sent by addTool and remove/Tool (asynchronously)...meaning that addTool/removeTool need to be customized as well.

Note that I'm interested in generalizing this update extension to other primitives...e.g. resources and prompts...plus others...so the same extension access for server-side dynamic updates. Ultimately it's not just for tools but I'm starting with tools.

On the McpAsyncClient, conversely, there are notification handlers that can be passed into the client on construction, allowing it to receive custom topics with params.

Clearly there are multiple ways to fix this in the SDK. One suggestion: Consider defining a public AbstractAsyncServer superclass, and moving protected members, constructors, and generalized methods into that super class. This is the one way with inheritance that I'm aware of that allows generalization and will not break binary compatibility for the current McpAsyncServer API consumers (e.g. by renaming public methods).

With that said, I'm open to composition rather than inheritance as a solution (as long as it supports what this update extension needs), but afaict will likely require larger refactoring and perhaps API changes at this point.

Commencez par McpAsyncServer, en particulier notifyToolsListChanged() autour de la ligne 510, et suivez la manière dont addTool et removeTool déclenchent les notifications. Comparez cela avec les gestionnaires de notifications de McpAsyncClient et examinez l’issue #793. Le résultat devrait fournir aux extensions du serveur un moyen pris en charge d’envoyer des sujets personnalisés avec des données et de contrôler les notifications automatiques existantes des outils, tout en laissant de la place pour les ressources et les prompts.