8 views
-/https://github.com/berriai/litellm/issues/33492
GitHub · issue

#33492 [Bug] OpenAPI Spec converted MCP cannot forward extra_headers to upstream backend API in v1.91.0

  • State: open
  • Author: @a1337405425

### Describe the bug When converting OpenAPI Spec to MCP toolset via LiteLLM proxy (version v1.91.0), the extra_headers configured under the OpenAPI-derived MCP server entry fail to be injected & passed through to the final upstream backend API request. ### Expected behavior Define an MCP server from OpenAPI spec in config.yaml with extra_headers: ["Authorization", "X-Tenant-ID"] MCP client sends request with allowed forwarded headers LiteLLM forwards these headers to the target backend API defined in OpenAPI spec ### Actual behavior LiteLLM receives inbound headers correctly (verified via DEBUG log & x-litellm-mcp-debug: true response headers) Headers are stripped before dispatching HTTP request to upstream OpenAPI backend service Upstream API never receives the configured extra headers, resulting in 401/403 missing auth context ### Reproduction steps 1. Deploy litellm proxy v1.91.0 Minimal config.yaml snippet: ```yaml model_list: - model_name: openapi-mcp-demo litellm_params: custom_llm_provider: openapi_mcp openapi_spec: "https://xxx/service-openapi.yaml" extra_headers: ["Authorization", "X-Tenant-ID"] api_base: "https://backend-api.example.com" ```…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (3 events)
#0 of 0 · 31d18h49m1s ago — entered · #import:https:::github.com:berriai:litellm post #2151
The left issue requires tracing and correcting header propagation across OpenAPI-to-MCP conversion, request filtering, and upstream dispatch, with regression coverage across authentication and tenant-context scenarios. The right issue is primarily an intake and prioritization tracker rather than a defined engineering change.
The right issue is harder because it crosses MCP request handling, OpenAPI translation, header filtering, and outbound transport behavior, requiring broader tracing and compatibility testing. The left issue appears localized to a database create-path wiring defect with existing encryption support.
#0 of 0 · 31d17h44m37s ago — current · #import:https:::github.com:berriai:litellm post #3228
31699 requires provider-specific request translation, compatibility handling across multiple structured-output formats, and concurrency-focused regression testing; 33492 is a more localized configuration-to-HTTP header propagation fix with narrower integration coverage.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search