|
| 1 | ++++ |
| 2 | +date = '2025-11-21T22:00:00+00:00' |
| 3 | +publishDate = '2025-11-21T22:00:00+00:00' |
| 4 | +title = 'MCP Apps: Extending servers with interactive user interfaces' |
| 5 | +author = 'Anton Pidkuiko (Maintainer), Olivier Chafik (Maintainer), Ido Salomon (MCP-UI), Liad Yosef (MCP-UI), Nick Cooper (Core Maintainer), Sean Strong (Anthropic), Jerome Swannack (Anthropic), Alexi Christakis (OpenAI), Bryan Ashley (OpenAI)' |
| 6 | +tags = ['apps', 'ui', 'user interfaces'] |
| 7 | ++++ |
| 8 | + |
| 9 | +Today we're introducing the proposal for the [MCP Apps Extension](https://github.com/modelcontextprotocol/ext-apps) ([SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)) to standardize support for interactive user interfaces in the Model Context Protocol. |
| 10 | + |
| 11 | +This extension addresses one of the most requested features from the MCP community and builds on proven work from [MCP-UI](https://github.com/idosal/mcp-ui) and [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) - the **ability for MCP servers to deliver interactive user interfaces to hosts**. |
| 12 | + |
| 13 | +MCP Apps Extension introduces a standardized pattern for declaring UI resources, linking them to tools, and enabling bidirectional communication between embedded interfaces and the host application. |
| 14 | + |
| 15 | + |
| 16 | + |
| 17 | +The SEP was authored by MCP Core Maintainers at OpenAI and Anthropic, together with the MCP-UI creators and lead maintainers of the MCP UI Community Working Group. |
| 18 | + |
| 19 | +## Standardization for interactive interfaces |
| 20 | + |
| 21 | +Currently, MCP servers are limited to exchanging text and structured data with hosts. While this works well for many use cases, it creates friction when tools need to present visual information or gather complex user input. |
| 22 | + |
| 23 | +For example, consider a data visualization MCP server that returns chart data as JSON. The host application must interpret that data and render it. Handling all kinds of specialized data in this scenario translates to a significant burden for client developers, who would need to build their own logic to render the UI. As more UI requirements come up, like the need to collect multiple related settings from users, the complexity balloons. Alternatively, without UI support, these interactions become awkward exchanges of text prompts and responses. |
| 24 | + |
| 25 | +The MCP community has been creative in working around these limitations, but different implementations using varying conventions and architectures make it harder for servers to work consistently across clients. This lack of standardization creates a real risk of ecosystem fragmentation - something we're working to proactively prevent. |
| 26 | + |
| 27 | +## Building together |
| 28 | + |
| 29 | +The [MCP-UI project](https://github.com/MCP-UI-Org/mcp-ui), created by [Ido Salomon](https://github.com/idosal) and [Liad Yosef](https://github.com/liady) and maintained by a dedicated community, spearheaded the vision of agentic apps with interactive interfaces. The project developed patterns for delivering rich user interfaces as first-class MCP resources, proving that agentic apps fit naturally within the MCP architecture. The project is backed by a large community and provides [rich SDKs](https://mcpui.dev/guide/client/overview), adopted at leading companies and projects such as Postman, Shopify, Hugging Face, Goose, and ElevenLabs. |
| 30 | + |
| 31 | +The [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) further validated the demand for rich UI experiences within conversational AI interfaces. The SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. To ensure interoperability and establish consistent security and usage patterns across the ecosystem, Anthropic, OpenAI, and MCP-UI are collaborating to create an official MCP extension for interactive interfaces. |
| 32 | + |
| 33 | + |
| 34 | + |
| 35 | +## MCP Apps Extension specification |
| 36 | + |
| 37 | +We're proposing a specification for UI resources in MCP, but the implications go further than just a set of schema changes. The MCP Apps Extension is starting to look like an agentic app runtime: a foundation for novel interactions between AI models, users, and applications. The proposal is intentionally lean, starting with core patterns that we plan on expanding over time. |
| 38 | + |
| 39 | +### Key design decisions |
| 40 | + |
| 41 | +#### Pre-declared resources |
| 42 | + |
| 43 | +UI templates are resources with the `ui://` URI scheme, referenced in tool metadata. |
| 44 | + |
| 45 | +```ts |
| 46 | +// Server registers UI resource |
| 47 | +{ |
| 48 | + uri: "ui://charts/bar-chart", |
| 49 | + name: "Bar Chart Viewer", |
| 50 | + mimeType: "text/html+mcp" |
| 51 | +} |
| 52 | + |
| 53 | +// Tool references it in metadata |
| 54 | +{ |
| 55 | + name: "visualize_data_as_bar_chart", |
| 56 | + description: "Plots some data as a bar chart", |
| 57 | + inputSchema: { |
| 58 | + type: "object", |
| 59 | + properties: { |
| 60 | + series: { type: "array", items: .... } |
| 61 | + } |
| 62 | + }, |
| 63 | + _meta: { |
| 64 | + "ui/resourceUri": "ui://charts/bar-chart", |
| 65 | + } |
| 66 | +} |
| 67 | +``` |
| 68 | + |
| 69 | +This approach enables hosts to prefetch and review templates before tool execution, improving both performance and security. It also separates static presentation (the template) from dynamic data (tool results), enabling better caching. |
| 70 | + |
| 71 | +#### MCP transport for communication |
| 72 | + |
| 73 | +Instead of inventing a custom message protocol, UI components communicate with hosts using existing MCP JSON-RPC base protocol over `postMessage`. This means that: |
| 74 | + |
| 75 | +- UI developers can use the standard `@modelcontextprotocol/sdk` to build their applications |
| 76 | +- All communication is structured and auditable |
| 77 | +- Future MCP features automatically work with the UI extension |
| 78 | + |
| 79 | +#### Starting with HTML |
| 80 | + |
| 81 | +The initial extension specification supports only `text/html` content, rendered in sandboxed [iframes](https://developer.mozilla.org/docs/Web/HTML/Reference/Elements/iframe). This provides: |
| 82 | + |
| 83 | +- Universal browser support |
| 84 | +- Well-understood security model |
| 85 | +- Screenshot and preview generation capabilities |
| 86 | +- A clear baseline for future extensions |
| 87 | + |
| 88 | +Other content types such as external URLs, remote DOM, and native widgets are explicitly deferred to future iterations. |
| 89 | + |
| 90 | +#### Security-first |
| 91 | + |
| 92 | +Hosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers: |
| 93 | + |
| 94 | +1. **Iframe sandboxing**: All UI content runs in sandboxed iframes with restricted permissions |
| 95 | +2. **Predeclared templates**: Hosts can review HTML content before rendering |
| 96 | +3. **Auditable messages**: All UI-to-host communication goes through loggable JSON-RPC |
| 97 | +4. **User consent**: Hosts can require explicit approval for UI-initiated tool calls |
| 98 | + |
| 99 | +These mitigations create defense in depth against malicious servers while preserving the flexibility developers need. |
| 100 | + |
| 101 | +#### Backward compatibility |
| 102 | + |
| 103 | +MCP Apps is an optional extension. Existing implementations continue working without changes, and hosts can gradually adopt UI support at their own pace. Servers should provide text-only fallback for all UI-enabled tools and return meaningful content even when UI is unavailable, so they can serve both UI-capable and text-only hosts. |
| 104 | + |
| 105 | +## What's next |
| 106 | + |
| 107 | +The [UI Community Working Group](https://github.com/modelcontextprotocol-community/working-groups/issues/35) has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an [early access SDK](https://github.com/modelcontextprotocol/ext-apps) to demonstrate the patterns and types described in the specification proposal. The [MCP-UI](https://mcpui.dev/) client and server SDKs support these patterns. |
| 108 | + |
| 109 | +If you are interested in contributing to this effort, we invite you to: |
| 110 | + |
| 111 | +- Review the full specification in [SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865) |
| 112 | +- Share feedback and concerns in [GitHub Issues](https://github.com/MCP-UI-Org/mcp-ui/issues) |
| 113 | +- Join the discussion in the `#ui-wg` channel in the [MCP Contributors Discord](https://modelcontextprotocol.io/community/communication#discord) |
| 114 | +- Test prototype implementations and share your experience |
| 115 | + |
| 116 | +## Acknowledgements |
| 117 | + |
| 118 | +This proposal wouldn't exist without the work of the maintainers at MCP-UI, OpenAI, and Anthropic. |
| 119 | + |
| 120 | +**Ido Salomon** and **Liad Yosef**, through MCP-UI and moderation of `#ui-wg`, incubated and championed many of the patterns that MCP Apps now standardizes, and together with contributors demonstrated that UI resources can be a natural part of MCP. |
| 121 | + |
| 122 | +**Sean Strong**, **Olivier Chafik**, **Anton Pidkuiko**, and **Jerome Swannack** from Anthropic helped steer the initiative and drive the collaboration. |
| 123 | + |
| 124 | +**Nick Cooper**, **Alexei Christakis**, and **Bryan Ashley** from OpenAI have provided valuable direction from their experience building the Apps SDK. |
| 125 | + |
| 126 | +Special thanks to the **UI Community Working Group** members and everyone who contributed to the discussions that shaped this proposal. |
0 commit comments