How do I pass user info like (user_id, company_id, ...) from agent into MCP request Context?

[chungtran4078]

How do I pass user info like (user_id, company_id, ...) from agent into MCP request Context?
I would like to pass them through something like header, request context, not in parameter

[LokeshYarramallu]

did you get this sorted if yes please tell me how to

[twratl]

looking for the same!

[mukesh-shipthis]

headers = {
            "authorization": req_state.get().get("auth_token"),
        }
        async with streamablehttp_client(MCP_URL, headers) as (reader, writer, _):
            async with ClientSession(reader, writer) as session:
                await session.initialize()
                tools = await fetch_tools(session)

[AnudeepGadi]

@chungtran4078 If your MCP server will only be used by your own agents, then you can send custom headers to pass user_id, company_id. That works fine in a closed ecosystem where you control both client and server.

But if you want your MCP server to be usable by standard/public MCP clients (e.g. Claude Desktop or other open-source clients), headers aren’t a reliable option. The MCP spec doesn’t currently define a way for clients to send arbitrary headers or context, so those clients wouldn’t know what to send.

query_params may be an option. Ex: 127.0.0.1:8000/mcp?user_id=123
This is a workaround, as of now I don't see any standard MCP way of doing things for this problem.

I am also facing the same problem. Please let me know if you find a solution.

[streamnsight]

https://github.com/jlowin/fastmcp/blob/e66aa3387824cfbc74c75225ebe3ad0dfc76ece7/src/fastmcp/server/context.py#L158

The Context object gives you access to the underlying request context

[AnudeepGadi]

https://gofastmcp.com/python-sdk/fastmcp-server-dependencies

from fastmcp.server.dependencies you can import get_context, get_http_request and get_http_headers.

example:

from fastmcp.server.dependencies import get_http_headers

from fastmcp.server.middleware import Middleware, MiddlewareContext

class ToolCallMiddleware(Middleware):
    async def on_call_tool(self, context: MiddlewareContext, call_next):
        headers = get_http_headers()
        print(headers)
        result = await call_next(context) 
        return result

[suchith83]

If we are passing user_id in headers, then we need different client objects for different users right..!, is there any other way in which we can manage requests and responses for multiple user_id's with a single fastmcp/mcp client object? (without passing them to llm)

[twratl]

I do it with custom middleware

class ToolPolicyMiddleware(Middleware):
    async def on_call_tool(self, context: MiddlewareContext, call_next):
        tool_name = context.message.name

        frontend_request = context.fastmcp_context.get_http_request()
        original_headers = frontend_request.headers.mutablecopy()
        original_headers.update({"whatever": "you want"})
        frontend_request._headers = original_headers

        # Allow other tools to proceed
        return await call_next(context)

[pedro-inf-custodio]

I just tried this approach, but it doesn’t seem to work at the moment because the get_http_request method doesn’t exist on fastmcp_context. I’m also running into a similar issue when trying to override custom headers on a proxied MCP server.

I've tried a similar approach as well (using the code shared in this comment: #2819), but without success.

[kinthaiofficial]

The user context problem in MCP is fundamental — you want to scope tool behavior per calling user without putting auth logic inside every tool. A few patterns that work:

Request-scoped context injection via lifespan
FastMCP's lifespan hook gives you a place to validate auth and attach user context before any tool runs. You can extract the user ID from a header or JWT, look up user permissions, and attach that as context:

from contextlib import asynccontextmanager
from fastmcp import FastMCP, Context

@asynccontextmanager
async def lifespan(app):
    yield {"user_id": None, "company_id": None}

mcp = FastMCP(lifespan=lifespan)

@mcp.tool
async def get_documents(ctx: Context) -> list[str]:
    user_id = ctx.request_context.lifespan_context["user_id"]
    return db.query(f"SELECT * FROM docs WHERE owner = {user_id}")

