[GH-ISSUE #24117] feat: Expose Open WebUI as a native MCP server — enable direct Hermes Agent-to-WebUI communication and full headless control #107189

New Issue

2026-05-18T05:51:34-05:00

GiteaMirror commented

2026-05-18 05:51:34 -05:00

Originally created by @githb-ac on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24117

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Open WebUI currently supports MCP as a client — it can connect outward to external
MCP servers. However it does not expose itself as an MCP server, meaning AI agents
such as Hermes Agent (https://github.com/NousResearch/hermes-agent) have no native
way to push data directly into the Open WebUI interface.

Currently the only options are polling or WebSocket connections to get data from
the agent layer into the UI. This requires bespoke data pipelines between the agent
and the interface that are fragile, hard to maintain, and specific to each deployment.

Hermes Agent already speaks MCP natively for everything it does. If Open WebUI
exposed itself as an MCP server, Hermes Agent could push agent status, costs,
hallucination data, VPS health, and live event streams directly into the UI using
the same protocol it already uses — with no new protocol work required on the agent
side at all.

Desired Solution you'd like

Expose Open WebUI as a native MCP server so that any MCP-compatible agent —
including Hermes Agent and Claude Desktop — can connect to it directly and push
or query data using natural language.

Every panel and action in the Open WebUI interface should have a corresponding
MCP tool, making the UI fully headless and agent-controllable:

Agent status and management
— query agent status, quality scores, hallucination rates, swap models,
replace agents
Cost and token tracking
— query 7-day cost, monthly pace, budget remaining, cost per agent and
per provider
VPS health
— query live CPU, RAM and disk usage
Hallucination alerts
— list active alerts, dismiss alerts, set and update thresholds per agent
Team management
— view, create and edit teams and agents, update roles, skills and model
assignments, trigger config reload without restart
MCP server management
— enable, disable, add and remove MCP servers per agent
Live event stream
— query recent tool calls, errors, successes and warnings per agent
Model health
— compare models by quality score and hallucination rate, get replacement
recommendations
Aegis data
— query traces, violations, pending approvals and anomalies from an
external Aegis gateway
Heartbeat status
— check whether the agent process is alive and when it was last seen
Provider failover status
— query which provider is currently serving each model, view failover
history per agent

The MCP server endpoint should follow the same pattern as Aegis, which already
implements this successfully at ws://localhost:8080/mcp-audit — exposing an MCP
server with tools that map directly to its internal API.

Alternatives Considered

The only current alternatives are polling or WebSocket connections, both of which
require custom integration work for every deployment. There is no way for an
MCP-native agent to push data into Open WebUI today without bespoke pipelines.

Additional Context

Reference implementation — Aegis MCP server (working example of this pattern):
https://github.com/Justin0504/Aegis

Hermes Agent (NousResearch) — the primary MCP client that would connect to this:
https://github.com/NousResearch/hermes-agent

The two components would communicate as peers in the same MCP ecosystem, with
Hermes Agent acting as MCP client and Open WebUI acting as MCP server — requiring
no new protocol work on either side beyond the server endpoint itself.

Originally created by @githb-ac on GitHub (Apr 24, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24117 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Open WebUI currently supports MCP as a client — it can connect outward to external MCP servers. However it does not expose itself as an MCP server, meaning AI agents such as Hermes Agent (https://github.com/NousResearch/hermes-agent) have no native way to push data directly into the Open WebUI interface. Currently the only options are polling or WebSocket connections to get data from the agent layer into the UI. This requires bespoke data pipelines between the agent and the interface that are fragile, hard to maintain, and specific to each deployment. Hermes Agent already speaks MCP natively for everything it does. If Open WebUI exposed itself as an MCP server, Hermes Agent could push agent status, costs, hallucination data, VPS health, and live event streams directly into the UI using the same protocol it already uses — with no new protocol work required on the agent side at all. ### Desired Solution you'd like Expose Open WebUI as a native MCP server so that any MCP-compatible agent — including Hermes Agent and Claude Desktop — can connect to it directly and push or query data using natural language. Every panel and action in the Open WebUI interface should have a corresponding MCP tool, making the UI fully headless and agent-controllable: 1. Agent status and management — query agent status, quality scores, hallucination rates, swap models, replace agents 2. Cost and token tracking — query 7-day cost, monthly pace, budget remaining, cost per agent and per provider 3. VPS health — query live CPU, RAM and disk usage 4. Hallucination alerts — list active alerts, dismiss alerts, set and update thresholds per agent 5. Team management — view, create and edit teams and agents, update roles, skills and model assignments, trigger config reload without restart 6. MCP server management — enable, disable, add and remove MCP servers per agent 7. Live event stream — query recent tool calls, errors, successes and warnings per agent 8. Model health — compare models by quality score and hallucination rate, get replacement recommendations 9. Aegis data — query traces, violations, pending approvals and anomalies from an external Aegis gateway 10. Heartbeat status — check whether the agent process is alive and when it was last seen 11. Provider failover status — query which provider is currently serving each model, view failover history per agent The MCP server endpoint should follow the same pattern as Aegis, which already implements this successfully at ws://localhost:8080/mcp-audit — exposing an MCP server with tools that map directly to its internal API. ### Alternatives Considered The only current alternatives are polling or WebSocket connections, both of which require custom integration work for every deployment. There is no way for an MCP-native agent to push data into Open WebUI today without bespoke pipelines. ### Additional Context Reference implementation — Aegis MCP server (working example of this pattern): https://github.com/Justin0504/Aegis Hermes Agent (NousResearch) — the primary MCP client that would connect to this: https://github.com/NousResearch/hermes-agent The two components would communicate as peers in the same MCP ecosystem, with Hermes Agent acting as MCP client and Open WebUI acting as MCP server — requiring no new protocol work on either side beyond the server endpoint itself.

GiteaMirror closed this issue

2026-05-18 05:51:34 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#107189