Expose session, auth, and transport information on handler Context

Problem

Users consistently need access to transport-level information from inside tool, resource, and prompt handlers. Today, this data exists in the system but is not accessible through the Context object that handlers receive.

There are three categories of information users are asking for:

Session identity

Users need to identify which client session they are serving — for per-session state, logging, debugging, or multi-tenant scenarios. The session ID exists at the transport layer (e.g., Mcp-Session-Id header for streamable HTTP, UUID query param for SSE) but there is no way to read it from a handler.

• #485 — "How to get session_id in tool"
• #942 — "How to expose mcp_session_id to user?"

Auth credentials

Users completing an OAuth flow need to access the authenticated token or claims inside their handlers. The auth middleware already validates tokens and stores them in a ContextVar (auth_context_var), but Context does not expose this.

• #638 — "FastMCP Auth Context in tools"

Transport metadata (HTTP headers, client info)

Users need access to HTTP request headers, client IP, or other request-level metadata. The Starlette Request object is passed through as ServerMessageMetadata.request_context and lands on ServerRequestContext.request, but it is typed as Any and not surfaced on Context.

• #750 — "How to get HTTP request headers in tools"
• #375 — "Passing client context to tools"

Current state

The underlying data is available in the system — it just is not reachable from Context:

• Session ID: managed by StreamableHTTPSessionManager / SseServerTransport, not exposed to handlers
• Auth info: stored in auth_context_var by AuthContextMiddleware, not exposed to handlers
• HTTP request: passed through as request_context: Any on ServerMessageMetadata, available on ServerRequestContext.request but not on Context

Scope

This issue is about designing and implementing access to these three categories of information on the handler Context. Key design considerations:

• Behavior varies by transport — stdio has no session ID, headers, or auth; stateless HTTP has no session ID; SSE has a different session ID mechanism than streamable HTTP
• The solution should work for both MCPServer (high-level) and low-level server handlers
• Should be consistent with the direction of #2021 (typed transport context) and #1684 (explicit context parameters)

Prior art

• PR #1608 — adds ctx.session_id by threading through InitializationOptions → ServerSession → RequestContext → Context

Related issues

• #2021 — Refactor handler context to be transport- and handler-type-aware (v2 architectural)
• #1684 — Refactor global contextvars into explicit parameters (v2 architectural)
• #2054 — Add dependency injection support to MCPServer (v2 architectural)

_{AI Disclaimer}

Beginne damit, Context, ServerRequestContext und ServerMessageMetadata.request_context nachzuverfolgen, und untersuche dann StreamableHTTPSessionManager, SseServerTransport und AuthContextMiddleware. Vergleiche die Ansätze in #2021, #1684 und #1608. Als abgeschlossen gilt die Aufgabe, wenn Handler konsistent über alle unterstützten Transports hinweg auf die jeweils relevanten Sitzungs-, Authentifizierungs- und Transportinformationen zugreifen können, einschließlich der dokumentierten Fälle, in denen Daten nicht verfügbar sind.