Skip to content

[Feature]: Support dynamic per-request headers for remote MCP servers #65776

Description

@jianxinxie

Summary

Support dynamic per-request headers for remote MCP servers so each outbound MCP request can include runtime-specific authorization and routing headers.

Problem to solve

Current MCP header configuration is effectively static at the server config level.

That works for:

one fixed bearer token
one fixed backend
one fixed tenant

But it does not work well for:

multi-tenant routing
per-user access tokens
short-lived / refreshed bearer tokens
session-specific auth
request-specific metadata such as x-tenant-id, x-org-id, or correlation headers

There is already an issue about static custom MCP headers not being applied correctly in some cases, but that is still different from supporting dynamic headers generated at request time.

Proposed solution

Suggested solution

It would be helpful if OpenClaw supported one of the following:

A hook to resolve headers before each MCP request
A runtime headersProvider for MCP transport
Templated headers that can use session/runtime context
Expected behavior

Before sending each MCP HTTP request, OpenClaw should be able to:

inspect current session/runtime context
generate dynamic headers
merge them with static headers
send the final headers to the remote MCP server
Why this matters

Without this, users often need to add an extra proxy layer only to inject auth headers dynamically.

Alternatives considered

No response

Impact

Impact

Affected users / systems / channels
This affects OpenClaw users who connect to remote MCP servers over HTTP / streamable-http, especially in multi-tenant setups, channel/plugin integrations, and systems using per-user, per-session, or short-lived bearer tokens.

Severity
For simple single-tenant setups, this is mostly annoying. For multi-tenant or dynamic-auth setups, it can block the workflow entirely because the correct auth or routing headers cannot be attached to each request.

Frequency
This happens consistently wherever per-request auth or tenant-specific headers are required. It is not an edge case for production multi-tenant MCP usage.

Practical consequences
Without dynamic per-request headers, users may hit 401/403 errors, route requests to the wrong backend or tenant, maintain separate MCP server configs per tenant, or build a custom proxy just to inject headers. This adds extra manual work, delays integration, and increases operational complexity.

Evidence/examples

No response

Additional information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.enhancementNew feature or requestimpact:auth-providerAuth, provider routing, model choice, or SecretRef resolution may break.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.issue-rating: 🌊 off-meta tidepoolIssue quality rating does not apply to this item.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions