dify - 💡(How to fix) Fix Feature request: Support MCP Apps extension (SEP-1865) for interactive UI in tool/MCP outputs [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#35658Fetched 2026-04-29 06:36:15
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
2
Author
Participants
Timeline (top)
labeled ×3

Root Cause

Why this is different from "support iframes / arbitrary HTML": It's tempting to flatten this into "Dify should render iframes," but the asks are categorically different. MCP Apps is a bounded extension, opt-in via capability negotiation, mandatory sandbox, predeclared ui:// templates that hosts can review and gate, an auditable JSON-RPC message protocol, host-controlled permission and CSP policies. A maintainer can reasonably accept MCP Apps while still saying no to generic HTML/iframe rendering, because the security and product surfaces are not the same. Treating them as the same conversation conflates "join an open standard" with "add an unbounded primitive." I think it's worth disambiguating those upfront in the discussion.

RAW_BUFFERClick to expand / collapse

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Yes. I've been integrating an MCP server that delivers interactive UI alongside its tool results into Dify, and hit a hard wall: the same server that produces a fully interactive experience in Claude, ChatGPT, and Cursor degrades to escaped markup in Dify's agent thoughts panel. The technical capability, interactive UI in chat, already exists in the rest of the MCP host ecosystem; what's missing is Dify's implementation of the standardized extension that carries it.

Practically that means today there are only two paths if you want this in front of Dify users:

  1. Fork Dify and add a custom rendering layer in web/. Works, but every Dify upgrade becomes a rebase, every deployment becomes a custom image, and the integration doesn't transfer to anyone else running stock Dify.
  2. Tell users to use a different MCP host (Claude, ChatGPT, etc.) for that conversation. Defeats the point of having Dify as a unified workspace.

Both paths fragment what should be a single integration story. With MCP Apps support in Dify upstream, the same server runs the same way across every compliant host, including stock Dify, with no per-vendor frontend work. That's the "standardize once, render everywhere" outcome the SEP was authored to deliver.

I don't think this is a niche problem either. As more MCP server authors build UI-rich experiences, they currently have to accept that Dify users will only get a text-fallback version. Closing this gap by supporting MCP Apps would be a huge win for Dify, ensuring it remains a top-tier, first-choice host for the next generation of interactive agent tools.

2. Additional context or comments

A few practical notes that didn't fit cleanly into the main description:

Why this is different from "support iframes / arbitrary HTML": It's tempting to flatten this into "Dify should render iframes," but the asks are categorically different. MCP Apps is a bounded extension, opt-in via capability negotiation, mandatory sandbox, predeclared ui:// templates that hosts can review and gate, an auditable JSON-RPC message protocol, host-controlled permission and CSP policies. A maintainer can reasonably accept MCP Apps while still saying no to generic HTML/iframe rendering, because the security and product surfaces are not the same. Treating them as the same conversation conflates "join an open standard" with "add an unbounded primitive." I think it's worth disambiguating those upfront in the discussion.

Adoption momentum: SEP-1865 reached Final status on the Extensions Track in late 2025, fueled by the convergence of OpenAI's Apps SDK and the community MCP-UI project. The named adopters via either lineage already include Anthropic (Claude, Claude Desktop), OpenAI (ChatGPT), Microsoft (VS Code Copilot), Cursor, Goose, Postman, MCPJam, plus servers from HuggingFace, Shopify, ElevenLabs, and the broader MCP-UI community. This isn't a speculative or fringe extension; it's where the ecosystem is converging.

Reference material in case it's useful for evaluation:

Happy to keep iterating on scope / approach in this thread.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.

extent analysis

TL;DR

Implementing MCP Apps support in Dify would allow for standardized interactive UI experiences across compliant hosts, resolving the current limitation of escaped markup in Dify's agent thoughts panel.

Guidance

  • Review the SEP-1865 spec and full extension spec to understand the requirements for implementing MCP Apps support in Dify.
  • Consider the security implications and how Dify's current architecture can be adapted to support the bounded extension, opt-in via capability negotiation, and mandatory sandbox.
  • Evaluate the potential impact on Dify's rendering layer and how it can be modified to support MCP Apps without introducing security risks.
  • Explore the host-side reference SDK and client matrix to understand the current adoption and implementation of MCP Apps in other hosts.

Example

No code example is provided as the issue requires a high-level understanding of the MCP Apps extension and its implementation in Dify.

Notes

The implementation of MCP Apps support in Dify requires careful consideration of security and architectural implications. The issue provides extensive reference material, including specs and implementation guides, which should be reviewed before attempting to implement the feature.

Recommendation

Apply a workaround by forking Dify and adding a custom rendering layer, as described in the issue, until a proper implementation of MCP Apps support is available. This allows for temporary support of interactive UI experiences while the main issue is being addressed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING