* Add idle session pruning tests
* Remove redundant CTS from StreamableHttpHandler
* StreamableHttpServerTransport.HandlePostRequest already creates the equivelant CTS
which DeleteRequest_CompletesSession_WhichCancelsLongRunningToolCalls verifies
* Fix accept header validation for GET
* Use InvalidOperationException for transport-not-connected errors in doc comments
* Fix flaky Cancellation_ThrowsCancellationException test
- Changes IJsonRpcMessage to an abstract base class so RelatedTransport will always be available
- Streamable HTTP supports multiple concurrent HTTP request with their own indpendent SSE response streams
- RelatedTransport indicates the source or destination of the JsonRpcMessage
- Changes the default RequestId to a JSON number for better compatibility with MCP servers in the wild
* AI generated `///` comment updates
* Fix compilation issues
* Fix incorrect XML comment structure
* Update all Client comments
* Update all Configuration comments
* Update all Messages comments
* Update all Transport comments
* Update all Types comments
* Update all Server comments
* Undo some commenting
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
- We still allow notification handlers to be configured pre-creation, eliminating any race conditions that may result from missed notifications. But now we also allow for post-creation notification handler registration.
- Handlers may now also be removed. This permits temporary registrations that may be created in a scoped manner.
- Registration handling is thread-safe.
- Handlers are now cancelable.
- Exceptions from notification handlers trigger all normal exception handling in the dispatch pipeline.
This also:
- Adds a WithStreamServerTransport as a counterpart to WithStdioServerTransport. The latter was used in several tests in a hacky way, and that's now simplified via the former's existence.
* Move notification handler registrations to capabilities
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.
* Address more feedback and further cleanup
* Allow user-defined JsonSerializerOptions for user-defined and inputs and hardcode everything else to the source generator.
* Add validation for user-defined JsonSerializerOptions.
* Remove out of date comment.
* Address feedback and add tests
