issue: Inconsistent Tool Server Verification (Admin vs. User) #4824

New Issue

2025-11-11T16:03:52-06:00

GiteaMirror commented

2025-11-11 16:03:52 -06:00

Originally created by @tth37 on GitHub (Apr 12, 2025).

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.2

Ollama Version (if applicable)

No response

Operating System

Docker environment

Browser (if applicable)

No response

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 listed steps to reproduce the bug in detail.

Problem

There is an inconsistency in how Open-WebUI verifies Tool Server URLs between the Admin Settings panel and the User Settings panel. Additionally, user-scope tool server metadata is not cached, leading to repeated requests.

Actual Behavior

Admin Settings: When adding/verifying a Tool Server in the Admin Settings panel, clicking the "Verify" button triggers a backend request to /api/v1/configs/tool_servers/verify
User Settings: When adding/verifying a Tool Server in User Settings panel, clicking the "Verify" button triggers a direct POST request from the user's browser to <tool_server_url>/openapi.json
Every time the Open-WebUI page is reloaded, requests are sent from the browser to fetch <tool_server_url>/openapi.json for each configured user-scope tool server. The metadata are not cached.

Critical Problems:

If the target Tool Server doesn't have permissive CORS headers, the browser will block the verification request.
If Open-WebUI is served over HTTPS, but the Tool Server is served over HTTP, browsers will also block the verification request.
The lack of caching for user-scope tool server metadata (openapi.json) means redundant requests are made on every page load.

Logs & Screenshots

User-scope OpenAPI Tool Server verification:

Verification fails:

Each time the page is reloaded:

Suggestion

Refactor the Tool Server verification logic in User Settings panel to proxy the request through the Open-WebUI backend, similar to how it's handled in the Admin Settings.
Implement caching for the fetched openapi.json metadata for user-scope tool servers. Maybe storing this within the $settings object (currently only openapi_tool_urls are stored)

Originally created by @tth37 on GitHub (Apr 12, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.2 ### Ollama Version (if applicable) _No response_ ### Operating System Docker environment ### Browser (if applicable) _No response_ ### 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 listed steps to reproduce the bug in detail. ### Problem There is an inconsistency in how Open-WebUI verifies Tool Server URLs between the Admin Settings panel and the User Settings panel. Additionally, user-scope tool server metadata is not cached, leading to repeated requests. ### Actual Behavior 1. **Admin Settings**: When adding/verifying a Tool Server in the Admin Settings panel, clicking the "Verify" button triggers a backend request to `/api/v1/configs/tool_servers/verify` 2. **User Settings**: When adding/verifying a Tool Server in **User Settings** panel, clicking the "Verify" button triggers a **direct POST request from the user's browser** to `<tool_server_url>/openapi.json` 3. Every time the Open-WebUI page is reloaded, requests are sent from the browser to fetch `<tool_server_url>/openapi.json` for **each** configured user-scope tool server. The metadata are not cached. **Critical Problems:** - If the target Tool Server doesn't have permissive CORS headers, the browser will block the verification request. - If Open-WebUI is served over HTTPS, but the Tool Server is served over HTTP, browsers will also block the verification request. - The lack of caching for user-scope tool server metadata (openapi.json) means redundant requests are made on every page load. ### Logs & Screenshots User-scope OpenAPI Tool Server verification: ![Image](https://github.com/user-attachments/assets/d7539140-d994-4a0c-9a4e-c2437e6a44cd) Verification fails: ![Image](https://github.com/user-attachments/assets/ff0e357d-2c55-4d01-9c43-203c21738a7e) Each time the page is reloaded: ![Image](https://github.com/user-attachments/assets/1c45d43d-40f4-4371-a4df-6fdfe5e33879) ### Suggestion 1. Refactor the Tool Server verification logic in User Settings panel to proxy the request through the Open-WebUI backend, similar to how it's handled in the Admin Settings. 2. Implement caching for the fetched `openapi.json` metadata for user-scope tool servers. Maybe storing this within the $settings object (currently only openapi_tool_urls are stored)

GiteaMirror added the bug label 2025-11-11 16:03:52 -06:00

GiteaMirror closed this issue

2025-11-11 16:03:52 -06:00

GiteaMirror commented

2025-11-11 16:03:53 -06:00

@tjbck commented on GitHub (Apr 12, 2025):

Intended behaviour. They're "direct" tool connections. One of the advantages of hosting tool servers is allowing users to connect their LLMs to their locally hosted tools.

https://docs.openwebui.com/openapi-servers/faq

@tjbck commented on GitHub (Apr 12, 2025): Intended behaviour. They're "direct" tool connections. One of the advantages of hosting tool servers is allowing users to connect their LLMs to their locally hosted tools. https://docs.openwebui.com/openapi-servers/faq

GiteaMirror referenced this issue

2026-04-19 20:22:36 -05:00

[GH-ISSUE #4824] Tool enabling in chat is not sticky. The toogle seems to reset itself. #13745

GiteaMirror referenced this issue

2026-04-25 03:41:58 -05:00

[GH-ISSUE #4824] Tool enabling in chat is not sticky. The toogle seems to reset itself. #29273

GiteaMirror referenced this issue

2026-05-05 13:29:47 -05:00

[GH-ISSUE #4824] Tool enabling in chat is not sticky. The toogle seems to reset itself. #52411

GiteaMirror referenced this issue

2026-05-13 00:42:46 -05:00

[GH-ISSUE #4824] Tool enabling in chat is not sticky. The toogle seems to reset itself. #68349