You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enable Server-Initiated Notifications to All Connected Clients #741
Is your feature request related to a problem? Please describe.
I'm frustrated that the server can only send notifications (like tools_list_changed) to the client associated with the current request. When the server changes tools, resources, or prompts outside of a request handler (e.g., when an administrator updates available tools), there’s no way to notify all connected clients. This is because the ServerSession is responsible for sending notifications, and it is only available while handling a specific client request. This leads to clients being out of sync with the server’s actual state.
Describe the solution you'd like
Track all active ServerSession instances in the server. Expose an API to broadcast notifications (such as tools_list_changed) to every connected client, not just the one associated with the current request context. This would let the server proactively inform all clients of important changes, keeping everyone in sync.
Describe alternatives you've considered
Sending notifications only in response to client requests (current behavior), but this doesn’t cover server-initiated changes.
Attempting to access the request context outside a handler, but this raises errors and isn’t supported by the current design.
Implementing a custom session registry in user code, but this is error-prone and would be better handled by the framework.
Additional context
This feature would support dynamic server-side changes (such as feature flags, admin actions, or configuration updates while the server is running) and improve the consistency and user experience for all clients.
I’m open to feedback or alternative approaches if there’s a better way to achieve this. Thanks for considering this improvement!
As you mention, this can be implemented by applications that need it - many will not. As it's our goal for the MCP SDK to be a minimal implementation of the core protocol, we'd rather not take on this maintenance complexity.
If you believe this would be a widely requested feature, it may be worth filing a SEP so that we figure out a standard way of implementing this broadcasting across SDKs.
Activity
felixweinberger commentedon Oct 7, 2025
See also #905
As you mention, this can be implemented by applications that need it - many will not. As it's our goal for the MCP SDK to be a minimal implementation of the core protocol, we'd rather not take on this maintenance complexity.
If you believe this would be a widely requested feature, it may be worth filing a SEP so that we figure out a standard way of implementing this broadcasting across SDKs.