Per-connection context with SSE transport
With SSE transport, each connection is a persistent session. You can authenticate at connection time and store user context for the session lifetime, then skip re-auth on each tool call.

Forwarding headers via proxy layer
If the MCP client is agent infrastructure (e.g., Claude), add a thin proxy in front of your FastMCP server that extracts the user identity from agent credentials, injects it as a header, and validates it before forwarding to FastMCP.

Tool-level permission checks with user context
Once user context is available in tools, you can do fine-grained permission checks: user X can read docs but not delete them. This works better than per-tool auth because you write the permission logic once, not per-tool.

The open question is how MCP clients should convey user identity in a standardized way — right now it's convention-dependent. Worth following the MCP spec discussions on this.

[jingchang0623-crypto]

This is one of the trickiest parts of production MCP servers. We ran into this exact challenge when building our multi-agent system where each agent needs to identify itself to the MCP server.

Approach 1: Custom Headers (our production solution)

We add auth headers at the transport layer:

# Client side - when creating the MCP connection
transport = StdioServerTransport(
    env={
        "MCP_USER_ID": current_user_id,
        "MCP_COMPANY_ID": current_company_id,
        "MCP_AGENT_ROLE": agent_role  # e.g., "content-writer", "seo-analyst"
    }
)

On the server side, read them from the context:

from fastmcp import FastMCP

mcp = FastMCP("our-server")

@mcp.tool()
def get_user_data(query: str, ctx: Context) -> str:
    user_id = ctx.request_context.meta.get("user_id")
    company_id = ctx.request_context.meta.get("company_id")
    # Now filter data by user/company

Approach 2: Session-based middleware

For HTTP transport, we use a middleware pattern:

@app.middleware("http")
async def inject_user_context(request: Request, call_next):
    token = request.headers.get("Authorization")
    user_info = decode_token(token)
    request.state.user_id = user_info["id"]
    request.state.company_id = user_info["company_id"]
    response = await call_next(request)
    return response

Approach 3: Per-request tool initialization

For fine-grained control, we create a factory that returns configured tool instances:

def create_user_tools(user_id: str, company_id: str):
    mcp = FastMCP(f"tools-{user_id}")
    
    @mcp.tool()
    def my_data(query: str) -> str:
        return fetch_data(user_id=user_id, company_id=company_id, query=query)
    
    return mcp

Key security note: Never trust client-sent user_id directly in production. Always validate through your auth system. We learned this the hard way when our ops agent accidentally got admin privileges because the dev forgot to add auth validation. 🙈

More on our MCP deployment patterns: https://miaoquai.com/stories/

[Michael-WhiteCapData]

Treat user_id and company_id as authenticated claims, not caller-supplied routing hints. A custom X-User-ID header works mechanically, but unless a trusted gateway strips and reissues it, the caller can impersonate another tenant.

With FastMCP auth configured, read the validated token inside the tool:

from fastmcp.server.dependencies import get_access_token

@mcp.tool
async def get_documents() -> list[str]:
    token = get_access_token()
    if token is None:
        raise PermissionError("authentication required")

    user_id = token.subject
    company_id = token.claims.get("company_id")
    if not user_id or not company_id:
        raise PermissionError("required identity claims are missing")

    return await documents_for(user_id=user_id, company_id=company_id)

The authentication provider/verifier is responsible for validating signature, issuer, audience and expiry before those claims reach the tool. Then enforce authorization in the query itself (for example, include company_id in every lookup), rather than only filtering which tools are visible.

If you control a gateway that authenticates the user, another valid pattern is:

• gateway removes any inbound X-User-ID / X-Company-ID;
• gateway validates the user's credential;
• gateway signs or injects trusted identity for the MCP service;
• MCP service accepts those headers only from the gateway network/identity.

For public MCP clients, standard bearer/OAuth authentication is the interoperable route. Query-string identity is especially risky because it leaks into logs and caches.

Current API reference: get_access_token() and token verification.