OpenAPI tool servers — frontend sends empty tool_servers=[] so middleware never injects schemas

[antonioromero-pm]

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.8.3 (Docker, ghcr.io/open-webui/open-webui:main, built 2026-02-14)

Ollama Version (if applicable)

0.16.3

Operating System

Windows 11 + WSL2 Ubuntu 24.04

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.

Description

When OpenAPI-type tool servers are configured in Admin Panel > Settings > External Tools, the model never receives their schemas and cannot call any tools. The failure is completely silent — no error is shown to the user and the chat completes normally without tool use.

Expected Behavior

The tool_servers field in the request payload should contain the OpenAPI specs for all enabled tool servers, so that middleware.py can inject them as a tools array into the upstream model request.

Actual Behavior

The tool_servers field is always [] (empty array) even when tool servers are configured, verified, and toggled on.

The tool_ids field is correctly populated (e.g. ["server:1", "server:open-meteo", "server:3"]) but the middleware receives no specs to work with.

Steps to Reproduce

1. Deploy any OpenAPI-compatible tool server (e.g. MCPO bridging MCP servers to OpenAPI)
2. In Admin Panel > Settings > External Tools, add a connection:
   • Type: OpenAPI
   • URL: pointing to your tool server
3. Verify the connection succeeds (green tick / "Connection successful")
4. In Workspace > Models, enable the tool server for a model
5. Open a new chat with that model, confirm the tool toggle is ON via the ➕ icon
6. Send a message that should trigger a tool (e.g. "What is the weather in New York?")
7. Inspect the /api/chat/completions request in browser DevTools > Network tab

Logs & Screenshots

Request payload from DevTools:

{
  "model": "my-model",
  "messages": [{"role": "user", "content": "What is the weather in New York?"}],
  "tool_ids": ["server:1", "server:open-meteo", "server:3"],
  "tool_servers": [],
  ...
}

---

Logs

Backend log during the request:

INFO | uvicorn... - "POST /api/chat/completions HTTP/1.1" 200

No tool-related log lines appear. By contrast, MCP-type tool servers (with server:mcp:* prefixed IDs) work correctly because their execution path is fully server-side.

---

Additional Information

#21770 is directly related -- the other half of the same fix.

Root Cause Analysis (traced through source)

middleware.py line 2274 reads tool server specs from the frontend request:

direct_tool_servers = metadata.get("tool_servers", None)

Line 2441 skips the entire tool injection block if this is falsy:

if direct_tool_servers:
    for tool_server in direct_tool_servers:
        ...

An empty list [] is falsy, so no tools are ever injected.

The backend does have a populated cache: app.state.TOOL_SERVERS is correctly built at startup by main.py:

await set_tool_servers(mock_request)
log.info(f"Initialized {len(app.state.TOOL_SERVERS)} tool server(s)")

However, app.state.TOOL_SERVERS (and get_tool_servers()) is never referenced in middleware.py:

$ grep -n "TOOL_SERVERS\|get_tool_servers" /app/backend/open_webui/utils/middleware.py
(no output)

The middleware relies entirely on the frontend to embed specs in the request, but the frontend never does so for admin-configured OpenAPI tool servers.

---

Suggested Fix

After line 2274 in middleware.py, add a fallback to the server-side cache when the frontend sends an empty array:

direct_tool_servers = metadata.get("tool_servers", None)

# Fallback: frontend sends tool_servers=[] for admin-configured OpenAPI servers.
# Resolve from server-side cache when tool_ids contains "server:*" entries.
if not direct_tool_servers and tool_ids:
    openapi_tool_ids = [
        tid for tid in tool_ids
        if tid.startswith("server:") and not tid.startswith("server:mcp:")
    ]
    if openapi_tool_ids:
        all_tool_servers = await get_tool_servers(request)
        direct_tool_servers = [
            s for s in all_tool_servers
            if f"server:{s['id']}" in openapi_tool_ids
            or f"server:{s['idx'] + 1}" in openapi_tool_ids
        ]

Note: get_tool_servers is already importable from open_webui.utils.tools — it just needs to be added to the import at the top of middleware.py.

The tool_ids matching needs to check both server:{id} (string name) and server:{idx+1} (1-based numeric position) because the frontend generates IDs inconsistently — some servers get their configured string ID, others get a positional integer.

---

Additional Notes

• MCP-type tool servers (server:mcp:* IDs) are unaffected — they are handled server-side and work correctly
• The USER_PERMISSIONS_FEATURES_DIRECT_TOOL_SERVERS config suggests frontend-embedded specs are intended as a user-facing "direct tool servers" feature — admin-configured OpenAPI servers appear to share this broken path unintentionally
• A second related bug (tool execution delegated to frontend) is filed separately

