René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Expose session, auth, and transport information on handler Context","articleBody":"## Problem\n\nUsers 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.\n\nThere are three categories of information users are asking for:\n\n### Session identity\n\nUsers 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.\n\n- #485 — \"How to get session_id in tool\"\n- #942 — \"How to expose mcp_session_id to user?\"\n\n### Auth credentials\n\nUsers 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.\n\n- #638 — \"FastMCP Auth Context in tools\"\n\n### Transport metadata (HTTP headers, client info)\n\nUsers 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`.\n\n- #750 — \"How to get HTTP request headers in tools\"\n- #375 — \"Passing client context to tools\"\n\n## Current state\n\nThe underlying data is available in the system — it just is not reachable from `Context`:\n\n- **Session ID**: managed by `StreamableHTTPSessionManager` / `SseServerTransport`, not exposed to handlers\n- **Auth info**: stored in `auth_context_var` by `AuthContextMiddleware`, not exposed to handlers\n- **HTTP request**: passed through as `request_context: Any` on `ServerMessageMetadata`, available on `ServerRequestContext.request` but not on `Context`\n\n## Scope\n\nThis issue is about designing and implementing access to these three categories of information on the handler `Context`. Key design considerations:\n\n- 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\n- The solution should work for both MCPServer (high-level) and low-level server handlers\n- Should be consistent with the direction of #2021 (typed transport context) and #1684 (explicit context parameters)\n\n## Prior art\n\n- PR #1608 — adds `ctx.session_id` by threading through `InitializationOptions` → `ServerSession` → `RequestContext` → `Context`\n\n## Related issues\n\n- #2021 — Refactor handler context to be transport- and handler-type-aware (v2 architectural)\n- #1684 — Refactor global contextvars into explicit parameters (v2 architectural)\n- #2054 — Add dependency injection support to MCPServer (v2 architectural)\n\n\u003csub\u003e[AI Disclaimer](https://gist.github.com/maxisbey/6123d132484e4c533eab519a2800693d)\u003c/sub\u003e","author":{"url":"https://github.com/maxisbey","@type":"Person","name":"maxisbey"},"datePublished":"2026-02-19T13:20:17.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/2098/python-sdk/issues/2098"}