issue: Unable to use global tool server while user tool server works properly

[theFra985]

Check Existing Issues

• I have searched for any existing and/or related issues.
• I have searched for any existing and/or related discussions.
• I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
• I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.9.2

Ollama Version (if applicable)

0.22.1 (unrelated)

Operating System

Arch linux

Browser (if applicable)

Tested in Chrome and Firefox

Confirmation

• I have read and followed all instructions in README.md.
• I am using the latest version of Open WebUI.
• 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

Maybe I am missing something but based on the MCP tools documentation page and the tools documentation page I would expect global tools to behave similarly to the user-defined tools. I expect tool server information to be visible when enabling a globally defined MCPO tool server.

Actual Behavior

When adding a MCPO tool server from Admin Panel > Settings > Integrations > Manage Tool Servers and activating it in the chat the tool appear as "available tool" but doesn't list any available function. When analyzing the request received by the model (using llama-swap as upstream, looking at it through the activity section) the request doesn't mention the tools from the tool server.

Adding the same exact tool server from Settings > Integrations > Manage Tool Servers leads the the expected result. Interacting with this configuration forwards the available tools to the model.

When enabling either configuration the MCPO endpoint /kubernetes/openapi.json is correctly called. The only difference is that the user-specific configuration also attempts to fetch /kubernetes/api/config from the server (resulting in a 404).
To perform this test the MCPO instance has been exposed both internally and externally with a valid SSL certificate. The global tool has been tested with both the internal HTTP address and the external HTTPS reverse-proxy address.

Steps to Reproduce

This has been tested on a clean openwebui install (still docker-compose based). I attempted to configure the global tool with both internal docker-compose networking and with external endpoints.

• Set-up a MCPO tool server
• Add MCPO tool server as global tool (exported as [{"type":"openapi","url":"https://mcpo-host-example/tool-name","spec_type":"url","spec":"","path":"openapi.json","auth_type":"bearer","key":"my-secret-bearer","info":{"id":"kubernetes","name":"Kubernetes","description":""}}])
• Open a new chat and enable the tool

Logs & Screenshots