[antonioromero-pm]

Updated the description after further analysis and arriving at a fix that works in my environment. Will submit a second related issue, both of which must be fixed to get this working.

[tjbck]

Admin level connections do NOT require tool_servers in the payload.

[stefan07f]

Confirming this on a separate setup with a full root-cause trace through the current main source — this isn't specific to any particular tool server implementation, it's a structural gap between the Admin panel and the chat UI for OpenAPI-type tool servers.

Environment

• ghcr.io/open-webui/open-webui:main, pulled 2026-07
• MCP_ENABLE=true
• Tool server: a custom OpenAPI proxy (Proxmox API), type OpenAPI, no auth, added under Admin → Settings → Integrations → Tool Servers
• openapi.json is valid (3.1.0), fully reachable from the container (docker exec open-webui curl http://host.docker.internal:8000/proxmox/openapi.json returns the full spec), every operation has an explicit operationId

Symptom

Server saves successfully, spec loads successfully, but no tools ever appear in the chat "+" menu or in tool_servers=[] on the outgoing /api/chat/completions request — matching the title of this discussion exactly.

Root cause (traced in main, today's pull)

There are two separate, unconnected config stores for OpenAPI tool servers.

Admin panel (src/lib/components/admin/Settings/Integrations.svelte:62) writes to config key TOOL_SERVER_CONNECTIONS (backend: Config.get('tool_server.connections', [])).

Chat UI's tool store is populated exclusively from the per-user settings object, not the admin config, in src/routes/(app)/+layout.svelte:125-138:

const setToolServers = async () => {
  let toolServersData = await getToolServersData($settings?.toolServers ?? []);
  toolServersData = toolServersData.filter(...);
  toolServers.set(toolServersData);
};

$settings here is the logged-in user's personal settings store — completely separate from the admin TOOL_SERVER_CONNECTIONS config.

The actual chat request only ever includes tool servers the user explicitly toggled on, filtered from that same $toolServers store — src/lib/components/chat/Chat.svelte:2521-2572 (direct_server: prefixed toolServerIds, filtered against $toolServers).

Backend takes this list as-is with no fallback to the server-side app.state.TOOL_SERVERS cache that's populated from the admin config — backend/open_webui/utils/middleware.py:2610 (direct_tool_servers = metadata.get('tool_servers', None)) and :2715 (if direct_tool_servers: ...). If empty, the block is simply skipped — no error, only a log.debug line that isn't visible at default log levels.

The only admin-config-driven path that does work end-to-end server-side is for type: mcp entries, via tool_id.startswith('server:mcp:') → connect_mcp_server() (middleware.py:2622), which does read Config.get('tool_server.connections', []). There is no equivalent server:openapi:-style path for type: openapi entries — they're structurally orphaned once added only at the admin level.

Net effect: admin-level OpenAPI-type tool servers are saved and even fetched/cached server-side (app.state.TOOL_SERVERS), but never surfaced to the chat UI or the outgoing request. Only tool servers added under the user's personal Settings → Tools actually work, because that's the only source setToolServers() reads from.

Workaround: re-add the same OpenAPI tool server under the individual user's own Settings → Tools (not the Admin panel). It then appears in the "+" menu and gets embedded in tool_servers once toggled on.

Suggested fix direction: either (a) merge admin-global, publicly-enabled TOOL_SERVER_CONNECTIONS entries into $toolServers in setToolServers() alongside the personal ones, or (b) give type: openapi admin connections a server-side resolution path analogous to server:mcp: in middleware.py, so they don't depend on the frontend embedding specs at all.

Happy to open this as a standalone bug report with a minimal repro if that's more useful than a comment here.

[stefan07f]

Follow-up with harder evidence — this also affects personal-settings ("direct") OpenAPI tool servers once more than one is configured, not just admin-global ones.

Setup: Two personal OpenAPI tool servers configured under Settings → Tools: "Home Assistant" (MCP type, unrelated) and "mcp-pve" (OpenAPI type, exposes tool_pve_list_nodes_post etc.). Both confirmed independently working when the only one enabled (spec loads, shows up in the "Available Tools" panel).

Test method: Patched window.fetch in the browser console to capture the exact JSON body sent to /api/chat/completions, then toggled tool servers via the "+" tool picker and sent the same prompt ("Welche Proxmox-Nodes gibt es? Nutze das passende Tool.") repeatedly.

Finding 1 — tool_servers silently empties out with 2 servers active:

With both "Home Assistant" and "mcp-pve" toggled ON:

{"hasTools": false, "tool_servers": 0, "model": "qwen3:8b"}

Model response: "nicht in der Liste der verfügbaren Tools enthalten" (not in the list of available tools) — despite both showing as enabled in the UI.

Finding 2 — with exactly 1 server active, the wrong server's tools are sent:

Toggled "Home Assistant" OFF and "mcp-pve" ON (verified via the UI — only mcp-pve's toggle was green), same prompt:

{"hasTools": false, "tool_servers": 1, "model": "qwen3:8b"}

tool_servers correctly has length 1 this time — but the model's response describes tools for notes, tasks, automations, and calendar events (i.e. the Home Assistant server's functions), not Proxmox:

"Die vorhandenen Tools decken Funktionen wie Notizen, Aufgaben, Automatisierungen und Kalenderereignisse ab, aber keine spezifischen Proxmox-Node-Informationen."

So the single entry that did make it into tool_servers was the wrong one — not the one currently toggled on in the UI.

Root cause hypothesis (from src/lib/components/chat/Chat.svelte, the tool_servers construction):

for (const toolId of selectedToolIds) {
  if (toolId.startsWith('direct_server:')) {
    let serverId = toolId.replace('direct_server:', '');
    if (!isNaN(parseInt(serverId))) { toolServerIds.push(parseInt(serverId)); }
    else { toolServerIds.push(serverId); }
  } else { toolIds.push(toolId); }
}
...
tool_servers: [
  ...($toolServers ?? []).filter((server, idx) =>
     toolServerIds.includes(idx) || toolServerIds.includes(server?.id))
]

This filters $toolServers by matching against either the array index (idx) or a server.id field. When a server has no stable id (e.g. an OpenAPI-type personal connection added without an explicit ID), the fallback to positional idx matching means toggling servers on/off — which doesn't change their position in $toolServers, but does change what's in toolServerIds — can select the wrong array slot, or (with 2+ direct servers combined with whatever produces Finding 1) drop the selection to [] entirely. Using a stable identifier consistently (never falling back to positional index) would fix both symptoms.

Independently confirmed the model itself is not at fault: called tool_pve_list_nodes_post correctly on the first attempt when the same tool definition was passed directly to Ollama's /api/chat API, bypassing Open WebUI entirely.

Happy to provide the full captured request/response pairs or a minimal two-tool-server repro config if useful.

[Z-Rick84]

Confirming this — hit the exact same issue (admin-configured OpenAPI tool server, config.enable: true, correctly persisted in tool_server.connections, survives a restart, but never shows up in a model's tools list or the per-chat + menu, and never makes it into the tools array of an actual chat completion request — verified via the backend LLM proxy logs, request payload contained only the built-in functions, zero external ones).

Traced it to the same root cause described above: middleware.py only reads metadata.get('tool_servers') (frontend-supplied, empty in practice) and has no fallback to the admin-level config when it's empty:

tool_ids = metadata.get('tool_ids', None)
direct_tool_servers = metadata.get('tool_servers', None)
...
if tool_ids:   # entire block skipped when both are empty
    ...

Worth noting: the existing tool_ids path with the server:<id> prefix (used for admin-configured OpenAPI servers when explicitly selected) is already fully functional server-side — correct auth header construction via build_tool_server_headers(), correct dispatch via execute_tool_server(). It's just never populated automatically. Also confirmed the server:mcp:... prefix (MCP tool servers) is not affected by this — it has its own working resolution path via connect_mcp_server().

Applied a minimal fallback right after those two metadata.get() calls: if both tool_ids and direct_tool_servers are empty, populate tool_ids with server:<id> for every OpenAPI connection in tool_server.connections where config.enable is true — i.e. exactly the entries a correctly-working frontend would already be sending. No existing code touched or removed.

Tested against a real self-hosted setup (0.11.0) with an external FastAPI-based tool server: before the patch, a chat request's tools array contained 34 built-in functions and zero from the registered server despite it being enabled; after, the model correctly invoked the external tool and returned real data from it.

Happy to open this as a proper PR with tests if that's useful — wanted to confirm the diagnosis and check preferred direction first, since a "silently activate all enabled admin tool servers for every chat" default might not be the shape the maintainers want upstream (e.g. some installs may prefer this scoped per-model/per-chat rather than global-always-on). Full patch (applied via a small idempotent script against the running container, not a source-tree PR) here for reference: https://gist.github.com/Z-Rick84/8a07bd829eb44bcbd3ee9311f312fb8e