Support server to client notifications from the stateless transport

[Randgalt]

The MCP spec allows stateless servers to send notifications to the client during a request. The response needs to be upgraded to SSE and the notifications are send in a stream until the final result is sent.

This commit adds a sendNotification method to the transport context allowing each transport implementation to implement it or not. In this commit, HttpServletStatelessServerTransport implements the method and when the caller first sends a notification, the response is changed to TEXT_EVENT_STREAM and events are then streamed until the final result.

This change will allow future features such as logging, list changes, etc. should we ever decide to support sessions in some manner. Even if we don't support sessions, sending progress notifications is a useful feature by itself.

Motivation and Context

We would like to have support for progress notifications in the stateless implementation.

How Has This Been Tested?

• testNotifications() added to HttpServletStatelessIntegrationTests
• manual testing with the MCP inspector

Breaking Changes

none

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[Randgalt]

An alternative to this might be a separate McpNotifier instance that would be accessed by calling McpTransportContext.get() with a lib-defined key. wdyt?

[Randgalt]

@tzolov do you have plans to support sessions for the stateless transport/server? We have some ideas that we will likely implement in our own code but could contribute here if there's interest.

[Randgalt]

Noe: I've only done HttpServletStatelessServerTransport. I'm changing this to Draft so that I can get feedback. Is this PR worth pursuing for the other transports?

[Randgalt]

@tzolov any interest in this? If so, I can rebase, etc.

[codyzwief]

I would be +1 to adding this, and would be happy to help or to pick up the rebasing/tests/work/etc if @Randgalt is busy with other things to do and @tzolov is OK with this addition to the library.

[Randgalt]

I will update the PR if the project is positive on the idea

[chemicL]

Hey, @Randgalt. I have been away from the project for a while so I apologize your proposal has not attracted a proper review this time.

I agree we should definitely support upgrade to SSE in stateless responses to allow for notifications to be part of the stream.

The PR, however, relies on the ability to use imperative APIs of the servlet stack, while it would not fly in other server implementations that expect a Publisher. The correct approach requires some research on how to effectively communicate the intent of the server developer - either by providing a fixed response, driving the transport to return a plain content or providing a Publisher, allowing the developer to send notifications which are terminated with the actual response to the originating request.

[Randgalt]

Thanks @chemicL - FWIW we've decided to implement our own backend instead of relying on this implementation so our contributions here will be limited.