header_provider to calculate HTTP headers when MCPTools connects and before each run.
The initial connection and tool discovery happen before a run exists. run_context, agent, and team can all be None on that first call. A protected MCP server therefore needs a credential that works during discovery. The example below uses one least-privileged service identity that is safe for every caller.
Dynamic headers are only relevant when using HTTP-based transports (
streamable-http or sse). The stdio transport does not support headers.The header_provider function
MCPTools calls the provider during initial connection and updates the headers before each run. Handle the initial call without relying on run-specific values.
The service token above is sent during discovery and every run. Give it only permissions shared by all callers. For per-user authorization, use run_context.user_id as a non-secret lookup key and resolve the credential from an external secrets store inside the provider. Reject missing or unauthorized user IDs. Do not place bearer tokens in RunContext.metadata; run metadata is serialized and can be persisted with the session.
The function is expected to return a dict of header name-value pairs.
The following parameters will be automatically injected into the function and can be useful to generate the headers:
You can read more about the
RunContext object and its fields in the RunContext reference.
Complete Example
- Run the example MCP server:
server.py
- Run the example client:
- You can check the logs of your MCP server to see the headers that were sent.
Multiple servers
Pass the same provider to eachMCPTools instance: