Open WebUI MCP tool servers

The core difference is who approves a connection and who holds the credentials behind it. In Open WebUI, an MCP tool server is added by an administrator, so the connection is approved once for the instance and every user granted access inherits that decision. A user-added OpenAPI tool server is a personal connection. The user supplies the endpoint and any authentication it needs, and the tools are available to that user's own chats. Both models give a language model new actions to take, so for a shared company deployment the question is not only which tool runs but who authorized the endpoint, which credential it uses, and whose data flows through it. Confirm these behaviors in your release, because the settings that control them can change between versions.

Credential handling is where the two models diverge most. An administrator adds an MCP server over streamable HTTP and authenticates it with OAuth 2.1, so the client registration and token lifecycle are set up centrally. Before go-live, confirm where those client details and tokens are stored, whether each user's tokens are kept separate from the administrator's, and what happens when a user signs out. Two points matter here. First, WEBUI_SECRET_KEY must be set and kept consistent across the deployment, and you should confirm in the configuration documentation what it protects in your version. Second, the scaling guidance states that without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. A multi-replica deployment without shared session state therefore has a longer exposure window for any token that leaks.

Visibility and use follow the same split. An MCP server added by an administrator can be made available to specific groups through Open WebUI's role-based access control, which supports groups and per-resource permissions. Confirm whether the tool list and the server configuration are visible to users who only have use permission. A user-added OpenAPI server is visible only to the person who created it, which limits blast radius but also means IT has no central inventory of which endpoints staff have connected, which keys they pasted into personal settings, or which company data those endpoints received. Ask your team to confirm what the audit logs record for each type of connection, and whether a tool added by a user can be seen or revoked by an administrator. If the answer is no, treat personal tool servers as unmanaged integrations.

Choose the administrator-managed MCP path when a tool touches company systems, uses shared credentials, or must be reviewed by a named owner before anyone relies on it. The risk is concentrated: a misconfigured or over-broad server is exposed to every group granted access at once, so the approval step needs a documented owner, a list of the tools it exposes, and a data classification for what those tools can read or change. Consider a user-added OpenAPI server only for personal work on non-sensitive data, or where the endpoint is one the user already controls. Where your release allows administrators to restrict user-added tool servers, decide that policy before rollout and confirm it with a test account. Write down, for each proposed tool, who approves it, who holds its credentials, and who can use it.

Before you run a second Open WebUI instance, you need PostgreSQL as the database and Redis as a shared state store. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from multiple processes well. Redis holds the state that every replica must see, including sessions, websocket connections and application state. Shared file storage is also required so uploads and knowledge stay reachable from every replica. The guide adds one more constraint: the default ChromaDB will crash in multi-process setups, so an external vector database must be in place when you run several workers or replicas. Treat these as prerequisites for the design, not as tuning options to add after go-live.

Redis matters most for sign-out and token lifetime. Without Redis, signing out does not revoke tokens. They stay valid until they expire, which is by default after 4 weeks. For MCP tool servers, this means a token a user obtained through Open WebUI can remain usable after that user has signed out, and a replica that never received the sign-out event will keep honoring it. A security team will expect that signing out, disabling an account or removing a user from a group ends access promptly. A multi-week validity window does not meet that expectation. Confirm the token lifetime setting for your release, and decide whether a multi-week window is acceptable before you approve the design.

Test the revocation behavior before anyone relies on it. In a staging environment with two replicas, sign in, connect an MCP server, sign out, and then replay the token against the MCP connection through the other replica. Run the same test with Redis present and absent so the difference is documented. Record the result, the release version and the configured token lifetime in your change record. If the test fails, the fix is architectural, so resolve it before production traffic arrives, not during an incident.

SQLite has a narrow place in this design. The scaling guide accepts it for single-replica deployments, evaluation and small teams, and only when the database file sits on locally attached SSD or NVMe storage. A database file on network-attached storage is outside that guidance. Moving an existing SQLite installation to PostgreSQL and a second replica is a migration with its own data validation and rollback plan, so schedule it as a project. Ask your platform team to confirm the storage class for any single-replica SQLite host, and ask whether the database file is on local disk.

Run this test plan on every MCP server before anyone outside the admin team uses it, and record each result against the server name, its endpoint, its version and the Open WebUI version it was tested on. Start with the connection. Confirm that Open WebUI completes the handshake with the server over streamable HTTP, and that the OAuth 2.1 authorization flow finishes against the identity provider you configured. Then confirm that the server refuses requests that carry no token or an invalid token. Ask the server owner which scopes the server requests and which it needs, and check that the two lists match. A server that connects but accepts unauthenticated calls should not move past this step.

Next, list the exposed tools as Open WebUI displays them after the connection succeeds. Compare that list with the tool list in the server's documentation and with the tools your team has approved. Any tool that is not on the approved list should be disabled or should block the release. Then run one read-only call and one write call, both inside a test group rather than for all users. For the write call, use a disposable test record created for this purpose. Check that the result matches what the tool describes, and check the logs on both the server side and the Open WebUI side to confirm the call was recorded where your audit process expects it.

Access control needs its own checks because the server is only as safe as the people who can change it. Sign in as a non-admin test user and confirm that the user cannot add a server, edit an existing server or change its settings. Confirm that a user outside the test group cannot see or call the tools. Then test the session lifecycle. Sign out, and reuse the token from the earlier session to confirm that the server rejects it. The scaling guide states that without Redis, sign-out does not revoke tokens, which means they stay valid until they expire, by default after 4 weeks. Confirm whether your deployment uses Redis, confirm the token lifetime you have actually configured, and test expiry in a test environment if the lifetime can be shortened there. Ask the platform owner to confirm these values in writing.

Test accounts and sample data should mirror production groups, including group names, roles and memberships, so that permission results carry over to real users. The records behind them must be synthetic. Do not point test servers at copies of customer, patient or employee data, and keep test data in a separate instance or tenant where possible. Repeat the full plan after every Open WebUI upgrade and after any change to an MCP server, including a version change, a new endpoint, altered scopes or a changed tool list. Upgrade rounds can be shorter, but they must always include the handshake, the tool inventory and the non-admin access check. Keep the dated results as evidence for your change records.