René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Propagate ContextVars to Transport Layer in MCP Clients","articleBody":"### Description\n\n## Summary\n\nEnsure that `contextvars` set in the calling thread are properly propagated to the transport layer at request time, enabling dynamic configuration of transport settings (e.g., HTTP headers, auth mechanism, etc.) on a per-request basis.\n\n## Problem Statement\n\nCurrently, `contextvars` set in the main thread are not visible in the transport layer when making requests. This is because:\n\n1. **Context isolation**: The `streamable_http_transport` runs in a different async context or thread, so context vars set after initialization are not visible\n2. **One-time copy**: Context may be copied only at session/transport creation time, not per-request\n\nThis prevents common use cases:\n- **Authentication**: Custom `httpx.Auth` implementations that read from context vars cannot access values set in the calling code\n- **Token Exchange**: Middleware that performs OAuth token exchange and stores the result in a context var cannot make that token available to outbound MCP requests\n- **Tracing**: Trace context set in request handlers isn't visible when the HTTP request is made\n- **Multi-tenancy**: Tenant context set per-request isn't available to the transport\n\n### Why ContextVars?\n\nPython's `contextvars` module is the standard mechanism for request-scoped state:\n- Already widely used in async frameworks (FastAPI, Starlette, aiohttp)\n- Thread-safe and async-safe by design\n- Values can be set in middleware/handlers and should be available downstream\n- Zero coupling between application code and transport internals\n\n## Proposed Solution\n\nEnsure that context vars are properly propagated from the calling code to the transport layer at request time. This would allow:\n\n1. Custom `httpx.Auth` implementations to read context vars\n2. Any code in the transport layer to access current context\n\n### Example Use Case: Custom Auth\n\n```python\nfrom contextvars import ContextVar\nimport httpx\nfrom mcp.client.streamable_http import streamable_http_client\n\n# Application defines context var for auth\nauth_token_var: ContextVar[str] = ContextVar('auth_token')\n\n\nclass ContextVarAuth(httpx.Auth):\n    \"\"\"Auth that reads token from context var.\"\"\"\n    \n    def auth_flow(self, request):\n        try:\n            token = auth_token_var.get()\n            request.headers[\"Authorization\"] = f\"Bearer {token}\"\n        except LookupError:\n            pass  # No token set\n        yield request\n\n\n# Create client with custom auth\nclient = httpx.AsyncClient(auth=ContextVarAuth())\n\nasync with streamable_http_client(\n    \"https://mcp.example.com\",\n    http_client=client,\n) as (read, write, _):\n    async with ClientSession(read, write) as session:\n        await session.initialize()\n        \n        # Request 1: Set context for user A\n        auth_token_var.set(\"user-a-token\")\n        await session.call_tool(\"tool1\", arguments={})  # Auth reads \"user-a-token\"\n        \n        # Request 2: Set context for user B  \n        auth_token_var.set(\"user-b-token\")\n        await session.call_tool(\"tool2\", arguments={})  # Auth reads \"user-b-token\"\n```\n\n### Current Behavior (Broken)\n\nThe above example doesn't work today because when `auth_flow` is called, it runs in a different context where `auth_token_var` doesn't have the value set in the calling code.\n\n### Expected Behavior\n\nContext vars set before calling `session.call_tool()` should be visible in:\n- The transport's HTTP request code\n- Custom `httpx.Auth` implementations\n- Any callbacks or handlers in the transport layer\n\n## Implementation Notes\n\nThe fix likely requires copying the context at request time (not just at session creation) using `contextvars.copy_context()` and running transport code within that context.\n\n## Relationship to Explicit Transport Configuration\n\nThere is a separate proposal (#1966) for explicit per-request transport configuration. Both approaches serve different purposes: context vars enable implicit, zero-touch propagation from middleware/handlers without changing caller code, while explicit configuration provides direct control with clear data flow. Both features are valuable and complementary. Additionally, fixing context var propagation would prevent breaking existing code that relies on context vars being visible in downstream code.\n\n## Related Issues\n\n- https://github.com/modelcontextprotocol/python-sdk/issues/1966\n\n\n### References\n\n_No response_","author":{"url":"https://github.com/somaraani","@type":"Person","name":"somaraani"},"datePublished":"2026-01-28T19:17:59.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/1969/python-sdk/issues/1969"}