Support passing an initial session ID to streamable HTTP client transport

[maxisbey]

Problem

In distributed client architectures (e.g., a proxy or gateway that fans out MCP requests across multiple backend workers), the client transport needs to reconnect to an existing server session that was established by a different process. Currently, streamable_http_client() and StreamableHTTPTransport provide no way to supply a pre-existing session ID — the transport always starts with session_id = None and only learns a session ID from the server's InitializeResult response:

python-sdk/src/mcp/client/streamable_http.py

Lines 75 to 82 in 0fe16dd

	def __init__(self, url: str) -> None:
	"""Initialize the StreamableHTTP transport.
	Args:
	url: The endpoint URL.
	"""
	self.url = url
	self.session_id: str | None = None

This means a distributed client backend cannot resume an already-initialized session without re-initializing, which defeats the purpose of session stickiness.

Use Case

A gateway/proxy receives requests from multiple upstream clients and routes them to MCP servers. The gateway initializes a session once and stores the resulting session ID. Subsequent requests — potentially handled by different gateway workers — need to attach that session ID to their outgoing requests without re-running the initialization handshake.

Spec Alignment

The MCP spec (2025-11-25) defines session IDs as server-assigned — the client echoes back what it received. This does not change that: the session ID still originates from the server. The gap is that the SDK does not allow a client transport instance to be pre-seeded with a session ID that was obtained earlier (by the same or a different process), rather than requiring every transport instance to go through initialization to learn it.

_{AI Disclaimer}

[maxisbey]

Closing as duplicate of #2116.