bug(api): MCP tool invoke drops OAuth Authorization when any custom header is set

api/core/tools/mcp_tool/tool.py の MCPTool.invoke_remote_mcp_tool から始め、ヘッダー処理を api/services/tools/mcp_tools_manage_service.py の _prepare_auth_headers と比較します。カスタム X-Tenant ヘッダーと保存済みの OAuth トークンを使ってユニットケースを再現し、呼び出しによってカスタムヘッダーが保持され、Authorization が含まれ、一覧表示が退行しないことを確認します。

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues and pull requests, including closed ones.
• I confirm that I am using English to submit this report.

Dify version

main (current)

Cloud or Self Hosted

Both

Problem

MCP tool listing and MCP tool invoke prepare Authorization differently.

• MCPToolManageService.list_provider_tools uses _prepare_auth_headers(), which always merges OAuth tokens into the request headers (custom headers + OAuth coexist).
• MCPTool.invoke_remote_mcp_tool gated token injection behind if not headers:. Any non-empty custom header map (for example X-Tenant: abc) skipped retrieve_tokens() entirely.

Falsifiable consequence:

1. Configure an MCP provider with at least one custom header and complete OAuth (tokens stored).
2. Refresh / list tools → succeeds (Authorization present via _prepare_auth_headers).
3. Invoke the same tool from Agent / Workflow → request goes out without Authorization, typically 401 from the MCP server, while listing still works.

This is an auth/header state asymmetry between list and invoke, not a UI issue.

Relevant code (before fix):

• api/services/tools/mcp_tools_manage_service.py → _prepare_auth_headers
• api/core/tools/mcp_tool/tool.py → invoke_remote_mcp_tool (if not headers: gate)

Steps to reproduce

Minimal unit repro (fails on main):

# decrypt_headers returns {"X-Tenant": "abc"}
# retrieve_tokens returns OAuthTokens(access_token="oauth-access-token", token_type="bearer", ...)
# invoke_remote_mcp_tool(...)
# MCPClientWithAuthRetry receives headers WITHOUT Authorization

Or manually:

1. Add MCP server with custom header X-Tenant=abc and OAuth credentials.
2. Click to fetch tools (list succeeds).
3. Call the tool from a workflow/agent → auth failure / 401.

Expected Behavior

Invoke must apply the same header merge as listing: custom headers kept, OAuth Authorization still attached when tokens exist.

Actual Behavior

Invoke drops OAuth whenever any custom header is present.

I am preparing a focused fix with regression tests and will open a PR linking this issue.