Motivation and context

Fixes #1197.

Applications need a place to enforce their own outgoing-notification policy, such as filtering request-scoped log messages or extension notifications. The default behavior should remain permissive.

This is a draft for feedback on the public API shape before marking it ready for review.

Changes

• Add McpServer.Builder.notifierFactory(BiFunction<McpRequestContext, McpAsyncNotifier, McpAsyncNotifier>).
• Supply each factory invocation with the current request context and its default notifier, allowing applications to decorate notification delivery while retaining existing progress handling.
• Invoke the factory lazily once per stream subscription, including streams used by sync handlers and subscriptions/listen. Non-streaming results do not invoke it.
• Preserve the default notifier unchanged when no factory is configured. No built-in logging policy is added.
• Reject null factory results and route factory failures through the existing in-band streaming error path; HTTP status is already committed at this point.
• Document the hook and cover context-dependent filtering, lazy per-request creation, progress forwarding, notification rejection, invalid factories, and sync-handler customization.

API choice for discussion

The factory receives the default notifier rather than a Reactor sink. This supports policy decorators without exposing sink internals or adding another public interface. The default factory simply returns the supplied notifier.

Validation

117 selected core and transport tests passed, with no failures or skips:

./mvnw -q -pl mcp-test -am "-Dtest=McpServerTests,ToolsFeatureTests,SubscriptionsFeatureTests,HttpServletMcpTransport*Tests,StdioMcpTransportTests" -Dsurefire.failIfNoSpecifiedTests=false test

Formatting is validated by the Maven build. The full repository and conformance suites were not run.

AI-assisted implementation using GitHub Copilot.