Move notification handler registrations to capabilities

[stephentoub]

Currently request handlers are set on the capability objects, but notification handlers are set after construction via an AddNotificationHandler method on the IMcpEndpoint interface. This moves handler specification to be at construction as well. This makes it more consistent with request handlers, simplifies the IMcpEndpoint interface to just be about message sending, and avoids a concurrency bug that could occur if someone tried to add a handler while the endpoint was processing notifications.

[Copilot]

Copilot reviewed 16 out of 16 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

tests/ModelContextProtocol.Tests/SseIntegrationTests.cs:233

• The square bracket initializer syntax used for NotificationHandlers may not be standard C#. Consider replacing it with a conventional collection initializer (e.g., 'new [] { ... }' or 'new List<KeyValuePair<string, Func<JsonRpcNotification, Task>>>() { ... }') to ensure compatibility.

NotificationHandlers = [new("test/notification", (args) =>

[halter73]

While I think it might be useful to be able to add handlers mid-session, the fact you couldn't remove them made it half-baked regardless. And we can always add that capability back if there's a real need.

[stephentoub]

And we can always add that capability back if there's a real need.

Someone can also do it on their own, just by adding a handler that reads from any collection they want to subsequently mutate. That single handler will be invoked and can effectively proxy the call to any number of handlers elsewhere.

[eiriktsarpalis]

Thanks