Pass session id's to MCP endpoints.

[eiriktsarpalis]

Ensures that MCP servers and clients have access to the underlying session id (typically the value of the Mcp-Session-Id header in streamable http). It does so by making the following (breaking) API changes:

• Adds a nullable SessionId property to the ITransport interface.
• Adds a Transport property to the IMcpEndpoint interface.

This lets consumers of IMcpServer and IMcpClient obtain the underlying session id by evaluating endpoint.Transport.SessionId. Note that the session id can be null if

1. The transport hasn't initialized yet or
2. The transport doesn't support multiple sessions as is the case with STDIO.

[halter73]

Other than exposing the SessionId, is there any other reason we want to expose the ITransport on the IMcpEndpoint? If not, should we start with exposing just the SessionId and not the entire ITransport?

I'd also consider just telling people to use IHttpContextAccessor to read the mcp-session-id response header inside their tools and other handlers if they care. It should be just as reliable without mucking up our core interfaces like ITransport and IMcpEndpoint with stuff that isn't that relevant to non-HTTP transports. This is more discoverable though for people creating their own logs, so I see the appeal there, but maybe we could just add documentation and hold off on the API change.

I think this would be more valuable if we included the session id in all the logs that can realistically have them similar to what we do for Kestrel with connection IDs and request IDs.

[eiriktsarpalis]

Other than exposing the SessionId, is there any other reason we want to expose the ITransport on the IMcpEndpoint? If not, should we start with exposing just the SessionId and not the entire ITransport?

Exposing the transport seems like the reasonable thing to do given that each MCP endpoint corresponds to one instance. What are some of the drawbacks of doing it? Lack of encapsulation? I have no strong opinions on the matter.

I'd also consider just telling people to use IHttpContextAccessor to read the mcp-session-id response header inside their tools and other handlers if they care.

Sure, but this only works provided that you only use your tools with streamable http exclusively. If your tool is invoked via legacy sse there is no mcp-session-id header as such but the concept of a session id does exist (albeit one scoped to the current server process) and can be used to meaningfully correlate invocations. My intention with this change is to provide a transport-agnostic identifier that also works in the case of stdio.

[halter73]

What are some of the drawbacks of doing it? Lack of encapsulation? I have no strong opinions on the matter.

Mostly the lack of encapsulation. We can always update this later, but I'd prefer to just expose the string? SessionId on the IMcpEndpoint for now.

[AArnott]

My two cents: If a user implementation of an MCP server has no business sending JSON-RPC messages or other functionality exposed by ITransport, then I would suggest just share a session id string as well.

[eiriktsarpalis]

I've updated IMcpEndpoint so that a string? SessionId is exposed instead of the transport.