FinalExtensions Track
| Field | Value |
|---|---|
| SEP | 1865 |
| Title | MCP Apps - Interactive User Interfaces for MCP |
| Status | Final |
| Type | Extensions Track |
| Created | 2025-11-21 |
| Author(s) | Ido Salomon (@idosal), Liad Yosef (@liadyosef), Olivier Chafik (@olivierchafik), |
| Sponsor | None (seeking sponsor) |
| PR | #1865 |
Abstract
This SEP proposes an extension to MCP (per SEP-1724) that enables servers to deliver interactive user interfaces to hosts. MCP Apps introduces a standardized pattern for declaring UI resources via theui:// URI scheme, associating them with tools through metadata, and facilitating
bi-directional communication between the UI and the host using MCP’s JSON-RPC base protocol. This
extension addresses the growing community need for rich, interactive experiences in MCP-enabled
applications, maintaining security, auditability, and alignment with MCP’s core architecture. The
initial specification focuses on HTML resources (text/html;profile=mcp-app) with a clear path for
future extensions.
Motivation
MCP lacks a standardized way for servers to deliver rich, interactive user interfaces to hosts. This gap blocks many use cases that require visual presentation and interactivity that go beyond plain text or structured data. As more hosts adopt this capability, the risk of fragmentation and interoperability challenges grows. MCP-UI has demonstrated the viability and value of MCP apps built on UI resources and serves as a community playground for the UI spec and SDK. Fueled by a dedicated community, it developed the bi-directional communication model and the HTML, external URL, and remote DOM content types. MCP-UI’s adopters, including hosts and providers such as Postman, HuggingFace, Shopify, Goose, and ElevenLabs, have provided critical insights and contributions to the community. OpenAI’s Apps SDK, launched in November 2025, further validated the demand for rich UI experiences within conversational AI interfaces. The Apps SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. The architecture of both the Apps SDK and MCP-UI has significantly informed the design of this specification. However, without formal standardization:- Servers cannot reliably expect UI support via MCP
- Each host may implement slightly different behaviors
- Security and auditability patterns are inconsistent
- Developers must maintain separate implementations or adapters for different hosts (e.g., MCP-UI vs. Apps SDK)
Specification
The full specification can be found at modelcontextprotocol/ext-apps. At a high level, MCP Apps extends the Model Context Protocol to enable servers to deliver interactive user interfaces to hosts. This extension introduces:- UI Resources: Predeclared resources using the
ui://URI scheme - Resource Discovery: Tools reference UI resources via metadata
- Bi-directional Communication: UI iframes communicate with hosts using standard MCP JSON-RPC protocol
- Security Model: Mandatory iframe sandboxing with auditable communication
text/html;profile=mcp-app) as the initial content
type, with extensibility for future formats.
As an extension, MCP Apps is optional and must be explicitly negotiated between clients and servers
through the extension capabilities mechanism (see Capability Negotiation section in the
full specification).
Rationale
Predeclared resources vs. inline embedding
UI is modeled as predeclared resources (ui://), referenced by tools via metadata. This allows:
- Hosts to prefetch templates before tool execution, improving performance
- Separation of presentation (template) from data (tool results), facilitating caching
- Security review of UI resources
- Embedded resources: Current MCP-UI approach, where resources are returned in tool results. Although it’s more convenient for server development, it was deferred due to the gaps in performance optimization and the challenges in the UI review process.
- Resource links: Predeclare the resources but return links in tool results. Deferred due to the gaps in performance optimization.
Reusing MCP JSON-RPC instead of a custom protocol
Reuses existing MCP infrastructure (type definitions, SDKs, etc.). JSON-RPC offers advanced capabilities (timeouts, errors, etc.). Alternatives considered:- Custom message protocol: Current MCP-UI approach with message types like tool, intent, prompt, etc. These message types can be translated to a subset of the proposed JSON-RPC messages.
- Global API object: Rejected because it requires host-specific injection and doesn’t work with external iframe sources. Syntactic sugar may still be added on the server/UI side.
HTML-only MVP
- HTML is universally supported and well-understood
- Simplest security model (standard iframe sandbox)
- Allows screenshot/preview generation (e.g., via html2canvas)
- Sufficient for most observed use cases
- Provides a clear baseline for future extensions
- Include external URLs in MVP: This is one of the easiest content types for servers to adopt,
as it’s possible to embed regular apps. However, it was deferred due to concerns around model
visibility, inability to screenshot content, and review process. It may effectively be supported
with the SEP’s new
externalIframescapability.
Backward Compatibility
The proposal is an optional extension to the core protocol. Existing implementations continue working without changes.Security Implications
Hosting interactive UI content from potentially untrusted MCP servers requires careful security consideration. Based on the threat model, MCP Apps proposes the following mitigations:- Iframe sandboxing: All UI content runs in sandboxed iframes with restricted permissions
- Predeclared templates: Hosts can review HTML content before rendering
- Auditable messages: All UI-to-host communication goes through loggable JSON-RPC
- User consent: Hosts can require explicit approval for UI-initiated tool calls