Per-client notifications infrastructure

[david-martin]

Summary

Implement infrastructure to support per-client notifications through the MCP Gateway. This is a prerequisite for several MCP features that require client-specific event delivery.

Background

The current notification implementation supports only broadcast (state change) notifications that are safe to send to all connected clients. However, several MCP features require per-client notification delivery:

• MCP Logging (notifications/message) - log messages are client-specific
• Resource subscriptions (notifications/resources/updated) - subscription state is per-client

Per the notifications design doc, this is currently a non-goal due to complexity:

This is a technical limitation due to the complexity of implementing a fan-out approach where the broker would need to maintain separate GET connections to each backend MCP server for each client, particularly when those connections require the client's authentication credentials.

Challenges

1. Managing per-client, per-server GET connections with client-specific authentication
2. Connection lifecycle management and reconnection logic for multiple fan-out connections
3. Resource overhead of maintaining many concurrent connections

Scope

This issue is for investigating and designing the infrastructure needed. Implementation of specific features (logging, subscriptions) will be tracked in separate issues.

Related Issues

• Blocks Support for MCP logging #407 (Support for MCP logging)
• Blocks Support for resource subscriptions #597 (Support for resource subscriptions)

References

• MCP Architecture - Notifications
• Notifications Design Doc

Tracking

• MCP Notifications Feature Support #600 - MCP Notifications Feature Support (parent tracking issue)