Ability for MCP Client to resume the session with MCP Server

[pankajvaher]

Is your feature request related to a problem? Please describe.**

We use McpClientFactory.CreateAsync to get an MCPClient instance to interact with the MCP server. Each time McpClientFactory.CreateAsync is invoked, a fresh session is established. In our case, this results in different sessions being created for different turns within the same conversation.

We need a way to reuse the same session across successive turns.

Describe the solution you'd like

Persistent Sessions

Provide an option during McpClient instantiation (e.g., a flag or parameter) to prevent sending a session deletion request to the MCP server when the McpClient instance is disposed. This allows the server-side session to remain active after the client object is disposed.

Session Resumption Capability

Introduce a mechanism to resume an existing session on subsequent turns. For example:

• Allow passing a previously obtained sessionId (along with negotiated protocol version and capabilities) into McpClientFactory.CreateAsync, or
• Introduce a new method such as ResumeSessionAsync.

This would allow the client to reconnect to an existing session instead of starting a new one.

Session State Persistence

Support capturing and reusing session state between turns. This could work in two ways:

1. SDK-Provided Serialization:
   Provide a method or property to retrieve the session details (sessionId, protocol version, negotiated capabilities) in a serialized form that can be persisted and later supplied to resume the session.

2. Caller-Managed Persistence:
   Document and support a workflow where the application persists the session details itself and passes them back into the SDK to resume the session.

[PederHP]

It should be noted that session id is a transport level concept. MCP doesn't have strong session/scoping mechanisms at the protocol level (yet). A connection lifecycle is not equivalent to a session or conversation. Some clients may even have multiple scopes in a connection. I suggest looking into metadata if you control both client and server. If you want it to work with any client, things get tricky as they don't necessarily provide you the information you need. But you're right about raising this. Others hsve also raised various aspects of it at the protocol level.

[mikekistler]

How should this work for MCP servers that require authentication? Does the host capture the auth token and supply it along with the sessionId when resuming the session, or do you expect the SDK to drive the whole authentication process again? Note that in the latter case the result might be a token that server could reject as not associated with the session.

[halter73]

Provide an option during McpClient instantiation (e.g., a flag or parameter) to prevent sending a session deletion request to the MCP server when the McpClient instance is disposed.

This is partially covered by #621. Do you have any suggestions for what the option should be called? HttpClientTransportOptions.DisableDeleteSessionRequest? HttpClientTransportOptions.PreserveSession?

I think HttpClientTransportOptions.SessionId is easy enough. Should supplying a session ID disable the delete request automatically since the McpClient would no longer be the original owner of the session conceptually? You'd still need a way to disable the delete request when starting a new session though.

I also wonder if we need something like McpClientOptions.KnownServerInfo as an analog to McpServerOptions.KnownClientInfo. We could make McpClient.ServerInfo and McpClient.ServerCapabilities nullable similar to McpServer.ClientInfo and McpServer.ClientCapabilities, but I worry that this will cause unnecessary nullability warnings for the majority people who start a new session every time they connect a new McpClient.

How should this work for MCP servers that require authentication?

This should be improved once we merge #834.