mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-08 12:58:11 -05:00
[GH-ISSUE #20995] feat: Support for MCP Apps Extension (Interactive UI in Chat) #58021
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#58021
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @IngoKiy on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20995
Check Existing Issues
Verify Feature Scope
Problem Description
Currently, OpenWebUI's MCP integration is limited to tool calls that return text/structured data. As noted in the documentation:
"MCP tools exposed via mcpo cannot use Open WebUI's event system for real-time UI updates (status messages, notifications, user input prompts). These features are only available for native Python tools."
This means MCP servers cannot render interactive UI elements like charts, forms, dashboards, or media players directly in the chat. Users have been asking about this capability (see #16327).
Desired Solution you'd like
Add support for the MCP Apps Extension (SEP-1865), the official standard for interactive UIs in MCP.
MCP Apps allows MCP servers to:
Return interactive HTML/JS UIs that render in sandboxed iframes
Enable bidirectional communication between the UI and the host via JSON-RPC
Support use cases like data visualization, forms, media players, multi-step workflows
Alternatives Considered
No response
Additional Context
Why now?
MCP Apps is now official – The spec was finalized and the SDK (@modelcontextprotocol/ext-apps) is published (v1.0.1)
Industry adoption – Claude, ChatGPT, VS Code, and Goose already support MCP Apps
Collaborative standard – Developed jointly by Anthropic, OpenAI, and the MCP-UI community
SDK available for hosts – @modelcontextprotocol/ext-apps/app-bridge provides the host-side implementation
Reference implementation exists – MCP-UI has contributed iframe/sandboxing logic that OSS clients can use
Technical Overview
MCP Apps uses a two-part pattern:
Tool with UI metadata – Tools include _meta.ui.resourceUri pointing to a UI resource
UI Resource – HTML content served via ui:// scheme, rendered in sandboxed iframe
typescript// Server registers tool with UI link
registerAppTool(server, "visualize-data", {
description: "Show interactive chart",
inputSchema: { /* ... / },
_meta: { ui: { resourceUri: "ui://charts/interactive" } }
}, async () => { / ... */ });
The host:
Detects _meta.ui.resourceUri in tool response
Fetches the UI resource
Renders it in a sandboxed iframe
Bridges communication via postMessage using MCP JSON-RPC
Resources
Specification: https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx
SDK & Examples: https://github.com/modelcontextprotocol/ext-apps
Host Bridge SDK: https://modelcontextprotocol.github.io/ext-apps/api/modules/app-bridge.html
MCP-UI (reference implementation): https://github.com/MCP-UI-Org/mcp-ui
Announcement blog post: https://modelcontextprotocol.io/blog/mcp-apps
Additional context
This would make OpenWebUI one of the first open-source chat interfaces to support the full MCP Apps standard, significantly expanding what MCP servers can do. The existing MCP Streamable HTTP support in OpenWebUI is a great foundation to build on.
@owui-terminator[bot] commented on GitHub (Jan 28, 2026):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
by paulelvers • Jan 27, 2026
💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@yannj-fr commented on GitHub (Mar 20, 2026):
https://github.com/open-webui/open-webui/pull/21639
@ThalesMMS commented on GitHub (Mar 26, 2026):
Wasn't it merged after all? Why?
@Classic298 commented on GitHub (Mar 26, 2026):
@ThalesMMS the PR is very large and messy, extremely difficult to review in scope
semi-unrelated question: why is it even needed? tools already offer Rich UI
@yannj-fr commented on GitHub (Mar 26, 2026):
This is the standard, MCPApps is the official extension to support UI in tools
@yannj-fr commented on GitHub (Mar 26, 2026):
This is large because it has to implement security model, visibility and so on to follow the specifications
https://modelcontextprotocol.io/extensions/apps/overview
https://github.com/modelcontextprotocol/ext-apps/
@yannj-fr commented on GitHub (Mar 26, 2026):
Also please advise, we are eager to improve it
@Classic298 commented on GitHub (Mar 26, 2026):
ok let me check it out. I'll be back
@Classic298 commented on GitHub (Mar 26, 2026):
I will comment my findings to the discussion later: https://github.com/open-webui/open-webui/discussions/20915
@Classic298 commented on GitHub (Mar 26, 2026):
Following up on my review — I built a proof of concept that demonstrates Open WebUI's existing Rich UI system can render MCP App ui:// resources without any core changes.
It's a single Tool file (~250 lines) that:
The security model (CSP directives, iframe sandbox) maps directly to what Open WebUI already provides — no double-iframe proxy or additional npm dependencies needed.
Available here: https://github.com/Classic298/open-webui-plugins/tree/main/mcp-app-bridge
Detailed findings (including a code review of the PR) are posted to the discussion at #20915.
@yannj-fr commented on GitHub (Mar 26, 2026):
Do you dispatch ui/notifications/tool-result
@Classic298 commented on GitHub (Mar 26, 2026):
Yes @yannj-fr — the tool now dispatches ui/notifications/tool-result per the spec.
Since a Tool can only control what goes inside the iframe (not the parent page), I implemented it as a shim: after OMContentLoaded, a synthetic MessageEvent is dispatched with source set to window.parent, carrying the JSON-RPC notification with the tool result in both content and structuredContent (if parseable as JSON).
This means apps built with the official AppBridge SDK receive the tool result via the standard protocol — no iframe same-origin needed.
The one thing that can't be done from inside the iframe alone is the app calling tools back through the host. But that maps to Open WebUI's existing sendPrompt bridge, which works without same-origin since 0.8.11 (via HITL confirmation) and with auto-submit when same-origin is enabled. Different mechanism, same outcome, and arguably better because the user sees what's happening.
Updated: https://github.com/Classic298/open-webui-plugins/tree/main/mcp-app-bridge