Making Endpoint optional on transport options

[aaronpowell]

Making the Endpoint optional, and nullable, on SseClientTransportOptions to better support integration with Aspire.

Fixes #515

Motivation and Context

As described in #515, the requirement to provide an Endpoint poses a challenge when working with Aspire, or anything that might want to delegate the endpoint to the HttpClient using an implementation of IServiceEndpointProvider.

How Has This Been Tested?

I've added a .NET Aspire sample (app host, service defaults and mcp server/client).

Breaking Changes

There's an API breaking change as the Endpoint property is now nullable (and not required).

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

Additional context

I've creating this as a draft PR initially as there's many failing tests, as there's many places we provide an Endpoint and HttpClient, but they don't match addresses, and I'm not sure the role of the HttpClient in those tests.

[halter73]

Rather than making the Endpoint fully optional, could we make it take a relative endpoint (e.g. new Uri("/", UriKind.Relative)? Maybe we just need to relax the validation in the setter rather than making it completely nullable.

Also, while it does demonstrate the motivation for this change, I don't think we're ready to take on the maintenance of a Blazor + Aspire sample. If anything, I'd want to consolidate the samples, but that should be done after discussing what we can combine.

[aaronpowell]

Rather than making the Endpoint fully optional, could we make it take a relative endpoint (e.g. new Uri("/", UriKind.Relative)? Maybe we just need to relax the validation in the setter rather than making it completely nullable.

If that's more viable, then sure.

Also, while it does demonstrate the motivation for this change, I don't think we're ready to take on the maintenance of a Blazor + Aspire sample. If anything, I'd want to consolidate the samples, but that should be done after discussing what we can combine.

Totally. I wanted to illustrate with a full e2e sample of what I am trying to do, but to do that it required changes in the underlying library so it was easier to do it in the repo. If this progresses forward, I would radically simplify the sample so there's not so many additional pieces in there.