feat: Add native MCP (Streamable HTTP) personal integrations

Start with src/shared/userConnections.ts to see how integration types are recognized, then src/main/connections.ts for service advertisement and src/main/relay.ts for the HTTP forwarding and header filtering. The issue asks for a design and a controlled proof of concept first, so the main output is a validated routing contract, not a patch. Done means the agreed path mapping and header behavior are documented and a proof of concept reaches tools/list through the relay.

Summary

Add MCP (Model Context Protocol) Streamable HTTP as a personal integration type in the official Tether client. This allows remote Open WebUI to use native MCP tools from localhost servers over the existing authenticated Tether WebSocket, without extra VPNs, public endpoints, reverse proxies, tunnels or mcpo. Tether should configure and restrict the local HTTP endpoint and relay traffic; Open WebUI should run its existing native MCP client.

Companion Open WebUI request: https://github.com/open-webui/open-webui/issues/34397

Technical notes identify existing integration points and design questions, not a mandatory implementation. Source observations are from Tether main reviewed November 13, 2026.

Use case

My Open WebUI runs on Azure at https://xxx.yyy.zzz. My Windows 11 PC runs Windows-MCP, with a tested Streamable HTTP endpoint at http://127.0.0.1:8000/mcp, and Tether connected to remote Open WebUI. I want to configure it under Settings → Integrations as:

Type: MCP (Streamable HTTP)
Name: Windows-MCP
URL: http://127.0.0.1:8000/mcp
Enabled: Yes

The MCP server remains bound to Windows loopback. Tether advertises the service; Open WebUI discovers and executes tools through its native MCP SDK.

Existing architecture

• src/shared/userConnections.ts recognizes openai, openapi, and terminal, with an ID, name, type, endpoint URL, enabled flag and optional key. URL paths such as /mcp are allowed.
• src/main/connections.ts persists enabled personal integrations, advertises c_<connection-id> relay services and handles updates. Existing enabled integration limits (15 personal services, with built-in terminal occupying another service) should continue to apply.
• src/main/relay.ts already streams HTTP requests and responses, supports concurrent streams, cancellation and local destination credentials, and strips remote credential/transport headers. This is a possible foundation, not yet verified end to end with the MCP SDK. The existing generic relay's same-origin check does not by itself isolate a configured /mcp path.

Proposed client-side direction

1. Add an MCP personal integration

Add mcp to integration types and make MCP (Streamable HTTP) selectable in Settings → Integrations, reusing existing name, URL, enabled, persistence and optional supported key fields. Advertise type: mcp using the existing c_<connection-id> service convention. Keep local endpoint URLs and credentials in local configuration; do not send them in advertisements. Integrations remain opt-in.

2. Prove transport compatibility first

Milestone A — controlled proof of concept: use temporary development-only relay service registration or test fixtures to validate Open WebUI's native MCP SDK initialization, tools/list, tools/call, HTTP status and MCP headers, incremental SSE where used, concurrency, cancellation and errors. This validates transport before choosing an adapter or committing to a production architecture. The proof of concept must remain controlled until endpoint isolation and authorization are validated. Production UI configuration, persistence and discovery are Milestone B. Tether should not implement a second MCP protocol client.

3. Define a shared endpoint-routing contract

A configured endpoint may be http://127.0.0.1:8000/mcp; the SDK may also issue protocol-discovery requests (server/discover where applicable). The mapping must be explicitly agreed across both repositories.

Open WebUI: produce logical HTTP requests using its native MCP SDK; select the requesting user's authorized Tether service; never choose arbitrary local destinations.

Tether: resolve the service to its locally configured endpoint; apply agreed HTTP request-path mapping; normalize and validate the final destination; reject unauthorized paths, destinations and redirects. MCP-specific HTTP routing may be required without parsing MCP JSON-RPC or acting as an MCP client.

Document normal requests, discovery requests, query strings, session termination, redirects and rejected paths. Validate origin and path after URL normalization, including traversal, encoded paths and redirect behavior; do not rely on string-prefix checks. Existing generic relay behavior for other integration types should stay unchanged.

4. Preserve relay header security

Do not weaken filtering of remotely supplied Authorization, Cookie, Host, Connection, Content-Length, Transfer-Encoding or Upgrade headers. Verify forwarding of MCP-required Mcp-Session-Id, MCP-Protocol-Version, Accept, Content-Type and other permitted transport headers. Local authentication, if configured, must be applied by Tether and cannot be overridden by remote credentials.

5. Separate authentication boundaries and support lifecycle

The MVP must support MCP endpoints without local HTTP authentication. Reusing Tether's existing optional key mechanism for authenticated endpoints is desirable where compatible; new authentication schemes, OAuth and arbitrary custom headers are outside initial scope. Authentication to Tether and to the local MCP HTTP server are different boundaries. MCP requests/results travel through the authenticated relay and remote Open WebUI: they do not remain exclusively local.

Stream SSE responses incrementally. Preserve MCP session headers without modification. Cancellation should release local requests/streams. Test the current 300-second socket inactivity timeout against long MCP operations while retaining bounded resource use. On disconnect, release local operations; Open WebUI handles MCP session invalidation and fresh initialization. Never automatically replay operations whose completion is uncertain. Privileged desktop tools warrant user-visible activity or confirmation consideration.

6. Test older-server compatibility

Older Open WebUI versions may reject unknown mcp integration types. Test compatibility; if advertising MCP to unsupported servers causes problems, omit those advertisements for those connections until support is available. Add capability negotiation only if necessary. Existing OpenAI, OpenAPI and terminal integrations must keep working.

Scope and milestones

MVP: MCP Streamable HTTP integration schema/UI, persistence, existing c_<connection-id> advertisement/update behavior, HTTP forwarding, documented secure endpoint routing, header compatibility, streaming, cancellation and lifecycle safety. Out of scope: a local MCP protocol client, comprehensive local protocol test UI, MCP Apps/resources/elicitation, OAuth, arbitrary custom headers, new authentication framework or dedicated MCP networking tunnel.

• Milestone A: controlled relay proof of concept with development-only service registration or test fixtures.
• Milestone B: production integration configuration, persistence, advertisements, secure routing, backward compatibility, lifecycle and regression/security tests.

Acceptance criteria

• Users can configure and enable MCP (Streamable HTTP) in Settings → Integrations using existing validation and persistence.
• MCP services use c_<connection-id> and existing WebSocket service advertisements/updates; local URL and credentials are not advertised.
• Existing HTTP relay works with the native Open WebUI MCP client for initialization, tools/list and tools/call.
• Shared routing contract prevents unrelated local paths, destinations, traversal and redirect bypasses.
• Required MCP headers and incremental SSE streaming work without weakening existing header security.
• Cancellation/disconnect release local resources; uncertain operations are not silently replayed.
• Existing service-count limits and non-MCP integrations remain functional.
• Older Open WebUI versions are tested; unsupported MCP advertisements can be omitted where needed.
• Windows-MCP at 127.0.0.1:8000/mcp works through the matching Open WebUI implementation without additional tunnels, VPNs, public endpoints, proxies or mcpo.

Related source

• Tether integration schema
• Tether service registration
• Tether HTTP relay
• Tether Integrations settings
• Open WebUI native MCP client

Expected outcome: first-party personal MCP integrations from localhost-only servers, carried by the existing authenticated Tether relay and executed with Open WebUI's native MCP client.