OpenAPI tool forwards MCP transport auth headers to downstream APIs

[aaazzam]

Summary

When an MCP server is created with FastMCP.from_openapi() and served over Streamable HTTP, the get_http_headers() call in OpenAPITool.run() forwards the incoming MCP transport's Authorization header to the downstream API, overwriting the API key configured on the httpx client.

This means the downstream API receives the MCP client's auth token instead of the intended API key, causing auth failures (503/401/403).

Root cause

In fastmcp/server/providers/openapi/components.py lines 173-175:

mcp_headers = get_http_headers()
if mcp_headers:
    request.headers.update(mcp_headers)

get_http_headers() extracts headers from the current MCP HTTP request context and forwards them. The authorization header is not in the exclude_headers set in dependencies.py, and .update() overwrites any existing headers — including the Authorization header that was already set from the httpx client's configured headers.

Minimal reproduction

# server.py
import json, os, httpx
from fastmcp import FastMCP

# Any OpenAPI spec will do
spec = json.loads(open("openapi.json").read())

backend = FastMCP.from_openapi(
    openapi_spec=spec,
    client=httpx.AsyncClient(
        base_url="https://api.example.com",
        headers={"Authorization": f"Bearer {os.environ['MY_API_KEY']}"},
    ),
    name="My API",
)

backend.run(transport="streamable-http")

When a client connects over Streamable HTTP with its own auth header (e.g. Claude Code, or any MCP client authenticating with the server), that auth header gets forwarded to api.example.com, replacing MY_API_KEY.

This does not happen when:

• The server runs over stdio (no HTTP request context, get_http_headers() returns {})
• You call backend.call_tool() directly in-process without an MCP HTTP context

Suggested fix

Add "authorization" to the exclude_headers set in get_http_headers():

exclude_headers = {
    "host",
    "content-length",
    "content-type",
    "connection",
    "transfer-encoding",
    "upgrade",
    "te",
    "keep-alive",
    "expect",
    "accept",
    "authorization",  # <-- add this
    # ...
}

Or alternatively, don't forward MCP transport headers to OpenAPI downstream requests by default.

Environment

• fastmcp 3.0.0
• httpx 0.28.1
• Python 3.13

[marvin-context-protocol]

Found 2 possible duplicate issues:

1. get_http_headers() should exclude content-type to prevent HTTP 415 errors in OpenAPI tools #3097: get_http_headers() should exclude content-type to prevent HTTP 415 errors in OpenAPI tools
2. h11 Protocol Error ("Too little data for declared Content-Length") when FastMCP tool calls downstream service due to forwarded Content-Length header #586: h11 Protocol Error ("Too little data for declared Content-Length") when FastMCP tool calls downstream service due to forwarded Content-Length header

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

[jlowin]

/marvin can you fix this - probably just add to exclude list?

[marvin-context-protocol]

Claude finished @jlowin's task in 2m 12s —— View job • claude/issue-3260-20260221-0249 • Create PR ➔

---

Fixing auth header forwarding in OpenAPI tools

• Gather context and read relevant files
• Add "authorization" to the exclude headers set in get_http_headers()
• Add test for authorization header exclusion
• Run tests to verify the fix (501 passed)
• Commit and push changes

Added "authorization" to the exclude_headers set in get_http_headers() (src/fastmcp/server/dependencies.py:453). This prevents the MCP transport's auth credentials from being forwarded to downstream APIs (e.g. OpenAPI backends configured with their own API keys on the httpx client).

|

---

Marvin Context Protocol | Type /marvin to interact further

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[meldsza]

Hi @jlowin, there are cases where this behaviour is genuinely useful:
Example having a FastAPI app along with MCP server. The FastAPI server handles the auth while the MCP server just passes the token along from the client.
Is there any way to keep the existing behaviour?