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
0.6.43
Ollama Version (if applicable)
No response
Operating System
Linux
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 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.
Supergateway is deployed via docker compose on a remote host, we use different clients from different hosts that need the same MCP Servers this is the docker configuration
The env file contains just the API keys for all the services TAM is using.
This configuration hasn't changed since always, works with commercial clients like Claude, has been tested successfully also with other open source tools like Librechat.
I feel like the request OWUI is sending is somehow malformed, i don't have access to the actual POST request, i am available to enable additional debugging if instructed how to do so.
Originally created by @AxelFooley on GitHub (Jan 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20500
### 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 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!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
0.6.43
### Ollama Version (if applicable)
_No response_
### Operating System
Linux
### 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 **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
I would like to use the [TAM MCP Server](https://github.com/gvaibhav/TAM-MCP-Server) with OWUI.
The same configuration works with other chatbots both commercial and open source.
### Actual Behavior
Every call made by OWUI fails with "400 Bad Request" even the connection check when configuring the MCP Server in the admin settings.
Logs server side are clean and it appears to replying to OWUI as expected.
### Steps to Reproduce
1. Perform a clean docker deploy of OWUI
2. Configure Supergateway on a remote host as described in the "Additional Information" section below
3. Verify that Supergateway is correctly running TAM MCP Server
4. Configure TAM as a Streamable HTTP Server in OWUI
5. Observe logs, you should find the 400 error and a toast notification in OWUI confirms that communication failed.
### Logs & Screenshots
OWUI Logs
```
open-webui-1 | 2026-01-08 14:42:54.236 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST http://10.0.120.198:8003/mcp "HTTP/1.1 200 OK"
open-webui-1 | 2026-01-08 14:42:54.236 | INFO | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25
open-webui-1 | 2026-01-08 14:42:54.241 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST http://10.0.120.198:8003/mcp "HTTP/1.1 400 Bad Request"
open-webui-1 | 2026-01-08 14:42:54.241 | ERROR | mcp.client.streamable_http:post_writer:574 - Error in post_writer
open-webui-1 | Traceback (most recent call last):
open-webui-1 |
open-webui-1 | File "<frozen runpy>", line 198, in _run_module_as_main
open-webui-1 | File "<frozen runpy>", line 88, in _run_code
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/uvicorn/__main__.py", line 4, in <module>
open-webui-1 | uvicorn.main()
open-webui-1 | │ └ <Command main>
open-webui-1 | └ <module 'uvicorn' from '/usr/local/lib/python3.11/site-packages/uvicorn/__init__.py'>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1485, in __call__
open-webui-1 | return self.main(*args, **kwargs)
open-webui-1 | │ │ │ └ {}
open-webui-1 | │ │ └ ()
open-webui-1 | │ └ <function Command.main at 0x7fe73c99f060>
open-webui-1 | └ <Command main>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1406, in main
open-webui-1 | rv = self.invoke(ctx)
open-webui-1 | │ │ └ <click.core.Context object at 0x7fe73d6d09d0>
open-webui-1 | │ └ <function Command.invoke at 0x7fe73c99ed40>
open-webui-1 | └ <Command main>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1269, in invoke
open-webui-1 | return ctx.invoke(self.callback, **ctx.params)
open-webui-1 | │ │ │ │ │ └ {'host': '0.0.0.0', 'port': 8080, 'forwarded_allow_ips': '*', 'workers': 1, 'app': 'open_webui.main:app', 'uds': None, 'fd': ...
open-webui-1 | │ │ │ │ └ <click.core.Context object at 0x7fe73d6d09d0>
open-webui-1 | │ │ │ └ <function main at 0x7fe73c79fe20>
open-webui-1 | │ │ └ <Command main>
open-webui-1 | │ └ <function Context.invoke at 0x7fe73c99df80>
open-webui-1 | └ <click.core.Context object at 0x7fe73d6d09d0>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/click/core.py", line 824, in invoke
open-webui-1 | return callback(*args, **kwargs)
open-webui-1 | │ │ └ {'host': '0.0.0.0', 'port': 8080, 'forwarded_allow_ips': '*', 'workers': 1, 'app': 'open_webui.main:app', 'uds': None, 'fd': ...
open-webui-1 | │ └ ()
open-webui-1 | └ <function main at 0x7fe73c79fe20>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 423, in main
open-webui-1 | run(
open-webui-1 | └ <function run at 0x7fe73c841bc0>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/uvicorn/main.py", line 593, in run
open-webui-1 | server.run()
open-webui-1 | │ └ <function Server.run at 0x7fe73c841440>
open-webui-1 | └ <uvicorn.server.Server object at 0x7fe73cd75650>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/uvicorn/server.py", line 67, in run
open-webui-1 | return asyncio_run(self.serve(sockets=sockets), loop_factory=self.config.get_loop_factory())
open-webui-1 | │ │ │ │ │ │ └ <function Config.get_loop_factory at 0x7fe73c9684a0>
open-webui-1 | │ │ │ │ │ └ <uvicorn.config.Config object at 0x7fe73d6d0e10>
open-webui-1 | │ │ │ │ └ <uvicorn.server.Server object at 0x7fe73cd75650>
open-webui-1 | │ │ │ └ None
open-webui-1 | │ │ └ <function Server.serve at 0x7fe73c8414e0>
open-webui-1 | │ └ <uvicorn.server.Server object at 0x7fe73cd75650>
open-webui-1 | └ <function asyncio_run at 0x7fe73c8413a0>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/uvicorn/_compat.py", line 23, in asyncio_run
open-webui-1 | return runner.run(main)
open-webui-1 | │ │ └ <coroutine object Server.serve at 0x7fe73c6ff3d0>
open-webui-1 | │ └ <function Runner.run at 0x7fe73cbecf40>
open-webui-1 | └ <asyncio.runners.Runner object at 0x7fe73c7bb750>
open-webui-1 | File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
open-webui-1 | return self._loop.run_until_complete(task)
open-webui-1 | │ │ │ └ <Task pending name='Task-1' coro=<Server.serve() running at /usr/local/lib/python3.11/site-packages/uvicorn/server.py:71> wai...
open-webui-1 | │ │ └ <cyfunction Loop.run_until_complete at 0x7fe73c7a6380>
open-webui-1 | │ └ <uvloop.Loop running=True closed=False debug=False>
open-webui-1 | └ <asyncio.runners.Runner object at 0x7fe73c7bb750>
open-webui-1 | > File "/usr/local/lib/python3.11/site-packages/mcp/client/streamable_http.py", line 571, in post_writer
open-webui-1 | await handle_request_async()
open-webui-1 | └ <function StreamableHTTPTransport.post_writer.<locals>.handle_request_async at 0x7fe634635f80>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/mcp/client/streamable_http.py", line 565, in handle_request_async
open-webui-1 | await self._handle_post_request(ctx)
open-webui-1 | │ │ └ RequestContext(client=<httpx.AsyncClient object at 0x7fe64ca14ad0>, session_id=None, session_message=SessionMessage(message=J...
open-webui-1 | │ └ <function StreamableHTTPTransport._handle_post_request at 0x7fe6503368e0>
open-webui-1 | └ <mcp.client.streamable_http.StreamableHTTPTransport object at 0x7fe64c944150>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/mcp/client/streamable_http.py", line 358, in _handle_post_request
open-webui-1 | response.raise_for_status()
open-webui-1 | │ └ <function Response.raise_for_status at 0x7fe6f284d260>
open-webui-1 | └ <Response [400 Bad Request]>
open-webui-1 | File "/usr/local/lib/python3.11/site-packages/httpx/_models.py", line 829, in raise_for_status
open-webui-1 | raise HTTPStatusError(message, request=request, response=self)
open-webui-1 | │ │ │ └ <Response [400 Bad Request]>
open-webui-1 | │ │ └ <Request('POST', 'http://10.0.120.198:8003/mcp')>
open-webui-1 | │ └ "Client error '400 Bad Request' for url 'http://10.0.120.198:8003/mcp'\nFor more information check: https://developer.mozilla...
open-webui-1 | └ <class 'httpx.HTTPStatusError'>
open-webui-1 |
open-webui-1 | httpx.HTTPStatusError: Client error '400 Bad Request' for url 'http://10.0.120.198:8003/mcp'
open-webui-1 | For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
```
Supergateway logs
```
sg-tam-market-research-1 | [supergateway] Tracking initialize request ID: 0
sg-tam-market-research-1 | [supergateway] Child stderr: info: Starting TAM MCP Server (STDIO transport)... {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.115Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ImfService: Constructor - API Configuration: {"available":true,"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.122Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: TAM MCP Server initialized {"capabilities":["tools","prompts","resources","logging","notifications"],"prompts":15,"rateLimit":{"requests":100,"window":60000},"resources":6,"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.126Z","tools":28,"version":"1.0.0"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: 🔍 API Availability Check: {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.126Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ AlphaVantage: API key configured {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.126Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ FRED: API key configured {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.127Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ BLS: API key configured {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.127Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ Census: API key configured {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.127Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ Nasdaq: API key configured {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.127Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ WorldBank: Public access (no key required) {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.128Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ OECD: Public access (no key required) {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.128Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: ✅ IMF: Public access (no key required) {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.128Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child stderr: info: 📊 Summary: 8/8 APIs available, 0 required APIs missing {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:04.128Z"}
sg-tam-market-research-1 |
sg-tam-market-research-1 | [supergateway] Child → StreamableHttp: {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{},"resources":{},"prompts":{},"logging":{},"notifications":{}},"serverInfo":{"name":"tam-mcp-server","version":"1.0.0","toolDefinitionPath":"./tools/tool-definitions.js"}},"jsonrpc":"2.0","id":0}
sg-tam-market-research-1 | [supergateway] Child → StreamableHttp: {"method":"notifications/message","params":{"level":"info","logger":"tam-mcp-server","data":"TAM MCP Server connected and ready! Notifications are enabled.","timestamp":"2026-01-08T13:54:05.130Z"},"jsonrpc":"2.0"}
sg-tam-market-research-1 | [supergateway] Child stderr: info: Welcome notification sent {"service":"tam-mcp-server","timestamp":"2026-01-08T13:54:05.131Z"}
```
### Additional Information
Supergateway is deployed via docker compose on a remote host, we use different clients from different hosts that need the same MCP Servers this is the docker configuration
```
sg-tam-market-research:
image: supercorp/supergateway
command: npx -y supergateway --stdio "npx -y @gvaibhav/tam-mcp-server" --port 8003 --outputTransport streamableHttp
ports:
- "8003:8003"
restart: unless-stopped
env_file: .env
```
The env file contains just the API keys for all the services TAM is using.
This configuration hasn't changed since always, works with commercial clients like Claude, has been tested successfully also with other open source tools like Librechat.
I feel like the request OWUI is sending is somehow malformed, i don't have access to the actual POST request, i am available to enable additional debugging if instructed how to do so.
GiteaMirror
added the bug label 2026-05-18 04:25:20 -05:00
@owui-terminator[bot] commented on GitHub (Jan 9, 2026):
🔍Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#14762issue: open-webui does not work with StreamableHttpTransport based MCP servers by alainivars • Jun 07, 2025 • bug
#19525issue: MCP Streamable HTTP incompatible with OpenMetadata MCP server due to missing Accept: application/json, text/event-stream header by aimendenche-nw • Nov 26, 2025 • bug
#19778issue: Streamable HTTP Notion MCP server doesn't stay enabled after authorizing by Sam-Horry • Dec 05, 2025 • bug
#18316issue: 0.6.33: When two or more Streamable(!) MCP servers are selected, the OpenWebUI-python3 process goes to 100% and stays there. by netmb • Oct 14, 2025 • bug
#17817issue: MCP tool calls are sent to wrong server when multiple streamable-http MCP servers are enabled, causing 'MCP error -32602: Tool not found' by eric2788 • Sep 27, 2025 • bug
Show 2 more related issues
#19813issue: Failed to connect to MCP server, while the connection test works fine by spi-dlp • Dec 08, 2025 • bug
#19901issue: New OAuth 2.1 Streamable HTTP MCP server Eetries do not propagate across multi-node setups by taylorwilsdon • Dec 12, 2025 • bug
💡Tips:
If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
If you found a solution in any of these issues, please share it here to help others
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
<!-- gh-comment-id:3727760214 -->
@owui-terminator[bot] commented on GitHub (Jan 9, 2026):
🔍 **Similar Issues Found**
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
1. [#14762](https://github.com/open-webui/open-webui/issues/14762) **issue: open-webui does not work with StreamableHttpTransport based MCP servers**
*by alainivars • Jun 07, 2025 • `bug`*
2. [#19525](https://github.com/open-webui/open-webui/issues/19525) **issue: MCP Streamable HTTP incompatible with OpenMetadata MCP server due to missing Accept: application/json, text/event-stream header**
*by aimendenche-nw • Nov 26, 2025 • `bug`*
3. [#19778](https://github.com/open-webui/open-webui/issues/19778) **issue: Streamable HTTP Notion MCP server doesn't stay enabled after authorizing**
*by Sam-Horry • Dec 05, 2025 • `bug`*
4. [#18316](https://github.com/open-webui/open-webui/issues/18316) **issue: 0.6.33: When two or more Streamable(!) MCP servers are selected, the OpenWebUI-python3 process goes to 100% and stays there.**
*by netmb • Oct 14, 2025 • `bug`*
5. [#17817](https://github.com/open-webui/open-webui/issues/17817) **issue: MCP tool calls are sent to wrong server when multiple streamable-http MCP servers are enabled, causing 'MCP error -32602: Tool not found'**
*by eric2788 • Sep 27, 2025 • `bug`*
<details>
<summary>Show 2 more related issues</summary>
6. [#19813](https://github.com/open-webui/open-webui/issues/19813) **issue: Failed to connect to MCP server, while the connection test works fine**
*by spi-dlp • Dec 08, 2025 • `bug`*
7. [#19901](https://github.com/open-webui/open-webui/issues/19901) **issue: New OAuth 2.1 Streamable HTTP MCP server Eetries do not propagate across multi-node setups**
*by taylorwilsdon • Dec 12, 2025 • `bug`*
</details>
---
💡 **Tips:**
- If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
- If you found a solution in any of these issues, please share it here to help others
*This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
<!-- gh-comment-id:3727990636 -->
@AxelFooley commented on GitHub (Jan 9, 2026):
Here you go
<img width="697" height="859" alt="Image" src="https://github.com/user-attachments/assets/9eb4e301-e871-47f8-bf8c-c506888157ef" />
@taylorwilsdon commented on GitHub (Jan 28, 2026):
Same issue, had a working setup and now it fails with no changes. Doesn't seem to produce any logs I can find either. Says it successfully registers but bombs out with verify connection. The 400 from /verify returns "detail: Failed to connect to the tool server"
<!-- gh-comment-id:3812410198 -->
@taylorwilsdon commented on GitHub (Jan 28, 2026):
Same issue, had a working setup and now it fails with no changes. Doesn't seem to produce any logs I can find either. Says it successfully registers but bombs out with verify connection. The 400 from /verify returns "detail: Failed to connect to the tool server"
<img width="491" height="255" alt="Image" src="https://github.com/user-attachments/assets/6c4d30e5-39e9-4eed-8f65-e1359004a8a6" />
<img width="413" height="85" alt="Image" src="https://github.com/user-attachments/assets/aa05c322-59ba-4011-b134-4bcf6ed1da36" />
<img width="721" height="158" alt="Image" src="https://github.com/user-attachments/assets/398bd9b4-2b71-47a1-8f00-9a75ced34ab3" />
This looks related - https://github.com/open-webui/open-webui/issues/20828
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @AxelFooley on GitHub (Jan 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20500
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.6.43
Ollama Version (if applicable)
No response
Operating System
Linux
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
I would like to use the TAM MCP Server with OWUI.
The same configuration works with other chatbots both commercial and open source.
Actual Behavior
Every call made by OWUI fails with "400 Bad Request" even the connection check when configuring the MCP Server in the admin settings.
Logs server side are clean and it appears to replying to OWUI as expected.
Steps to Reproduce
Logs & Screenshots
OWUI Logs
Supergateway logs
Additional Information
Supergateway is deployed via docker compose on a remote host, we use different clients from different hosts that need the same MCP Servers this is the docker configuration
The env file contains just the API keys for all the services TAM is using.
This configuration hasn't changed since always, works with commercial clients like Claude, has been tested successfully also with other open source tools like Librechat.
I feel like the request OWUI is sending is somehow malformed, i don't have access to the actual POST request, i am available to enable additional debugging if instructed how to do so.
@owui-terminator[bot] commented on GitHub (Jan 9, 2026):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#14762 issue: open-webui does not work with StreamableHttpTransport based MCP servers
by alainivars • Jun 07, 2025 •
bug#19525 issue: MCP Streamable HTTP incompatible with OpenMetadata MCP server due to missing Accept: application/json, text/event-stream header
by aimendenche-nw • Nov 26, 2025 •
bug#19778 issue: Streamable HTTP Notion MCP server doesn't stay enabled after authorizing
by Sam-Horry • Dec 05, 2025 •
bug#18316 issue: 0.6.33: When two or more Streamable(!) MCP servers are selected, the OpenWebUI-python3 process goes to 100% and stays there.
by netmb • Oct 14, 2025 •
bug#17817 issue: MCP tool calls are sent to wrong server when multiple streamable-http MCP servers are enabled, causing 'MCP error -32602: Tool not found'
by eric2788 • Sep 27, 2025 •
bugShow 2 more related issues
#19813 issue: Failed to connect to MCP server, while the connection test works fine
by spi-dlp • Dec 08, 2025 •
bug#19901 issue: New OAuth 2.1 Streamable HTTP MCP server Eetries do not propagate across multi-node setups
by taylorwilsdon • Dec 12, 2025 •
bug💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@Classic298 commented on GitHub (Jan 9, 2026):
screenshot from your configuration?
@AxelFooley commented on GitHub (Jan 9, 2026):
Here you go
@swvajanyatek commented on GitHub (Jan 20, 2026):
Same here
@taylorwilsdon commented on GitHub (Jan 28, 2026):
Same issue, had a working setup and now it fails with no changes. Doesn't seem to produce any logs I can find either. Says it successfully registers but bombs out with verify connection. The 400 from /verify returns "detail: Failed to connect to the tool server"
This looks related - https://github.com/open-webui/open-webui/issues/20828
@taylorwilsdon commented on GitHub (Jan 29, 2026):
@tjbck it is fixed in dev btw, looking forward to the release!
@Classic298 commented on GitHub (Jan 29, 2026):
great!