Repository navigation
Document recommended pattern for role/identity propagation in MCP tool execution #1452
Description
The MCP C# SDK does not provide a built-in mechanism to propagate caller identity or role into MCP tool execution. Production servers like Azure Data API Builder implement a custom HTTP header convention (X-MS-API-ROLE) via IHttpContextAccessor.
The SDK documentation should describe the recommended approach for role-aware MCP servers, covering both HTTP and stdio transports.
Reacted by Copilot
Activity
halter73 commentedon Mar 22, 2026
The MCP C# SDK does flow the user identity and roles to the tool call handler without requiring you use the IHttpContextAccessor or even the HttpContext.
The user's ClaimsPrincipal (if Authenticated using SSE or the Streamable HTTP transports) should be flowed with each
JsonRpcMessage.Context.We should have a buch of tests that demonstrate easily injecting a
ClaimsPrincipalvia parameters to MCP server tool handlers. This working is also key to how we support the[Authorize]attribute via the filter API.axeldunkel commentedon Apr 4, 2026
There's an architectural alternative worth considering here: rather than propagating caller identity through the SDK layer on every individual MCP server, move authorization to a gateway that sits in front of all your MCP servers.
The challenge with the SDK-level approach (whether via IHttpContextAccessor, custom headers, or middleware) is that every MCP server must implement it independently. You end up with M authorization implementations across M servers — each with its own bugs, gaps, and inconsistencies.
A gateway approach (like what we built with ToolMesh) centralizes this: the gateway handles authentication, maps identities to fine-grained permissions via OpenFGA, and enforces policy before the call ever reaches the backend server. The MCP server itself stays stateless and identity-agnostic — it just executes tools. Consistent audit logging and credential injection come for free across all servers regardless of SDK or language.
This doesn't make SDK-level identity propagation unnecessary — you still need it for servers that need to pass identity downstream to a backend API. But for the authorization question (who is allowed to call which tools), a central control plane scales better than per-server enforcement.