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.
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.
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.
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:
Prior art
Related issues
AI Disclaimer
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
Contextobject 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-Idheader for streamable HTTP, UUID query param for SSE) but there is no way to read it from a handler.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), butContextdoes not expose this.Transport metadata (HTTP headers, client info)
Users need access to HTTP request headers, client IP, or other request-level metadata. The Starlette
Requestobject is passed through asServerMessageMetadata.request_contextand lands onServerRequestContext.request, but it is typed asAnyand not surfaced onContext.Current state
The underlying data is available in the system — it just is not reachable from
Context:StreamableHTTPSessionManager/SseServerTransport, not exposed to handlersauth_context_varbyAuthContextMiddleware, not exposed to handlersrequest_context: AnyonServerMessageMetadata, available onServerRequestContext.requestbut not onContextScope
This issue is about designing and implementing access to these three categories of information on the handler
Context. Key design considerations:Prior art
ctx.session_idby threading throughInitializationOptions→ServerSession→RequestContext→ContextRelated issues
AI Disclaimer