Self Checks
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:
- 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.
- 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?
Self Checks
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:
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?