Why can't I add an MCP server myself as a regular user?

Open WebUI's docs treat MCP server registration as admin-only, unlike OpenAPI tool servers, which users can add themselves if the admin has granted the Direct Tool Servers permission. The reasoning given: an MCP server is stateful and capability-rich, so an admin adds it once and individual users then authenticate to it themselves.

My server connects but the model never calls its tools. Why?

Check the model's Function Calling mode first. Open WebUI's Native mode (also called Agentic mode) uses the model's own structured tool-calling output and is what current docs describe as the supported path; the older Legacy mode relies on prompt injection and is documented as unreliable for multi-step tool chains. If Native is already selected, the model itself may lack solid tool-calling support — that's a model problem, not a server problem.

My local MCP server works from the terminal but Open WebUI can't reach it. Why?

This is almost always Docker networking. If Open WebUI is running in a Docker container and the MCP server is on the host machine, `localhost` inside the container refers to the container itself, not your host. Use `http://host.docker.internal: ` instead.

How to Add a Remote MCP Server to Open WebUI

How do I add a remote MCP server to Open WebUI?

Open WebUI's native MCP support is admin-configured and Streamable HTTP only — there's no stdio or SSE option, because Open WebUI is a multi-tenant web app and can't hold long-lived stdio connections open per user. An admin goes to Admin Settings → Integrations → External Tool Servers, adds a new entry, sets the connection type to MCP (Streamable HTTP), and pastes the server URL. From there, each user who wants to use the server authenticates to it individually — Open WebUI supports no auth, bearer tokens, OAuth 2.1 with dynamic client registration, or OAuth 2.1 with a static pre-registered client.

Requirements

Open WebUI v0.6.31 or later — this is when native MCP (Streamable HTTP) support arrived
Admin access to the Open WebUI instance, since MCP server registration is an admin-only setting
The MCP server's URL, and to know which auth type it expects (none, bearer token, or OAuth 2.1)

Adding the server (admin)

Open Admin Settings → Integrations
Find External Tool Servers and add a new one
Set the connection type to MCP (Streamable HTTP) — a different type here will error
Paste the server's URL
Set the authentication type to match what the server expects: None, Bearer, OAuth 2.1, or OAuth 2.1 (Static) if the server needs a pre-registered client ID and secret rather than dynamic registration
Save

Authorization (each user)

For an OAuth-protected server, each user who wants to use it completes their own browser consent flow the first time they use it — the admin who added the server doesn't authorize on everyone's behalf. For a bearer-token server, whoever configured the key controls access instead, so treat that token with the same care as a password.

One documented caveat: don't set an OAuth 2.1 tool as a model's default tool. OAuth needs an interactive browser redirect, which isn't available mid-request if the tool fires automatically inside a chat that's already running. Enable OAuth tools per chat instead (see below), or use a bearer-token server if you want it always-on for a model.

Enabling the tool for a model or a chat

Once the server is registered, it still has to be turned on somewhere before a model will call it:

Always on for a model: go to Workspace → Models, edit the model, and in the Tools section check the servers you want that model to have by default.
Just for this chat: click the Integrations icon in the chat input area (the four-diamond icon next to the + button), then select Tools, and enable the server there.

Function calling mode

Open WebUI calls tools in one of two modes, and this setting decides whether tool calls work reliably at all:

Native mode (also called Agentic mode) uses the model's own structured tool-calling output. This is the documented, supported path.
Legacy mode relies on prompt injection instead of the model's native tool format. Open WebUI's own docs describe it as unreliable for multi-step tool chaining and note it breaks KV caching.

If tools aren't being called reliably, check the model's Function Calling setting first, before assuming the server is broken.

What else goes wrong

Wrong connection type. MCP servers must be added as type MCP (Streamable HTTP), not the OpenAPI tool-server type — using the wrong type is a documented source of errors.
Docker networking. If Open WebUI runs in a Docker container and the MCP server runs on your host machine, localhost inside the container points at the container, not your host. Use http://host.docker.internal:<port> instead.
OAuth set as a chat default. An OAuth 2.1 tool configured as a model default can't complete its browser redirect mid-chat. Enable it per chat via the Integrations icon instead.
Model has no reliable tool-calling. Confirm Function Calling is set to Native, and if calls still fail or come back malformed, the model itself may be the limiting factor rather than the server or the config.

What about local (stdio) MCP servers?

Open WebUI's native support is remote-only. For a server that only speaks stdio, Open WebUI's own project maintains mcpo, a separate proxy that wraps a stdio (or SSE) MCP server and exposes it as an OpenAPI-compatible HTTP endpoint, which Open WebUI can then add as a regular tool server. That's a different setup path than the one on this page, which covers servers that already speak MCP over Streamable HTTP directly.

A worked example

Tempreon is a hosted MCP server over Streamable HTTP, which is exactly the transport Open WebUI's native support expects — no proxy needed. An admin adds it once in Admin Settings → Integrations → External Tool Servers with connection type MCP (Streamable HTTP) and the URL:

https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

set to OAuth 2.1 authentication. Each person on that Open WebUI instance who wants their own memory then enables the Tempreon tool for their chat (or for a model they use regularly) and completes their own browser consent screen the first time. From then on, whatever model they're running — local via Ollama, or a hosted API — can load their identity and log what it learns, the same as any other client. Full setup notes, including the other open-source clients Tempreon connects to, are in the open-source clients guide.