[GH-ISSUE #17768] issue: MCP feature doesn't support multi-tenant use case #18392

New Issue

GiteaMirror · 2026-04-20T00:36:45-05:00

GiteaMirror commented

2026-04-20 00:36:45 -05:00

Originally created by @hsuyuming on GitHub (Sep 26, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17768

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.

Installation Method

Pip Install

Open WebUI Version

v0.6.31

Ollama Version (if applicable)

No response

Operating System

Debian 12

Browser (if applicable)

Chrome 140.0.7339.133

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Metadata discovery logic should follow the MCP spec documentation for multi-tenant usecase.
https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-metadata-discovery

Find metadata url from WWW-Authenticate response header
https:///.well-known/oauth-protected-resource//mcp

FYI: Our secured remote mcp server can work well when using mcp inspector and mcp-remote npm package

Actual Behavior

Hi:
When I attempt to test the latest MCP feature released in version v0.6.31, I try to connect it to one of our secured remote MCP servers. However, during metadata discovery, it cannot locate the correct path. This issue arises because we are using an Apigee reverse proxy in a multi-tenant setup.

Our MCP URL : https:///<subpath(tenant)>/mcp
Currently, the mcp code logic ignores the subpath, so it attempts to send a request to https:///.well-known/oauth-authorization-server, which does not exist.

Error message:
{
"detail": "Failed to fetch OAuth 2.1 discovery document from [https:///.well-known/oauth-authorization-server"](https:///.well-known/oauth-authorization-server%

Steps to Reproduce

Step:

Create python virtual env:

uv venv --python=3.12.10

Active python env

source .venv/bin/activate

install open-webui

pip install open-webui

Setup env

export MCP_ENABLED=True

Launch

open-webui serve

Open browser -> Go to Admin -> settings -> external tools -> Add -> Click 'OpenAPI' in order to switch to MCP mode -> Provide below information
URL: https:///abehsu-mcp-test/mcp
Select OAuth 2.1, provide client_id c0657649-6f42-4103-b581-2d6592d63bb0
Click "Verify connection" -> Fail

Logs & Screenshots

Error from cmd:
2025-09-26 04:50:27.653 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 127.0.0.1:54310 - "POST /api/v1/configs/tool_servers/verify HTTP/1.1" 400

Error from browser:

{
    "detail": "Failed to fetch OAuth 2.1 discovery document from https://<apigee>/.well-known/oauth-authorization-server"
}

Additional Information

https://apigee/.well-known/oauth-protected-resource/abehsu-mcp-test/mcp exist

https:///.well-known/oauth-authorization-server/abehsu-mcp-test exist

Originally created by @hsuyuming on GitHub (Sep 26, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/17768 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Pip Install ### Open WebUI Version v0.6.31 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 12 ### Browser (if applicable) Chrome 140.0.7339.133 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Metadata discovery logic should follow the MCP spec documentation for multi-tenant usecase. https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-metadata-discovery 1. Find metadata url from WWW-Authenticate response header 2. https://<share server URL>/.well-known/oauth-protected-resource/<tenant>/mcp FYI: Our secured remote mcp server can work well when using mcp inspector and mcp-remote npm package ### Actual Behavior Hi: When I attempt to test the latest MCP feature released in version v0.6.31, I try to connect it to one of our secured remote MCP servers. However, during metadata discovery, it cannot locate the correct path. This issue arises because we are using an Apigee reverse proxy in a multi-tenant setup. <img width="1723" height="969" alt="Image" src="https://github.com/user-attachments/assets/887a1e3d-9fb3-4118-a3c7-2153f717448b" /> Our MCP URL : https://<Apigee>/<subpath(tenant)>/mcp Currently, the mcp code logic ignores the subpath, so it attempts to send a request to https://<Apigee>/.well-known/oauth-authorization-server, which does not exist. Error message: { "detail": "Failed to fetch OAuth 2.1 discovery document from [https://<Server>/.well-known/oauth-authorization-server"](https://<Server>/.well-known/oauth-authorization-server% ### Steps to Reproduce Step: - Create python virtual env: ```cmd uv venv --python=3.12.10 ``` - Active python env ```cmd source .venv/bin/activate ``` - install open-webui ```cmd pip install open-webui ``` - Setup env ```cmd export MCP_ENABLED=True ``` - Launch ```cmd open-webui serve ``` - Open browser -> Go to Admin -> settings -> external tools -> Add -> Click 'OpenAPI' in order to switch to MCP mode -> Provide below information URL: https://<apigee>/abehsu-mcp-test/mcp Select OAuth 2.1, provide client_id c0657649-6f42-4103-b581-2d6592d63bb0 Click "Verify connection" -> Fail ### Logs & Screenshots Error from cmd: 2025-09-26 04:50:27.653 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 127.0.0.1:54310 - "POST /api/v1/configs/tool_servers/verify HTTP/1.1" 400 Error from browser: ```text { "detail": "Failed to fetch OAuth 2.1 discovery document from https://<apigee>/.well-known/oauth-authorization-server" } ``` ### Additional Information https://apigee/.well-known/oauth-protected-resource/abehsu-mcp-test/mcp exist <img width="1070" height="463" alt="Image" src="https://github.com/user-attachments/assets/f2b75ccd-4598-4242-b3c7-66cad5c3727e" /> https://<apigee>/.well-known/oauth-authorization-server/abehsu-mcp-test exist <img width="1008" height="682" alt="Image" src="https://github.com/user-attachments/assets/14fb6bc1-4327-476a-9d8d-7c3e097e5840" />

GiteaMirror added the bug label 2026-04-20 00:36:45 -05:00

GiteaMirror closed this issue

2026-04-20 00:36:46 -05:00

GiteaMirror commented

2026-04-20 00:36:46 -05:00

@tjbck commented on GitHub (Sep 26, 2025):

should be addressed with 0431ad9cc4, testing wanted here.

@tjbck commented on GitHub (Sep 26, 2025): should be addressed with 0431ad9cc4cf1d5453d27e053ed54bc097017003, testing wanted here.

GiteaMirror commented

2026-04-20 00:36:47 -05:00

@hsuyuming commented on GitHub (Sep 27, 2025):

Thank you @tjbck , Let me test it next week!

@hsuyuming commented on GitHub (Sep 27, 2025): Thank you @tjbck , Let me test it next week!

GiteaMirror commented

2026-04-20 00:36:47 -05:00

@logan-hcg commented on GitHub (Nov 17, 2025):

@tjbck it looks like the order of the metadata lookup is reversed. Based on https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-metadata-discovery, it should check the "tenant" metadata. It doesn't say anything about falling back to the "non-tenant" discovery locations, but I think that is reasonable.

Edit: opened a PR: https://github.com/open-webui/open-webui/pull/19244

@logan-hcg commented on GitHub (Nov 17, 2025): @tjbck it looks like the order of the metadata lookup is reversed. Based on https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-metadata-discovery, it should check the "tenant" metadata. It doesn't say anything about falling back to the "non-tenant" discovery locations, but I think that is reasonable. <img width="742" height="608" alt="Image" src="https://github.com/user-attachments/assets/f3acf835-5aee-485e-a4a2-1446a7f47ae4" /> Edit: opened a PR: https://github.com/open-webui/open-webui/pull/19244

GiteaMirror commented

2026-04-20 00:36:47 -05:00

@xqqp commented on GitHub (Nov 18, 2025):

Find metadata url from WWW-Authenticate response header

This part of the metadata discovery is not implemented yet. I think the issue should be reopened.

@xqqp commented on GitHub (Nov 18, 2025): > 1. Find metadata url from WWW-Authenticate response header This part of the metadata discovery is not implemented yet. I think the issue should be reopened.

GiteaMirror referenced this issue

2026-04-20 00:48:04 -05:00

[GH-ISSUE #18392] feat: Model-Specific Tool Restrictions #18583

GiteaMirror referenced this issue

2026-04-20 01:13:31 -05:00

[GH-ISSUE #19585] feat: Per-model accent color/theme for visual differentiation #18933

GiteaMirror referenced this issue

2026-04-25 08:02:32 -05:00

[GH-ISSUE #18392] feat: Model-Specific Tool Restrictions #34112

GiteaMirror referenced this issue

2026-04-25 08:28:03 -05:00

[GH-ISSUE #19585] feat: Per-model accent color/theme for visual differentiation #34462