Feature request: allow members to add MCP tool servers (personal connections are OpenAPI-only) #19

New Issue

2026-10-14T04:43:43Z

inference-bot commented

2026-10-14 04:43:43 +00:00

The problem

Members can now attach external tool servers to their chats (Settings →
Services → Integrations → External Tool Servers) — but only services that
speak the OpenAPI protocol. The Type selector in the add dialog is
deliberately OpenAPI-only for personal connections ({#if !direct} in
AddToolServerModal.svelte — same in upstream latest), so MCP servers
cannot be added by members, only by admins via the shared admin
configuration (tool_server.connections).

This surfaced when a member tried to connect two different marketplace-search
services (secondhand-mcp, socialapis.io) — both are MCP-only (no OpenAPI
spec published), so neither is member-addable. The member's goal is legitimate
and low-risk: read-only searches of public marketplace data under their own
account and quota.

Why this matters

Tool integrations are exactly the kind of member-driven experimentation the
co-op wants to encourage, and the current design makes every non-OpenAPI
integration an admin ticket.
Admin-added MCP servers are co-op-wide and share a single credential:
either the co-op owns the API key (cost, quota, and a shared privacy
posture members didn't individually consent to) or a member's personal key
gets configured co-op-wide (their quota, visible to everyone — clearly
wrong).
The OpenAI-style "bring your own key" model fits the co-op well: members
already manage their own API keys in the dashboard.

Current state (verified 2026-10-13)

Open WebUI 0.12.0; features.direct_tool_servers enabled platform-wide.
Personal connections: OpenAPI-only by design (upstream behaves the same
in the latest AddToolServerModal.svelte).
Admin MCP connections work fine (verified with two external MCP services).

Potential solutions (in order of preference)

1. Allow the MCP type for personal (direct) connections

Lift the {#if !direct} restriction so the Type toggle renders for members.
Members add MCP servers under their own accounts; the platform already
enforces the direct_tool_servers permission server-side (user-supplied
tool servers are stripped from requests when the permission is absent, so the
boundary is real).

Security considerations (accepted by the co-op's "high trust community"
posture, but worth noting upstream): a member's MCP server sees the content
of chats it's attached to, and the server makes outbound calls to
member-specified URLs. These are the member's own risk surface — the same
trust model as personal OpenAPI connections, which already have both
properties.

2. Co-op-hosted OpenAPI wrapper bridge

The co-op hosts a small OpenAPI-compatible proxy that forwards to arbitrary
MCP services configured by the operator. Members connect to the wrapper with
their own upstream API key (passed per-request), keeping accounts
per-member. This works within today's constraints but is real infrastructure:
hosting, maintenance, and a trust boundary (the wrapper sees member keys).

3. Admin-added per-request keys

Keep MCP admin-curated, but allow an admin-added MCP server to prompt the
member for their own API key at use time (per-member key storage for a shared
server definition). Avoids shared credentials without changing the connection
model.

What we'd love from upstream/maintainers

A steer on whether personal MCP connections are on the roadmap, and if the
{#if !direct} restriction is a deliberate trust boundary or just an early
default. Happy to test a build or provide more detail on our setup
(Cloudron-packaged 0.12.0, SSO, ~25 members, tool servers over
streamable-http verified working from our network).

## The problem Members can now attach **external tool servers** to their chats (Settings → Services → Integrations → External Tool Servers) — but only services that speak the **OpenAPI** protocol. The **Type** selector in the add dialog is deliberately OpenAPI-only for personal connections (`{#if !direct}` in `AddToolServerModal.svelte` — same in upstream latest), so **MCP servers cannot be added by members**, only by admins via the shared admin configuration (`tool_server.connections`). This surfaced when a member tried to connect two different marketplace-search services (secondhand-mcp, socialapis.io) — both are **MCP-only** (no OpenAPI spec published), so neither is member-addable. The member's goal is legitimate and low-risk: read-only searches of public marketplace data under their own account and quota. ## Why this matters - Tool integrations are exactly the kind of member-driven experimentation the co-op wants to encourage, and the current design makes every non-OpenAPI integration an admin ticket. - Admin-added MCP servers are **co-op-wide and share a single credential**: either the co-op owns the API key (cost, quota, and a shared privacy posture members didn't individually consent to) or a member's personal key gets configured co-op-wide (their quota, visible to everyone — clearly wrong). - The OpenAI-style "bring your own key" model fits the co-op well: members already manage their own API keys in the dashboard. ## Current state (verified 2026-10-13) - Open WebUI 0.12.0; `features.direct_tool_servers` enabled platform-wide. - Personal connections: **OpenAPI-only by design** (upstream behaves the same in the latest `AddToolServerModal.svelte`). - Admin MCP connections work fine (verified with two external MCP services). ## Potential solutions (in order of preference) ### 1. Allow the MCP type for personal (direct) connections Lift the `{#if !direct}` restriction so the Type toggle renders for members. Members add MCP servers under their own accounts; the platform already enforces the `direct_tool_servers` permission server-side (user-supplied tool servers are stripped from requests when the permission is absent, so the boundary is real). Security considerations (accepted by the co-op's "high trust community" posture, but worth noting upstream): a member's MCP server sees the content of chats it's attached to, and the server makes outbound calls to member-specified URLs. These are the member's own risk surface — the same trust model as personal OpenAPI connections, which already have both properties. ### 2. Co-op-hosted OpenAPI wrapper bridge The co-op hosts a small OpenAPI-compatible proxy that forwards to arbitrary MCP services configured by the operator. Members connect to the wrapper with **their own upstream API key** (passed per-request), keeping accounts per-member. This works within today's constraints but is real infrastructure: hosting, maintenance, and a trust boundary (the wrapper sees member keys). ### 3. Admin-added per-request keys Keep MCP admin-curated, but allow an admin-added MCP server to prompt the member for their own API key at use time (per-member key storage for a shared server definition). Avoids shared credentials without changing the connection model. ## What we'd love from upstream/maintainers A steer on whether personal MCP connections are on the roadmap, and if the `{#if !direct}` restriction is a deliberate trust boundary or just an early default. Happy to test a build or provide more detail on our setup (Cloudron-packaged 0.12.0, SSO, ~25 members, tool servers over streamable-http verified working from our network).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: co-op/support#19