Allow subclasses to be used to customize server behavior

まず McpAsyncServer を読み、特に issue で名前が挙げられている package-private コンストラクターと、prepareRequestHandlers、prepareNotificationHandlers、setSessionFactory の各エントリーポイントを確認します。McpSyncServer や McpStateless* を含む他のルートサーバークラスと比較し、issue #525 の関連する拡張性リクエストも確認します。SDK 利用者が、サーバーを再実装せずに、機能、初期化、セッションの作成と型、および関連するサーバーの動作をカスタマイズできれば完了です。

What I say below is (mostly) appropriate to the other types of server classes (i.e. McpSyncServer, McpStateless*), but I'm going to focus specifically on McpAsyncServer current impl for clarity.

Currently the McpAsyncServer constructors are package private...e.g.

	/**
	 * Create a new McpAsyncServer with the given transport provider and capabilities.
	 * @param mcpTransportProvider The transport layer implementation for MCP
	 * communication.
	 * @param features The MCP server supported features.
	 * @param jsonMapper The JsonMapper to use for JSON serialization/deserialization
	 */
	McpAsyncServer(McpServerTransportProvider mcpTransportProvider, McpJsonMapper jsonMapper,
			McpServerFeatures.Async features, Duration requestTimeout,
			McpUriTemplateManagerFactory uriTemplateManagerFactory, JsonSchemaValidator jsonSchemaValidator) {
		this.mcpTransportProvider = mcpTransportProvider;
		this.jsonMapper = jsonMapper;
		this.serverInfo = features.serverInfo();
		this.serverCapabilities = features.serverCapabilities().mutate().logging().build();
		this.instructions = features.instructions();
		this.tools.addAll(withStructuredOutputHandling(jsonSchemaValidator, features.tools()));
		this.resources.putAll(features.resources());
		this.resourceTemplates.putAll(features.resourceTemplates());
		this.prompts.putAll(features.prompts());
		this.completions.putAll(features.completions());
		this.uriTemplateManagerFactory = uriTemplateManagerFactory;
		this.jsonSchemaValidator = jsonSchemaValidator;

		Map<String, McpRequestHandler<?>> requestHandlers = prepareRequestHandlers();
		Map<String, McpNotificationHandler> notificationHandlers = prepareNotificationHandlers(features);

		this.protocolVersions = mcpTransportProvider.protocolVersions();

		mcpTransportProvider.setSessionFactory(transport -> {
			String sessionId = UUID.randomUUID().toString();
			return new McpServerSession(sessionId, requestTimeout, transport, this::asyncInitializeRequestHandler,
					requestHandlers, notificationHandlers, () -> this.cleanupForSession(sessionId));
		});
	}

Among other things, this means that users of the sdk cannot customize the server runtime behavior, as they are essentially forced to use not only the static factory methods, but also cannot provide custom features on construction nor customize the server initialization via the methods called in the constructor: prepareRequestHandlers, prepareNotificationHandlers, and importantly: setSessionFactory (which also means that the sessionid creation cannot be altered, nor the type of the McpServerSession.

In some servers the calling of setSessionFactory wants to be delayed, so that construction/initialization of members (feature contents, prepare method), can be separated from putting the server online by setting the session factory.

Use Case - Extensions

To implement some extensions, such as grouping and primitive update it's necessary to customize the feature set, initialization, factory setting session type and in some cases optionally override methods of McpAsyncServer (e.g. notification sending and contents) (which further need to access currently private members...e.g. list of tools, resources, primitives. With the current permissions, to do this customization would mean having to re-implement McpAsyncServer...outside of it's existing package, which seems like an unnecessary burden on sdk developers.

Also, there have been several unrelated community requests for sdk server extensibility here:

https://github.com/modelcontextprotocol/java-sdk/issues/525

I request that the McpAsyncServer (and other server root classes) be made more extensible by sdk consumers.

I understand that composition might be preferable architecturally, but to allow such composition would currently require a major refactoring and generalization of the server classes, so it seems that making members, constructors, and methods protected might be better in the short term.

Another option for implementing...that would retain binary backward compatibility...would be to introduce abstract super class(es) (for McpAsyncServer) and expose the relevant constructors, members, initialization methods in the abstract super class(es).