Skip to main content
Use 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

  1. Run the example MCP server:
server.py
  1. Run the example client:
  1. You can check the logs of your MCP server to see the headers that were sent.

Multiple servers

Pass the same provider to each MCPTools instance: