Is your feature request related to a problem? Please describe.
This minor change enables clients to specify extra headers that might be overridden by authentication. Several MCP servers - like Atlassian's Rovo - allow both API tokens and OAuth using the same Authorization header. The assumption is that if the Authorization header is specified then it is valid. They do not differentiate the headers used for API tokens (like x-api-key) and the results of OAuth.
This becomes an issue in MCP configuration files where I may want to specify an API Key through an environment variable, but if the variable isn't set I want to fall back to OAuth. Since there isn't a way to "turn off" the header, it will be sent with an invalid value.
This works mostly with the SDK. The initial call with an invalid Authorization header fails and triggers an OAuth flow. This results in a set of tokens, and those tokens get inserted in _commonHeaders(). The problem is that unlike several other places in the code, _commonHeaders places those derived header values before the configured headers.
const extraHeaders = normalizeHeaders(this._requestInit?.headers);
return new Headers({
...headers,
...extraHeaders
});
This means that once a header is defined (like mcp-remote --header) then OAuth doesn't overwrite it even if it went through the OAuth flow and has tokens defined.
Describe the solution you'd like
Changing the order of the insertion above to be extraHeaders first followed by headers (which is the order in several other places) resolves the issue and allows derived headers like Authorization to override specified headers.
Describe alternatives you've considered
I have not been able to think of other options. Obviously two MCP servers could be defined, but then they would need to be manually enabled/disabled. Otherwise the OAuth MCP configuration (no Authorization header defined) would always trigger OAuth.
Additional context
N/A
Is your feature request related to a problem? Please describe.
This minor change enables clients to specify extra headers that might be overridden by authentication. Several MCP servers - like Atlassian's Rovo - allow both API tokens and OAuth using the same Authorization header. The assumption is that if the Authorization header is specified then it is valid. They do not differentiate the headers used for API tokens (like x-api-key) and the results of OAuth.
This becomes an issue in MCP configuration files where I may want to specify an API Key through an environment variable, but if the variable isn't set I want to fall back to OAuth. Since there isn't a way to "turn off" the header, it will be sent with an invalid value.
This works mostly with the SDK. The initial call with an invalid Authorization header fails and triggers an OAuth flow. This results in a set of tokens, and those tokens get inserted in _commonHeaders(). The problem is that unlike several other places in the code, _commonHeaders places those derived header values before the configured headers.
This means that once a header is defined (like mcp-remote --header) then OAuth doesn't overwrite it even if it went through the OAuth flow and has tokens defined.
Describe the solution you'd like
Changing the order of the insertion above to be extraHeaders first followed by headers (which is the order in several other places) resolves the issue and allows derived headers like Authorization to override specified headers.
Describe alternatives you've considered
I have not been able to think of other options. Obviously two MCP servers could be defined, but then they would need to be manually enabled/disabled. Otherwise the OAuth MCP configuration (no Authorization header defined) would always trigger OAuth.
Additional context
N/A