Not able to set/forward headers in MCP server policy when using MCP server from REST API in APIM

Adding this as an answer too even though it's more of a workaround:

It looks like the ONLY header that it lets you forward currently is 'Ocp-Apim-Subscription-Key'. So what I did is on my MCP server policy I take my auth header and put it into that key header, and then in my rest API policy I take that token and put it back into the auth header. In my actual policies I have it doing a token exchange in an OBO flow but below is a simplified version for just passing it straightup to the backend.

Frontend MCP server policy (in the inbound section):

		<set-header name="Ocp-Apim-Subscription-Key" exists-action="override">
			<value>@((string)context.Request.Headers.GetValueOrDefault("Authorization",""))
)</value>
		</set-header>

API policy at the 'all operations' level (also in the inbound section):

<set-header name="Authorization" exists-action="override">
            <value>@((string)context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key",""))</value>
        </set-header>

Hope this helps you or whoever else runs into this!

@Patrice Ferrot

we are sorry that the previous response could'nt help you. please find out below to to set headers in the MCP server policy so they are available in the API policy when using the Expose REST API as an MCP server feature

Ensure that the Authorization header (or any other headers) is forwarded from the MCP server to the backend API, you need to configure the Outbound Policy in the MCP server. Below is the correct approach to configure the MCP outbound policy:

Step 1: Add the set-header Policy in MCP Outbound

The set-header policy in the Outbound section of the MCP server ensures that headers are passed to the backend API. Here's an example:

xml

Copy snippet

XML

<policies><outbound><set-header name="Authorization" exists-action="override"><value>@(context.Request.Headers.GetValueOrDefault("Authorization", ""))</value></set-header></outbound></policies>

• Explanation:
  • context.Request.Headers.GetValueOrDefault("Authorization", ""): Retrieves the Authorization header from the incoming request to the MCP server.
    • exists-action="override": Ensures the header is set even if it already exists.

Step 2: Test with Hardcoded Headers

To confirm that the outbound policy is working, try setting a hardcoded header:

xml

Copy snippet

XML

<policies><outbound><set-header name="X-Test-Header" exists-action="override"><value>TestValue</value></set-header></outbound></policies>

• Make a request to the MCP server and check if the X-Test-Header is available in the backend API.

Step 3: Debug Header Forwarding

Use the Trace feature in Azure API Management to debug the outbound headers:

1. Enable Tracing in your API Management instance.
2. Make a request to the MCP server.
3. Inspect the trace logs to confirm whether the Authorization header is being forwarded.

Step 4: Ensure No Conflicting Policies

Check for any policies in the MCP server or backend API that might be removing or altering headers:

• Look for remove-header policies that may be stripping headers.
• Ensure the backend API is not rejecting headers due to security or configuration settings.

Step 5: Validate Backend API Configuration

Ensure the backend API is configured to accept headers forwarded from the MCP server. Some backend APIs may require explicit configuration to handle custom headers.

Step 6: Use Context Variables for Debugging

If the issue persists, use context variables to inspect the request and response headers:

xml

Copy snippet

XML

<log-to-eventhub><message>@(context.Request.Headers)</message></log-to-eventhub>

This will help you confirm whether the Authorization header is present in the outbound request.

Step 7: Special Considerations for Authorization Header

The Authorization header is treated specially by Azure API Management:

• If the validate-jwt policy is applied in the MCP server or backend API, ensure the token matches the expected configuration (issuer, audience, etc.).
• If the backend API also has a validate-jwt policy, ensure it is not rejecting the forwarded token.

Final Notes

If headers are still not being forwarded, consider:

• Using a custom header name instead of Authorization (e.g., X-Custom-Auth) to test if the issue is specific to the Authorization header.
• Checking the backend API

I hope this helps in resolving the issue, do let me know if you have any further questions on this