Adding a global tool (docker-compose logs for both webui and webui-tools services

webui-1        | 2026-05-04 22:17:02.280 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/v1/configs/tool_servers HTTP/1.1" 200
webui-1        | 2026-05-04 22:17:02.329 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/v1/configs/terminal_servers HTTP/1.1" 200
webui-1        | 2026-05-04 22:17:25.709 | INFO     | open_webui.config:async_save:266 - Saving 'TOOL_SERVER_CONNECTIONS' to the database
webui-tools-1  | INFO:     172.18.0.5:55232 - "GET /kubernetes/openapi.json HTTP/1.1" 200 OK
webui-1        | 2026-05-04 22:17:25.717 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "POST /api/v1/configs/tool_servers HTTP/1.1" 200
webui-1        | 2026-05-04 22:17:27.481 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /_app/version.json HTTP/1.1" 304
webui-1        | 2026-05-04 22:17:27.798 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/v1/configs/banners HTTP/1.1" 200
webui-tools-1  | INFO:     172.18.0.5:55244 - "GET /kubernetes/openapi.json HTTP/1.1" 200 OK
webui-1        | 2026-05-04 22:17:27.812 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/v1/tools/ HTTP/1.1" 200
webui-1        | 2026-05-04 22:17:33.704 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/usage HTTP/1.1" 200
webui-1        | 2026-05-04 22:17:37.069 | INFO     | open_webui.routers.openai:get_all_models:496 - get_all_models()
webui-1        | 2026-05-04 22:17:37.070 | INFO     | open_webui.routers.ollama:get_all_models:329 - get_all_models()
webui-1        | 2026-05-04 22:17:37.084 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/models HTTP/1.1" 200

Adding user tool

webui-1        | 2026-05-04 22:24:00.101 | INFO     | open_webui.routers.openai:get_all_models:496 - get_all_models()
webui-1        | 2026-05-04 22:24:00.101 | INFO     | open_webui.routers.ollama:get_all_models:329 - get_all_models()
webui-1        | 2026-05-04 22:24:00.109 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/models HTTP/1.1" 200
webui-1        | 2026-05-04 22:24:00.118 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "POST /api/v1/users/user/settings/update HTTP/1.1" 200
webui-tools-1  | INFO:     192.168.2.135:47698 - "OPTIONS /kubernetes/openapi.json HTTP/1.1" 200 OK
webui-tools-1  | INFO:     192.168.2.135:47698 - "GET /kubernetes/openapi.json HTTP/1.1" 200 OK
webui-tools-1  | INFO:     192.168.2.135:47698 - "GET /kubernetes/api/config HTTP/1.1" 404 Not Found
webui-1        | 2026-05-04 22:24:02.315 | INFO     | open_webui.routers.openai:get_all_models:496 - get_all_models()
webui-1        | 2026-05-04 22:24:02.315 | INFO     | open_webui.routers.ollama:get_all_models:329 - get_all_models()
webui-1        | 2026-05-04 22:24:02.325 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "GET /api/models HTTP/1.1" 200
webui-1        | 2026-05-04 22:24:02.335 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.2.157:0 - "POST /api/v1/users/user/settings/update HTTP/1.1" 200
webui-tools-1  | INFO:     192.168.2.135:47698 - "GET /kubernetes/openapi.json HTTP/1.1" 200 OK
webui-tools-1  | INFO:     192.168.2.135:47698 - "GET /kubernetes/api/config HTTP/1.1" 404 Not Found

The browser requests are the one listed by the logs without any noteworthy behavior.

Additional Information

The user being used as test has the admin role. I tried checking the implementation of the tool loading in this repository to see if there was some additional permission check I was messing up but I confirmed the admin user bypasses such checks.
The /api/v1/tools/ endpoint correctly returns the tool as active with

{
  "id": "server:kube",
  "user_id": "server:kube",
  "name": "Kubernetes",
  "meta": {
    "description": "",
    "manifest": {}
  },
  "access_grants": [],
  "updated_at": 1777933917,
  "created_at": 1777933917,
  "user": null
}

present in the array. Looking at backend/open_webui/routers/tools.py that seems the correct behavior.
Thank you for the support.

[owui-terminator[bot]]

🔍 Similar Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

1. #24330 issue: Uvicorn worker crash loop on chat completion when tool servers are unreachable causes CPU exhaustion and system unresponsiveness
   by zaakiy · bug

2. #24176 issue: Parameterized URLs auto-submit fires before MCP tool servers are loaded, sending request with no tool_servers
   by jimbo-p · bug

3. #23851 issue: Tool server OAuth token forwarding works in chat but not in scheduled tasks
   by R00T99 · bug

4. #23597 issue: Failed to parse tool server enum value integer
   by Omripresent · bug

5. #21600 issue: Previously Configured Tool Servers via UI Break When TOOL_SERVER_CONNECTIONS Is Introduced or Empty
   by BernhardtMilan · bug

---

💡 If this is a duplicate, consider closing it and adding details to the existing issue.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

[tjbck]

Global tool servers make requests from the backend, and the direct user tool servers from the browser. We'd suggest you check your network config.

[theFra985]

curling from the openwebui container works properly and "checking" the tool status with the test button leads to a successful result (and the mcpo server logs the request). This can be seen demonstrated by the logs attached when saving the configuration, where the mcpo server gets contacted successfully, fulfilling the request. The issue seems to be related to how it's then handled in openwebui as it shows the tool without any additional information. It really looked like a permission issue but even setting the tool server as public or giving the user explicit permissions doesn't change the behavior. If there are any additional information or checks I can do I can provide more diagnostics. Thank you for your time!

[musaabhasan]

The backend-vs-browser distinction is likely the key here. A user tool server can work from the browser while a global tool server fails because the global request is made from inside the Open WebUI backend container/network namespace.

I would verify it from the backend container rather than from the host browser:

• docker exec into the Open WebUI container and curl the exact global tool-server URL
• if the URL uses localhost or 127.0.0.1, replace it with the Docker service name, container name, host gateway, or host.docker.internal depending on how the tool server is deployed
• confirm the tool server binds to 0.0.0.0, not only loopback inside its own container
• check whether the backend container is on the same Docker network as the tool server
• if HTTPS is used, test certificate trust from inside the backend container
• compare backend logs for connection refused, DNS failure, timeout, or TLS verification failure; those point to different fixes

If the direct user server works but the global one does not, I would start by assuming network reachability from the backend is different, not that the tool protocol itself is failing.