Skip to content

Feature Request: Allow _execute_api_tool to source Authorization header from tool arguments for internal clients #143

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
stepolan opened this issue May 20, 2025 · 0 comments · May be fixed by #144

Comments

@stepolan
Copy link

stepolan commented May 20, 2025

Is your feature request related to a problem? Please describe.
Currently, when fastapi-mcp's _execute_api_tool method in server.py makes an internal HTTP request to execute a FastAPI tool endpoint, it primarily looks for an Authorization header within the http_request_info.headers that it receives. This works well for external MCP clients that pass the Authorization header directly.

However, in scenarios involving internal MCP clients (e.g., a backend service within the same application making a tool call via an MCPClientSession), the original end-user's authentication token might be more conveniently passed through the arguments of the call_tool request, rather than re-constructing HTTP headers for the internal call.

In our application, a service acts as an internal MCP client. It extracts the Bearer token from the initial HTTP request's Authorization header and includes it in the arguments dictionary (e.g., as user_access_token) when calling MCPClientSession.call_tool(). The current fastapi-mcp (version 0.3.3) does not automatically pick up this token from the arguments to authenticate the subsequent internal request to the tool's actual FastAPI endpoint, leading to authentication failures for the tool if it's protected.

Describe the solution you'd like
Enhance the _execute_api_tool method in fastapi_mcp/server.py to check the arguments dictionary for a specific token key (e.g., user_access_token) if an Authorization header is not already present in http_request_info.headers. If found, this token would be used to construct a Bearer token and set the Authorization header for the httpx.AsyncClient request made to the tool's endpoint.

Describe alternatives you've considered

  1. Manually patching fastapi_mcp/server.py: This is our current workaround but is not sustainable.
  2. Attempting to modify http_request_info before it reaches _execute_api_tool: This is complex and involves internal details of the mcp library.

Proposed Code Change (Illustrative):
This is the patch I have successfully used locally. It's added within the _execute_api_tool method in fastapi_mcp/server.py, just before the httpx.AsyncClient is used:

# ... existing code in _execute_api_tool ...

        if http_request_info and http_request_info.headers:
            if "Authorization" in http_request_info.headers:
                headers["Authorization"] = http_request_info.headers["Authorization"]
            elif "authorization" in http_request_info.headers:
                headers["Authorization"] = http_request_info.headers["authorization"]

        # NEW: Check arguments for a user_access_token if Authorization header is still missing
        if "Authorization" not in headers and arguments and "user_access_token" in arguments:
            token = arguments.pop("user_access_token", None) # Remove it from arguments so it doesn't become body
            if token:
                headers["Authorization"] = f"Bearer {token}"
                logger.debug("Set Authorization header from 'user_access_token' in tool arguments.")

# Existing code...

        body = arguments if arguments else None

        try:
            logger.debug(f"Making {method.upper()} request to {path}")
            response = await self._request(client, method, path, query, headers, body)

(Self-correction during drafting: Used .get() for safer dictionary access and added a type check for the token. Also considered whether to pop the token from arguments, deciding it's often better not to unless a name collision is likely.)

Additional context
This change would make fastapi-mcp more flexible for internal tool usage patterns where direct header manipulation by the immediate internal client is less convenient than passing auth details via arguments. It also maintains the priority of an explicitly passed Authorization header if present.

Thank you for considering this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant