SEP-1865：MCP Apps——MCP 的交互式用户界面
社区译文；来源： MCP 29affa6b
| 字段 | 值 |
|---|---|
| SEP | 1865 |
| 标题 | MCP Apps——MCP 的交互式用户界面 |
| 状态 | Final |
| 类型 | 扩展跟踪 |
| 创建日期 | 2025-11-21 |
| 作者 | Ido Salomon (@idosal), Liad Yosef (@liadyosef), Olivier Chafik (@olivierchafik), Jerome Swannack (@jeromeswannack), Jonathan Hefner (@jonathanhefner), Anton Pidkuiko (@antonpidkuiko), Nick Cooper (@nickcooper), Bryan Ashley (@bryanashley), Alexi Christakis (@alexichristakis) |
| 发起人 | 无（正在寻求发起人） |
| PR | #1865 |
摘要
本 SEP 提议一项 MCP 扩展（依据 SEP-1724），使服务器能够向宿主交付交互式用户界面。MCP Apps 引入一种标准化模式：通过 ui:// URI scheme 声明 UI 资源，通过元数据将资源与工具关联，并使用 MCP 的 JSON-RPC 基础协议实现 UI 与宿主之间的双向通信。该扩展满足 MCP 社区对丰富交互体验日益增长的需求，同时维持安全性、可审计性，并与 MCP 核心架构保持一致。初始规范聚焦于 HTML 资源（text/html;profile=mcp-app），同时为未来扩展提供清晰路径。
动机
MCP 缺少一种让服务器向宿主交付丰富交互式用户界面的标准方式。这一缺口阻碍了许多超出纯文本或结构化数据、需要视觉呈现和交互的用例。随着越来越多宿主采用这项能力，碎片化和互操作性问题的风险也随之增加。
MCP-UI 已证明基于 UI 资源构建 MCP Apps 的可行性和价值，并作为 UI 规范与 SDK 的社区试验场。在专门社区的推动下，它发展出了双向通信模型，以及 HTML、外部 URL 和远程 DOM 等内容类型。MCP-UI 的采用者包括 Postman、HuggingFace、Shopify、Goose 和 ElevenLabs 等宿主与提供方，他们为社区提供了关键见解与贡献。
OpenAI 的 Apps SDK 于 2025 年 11 月发布，进一步验证了在对话式 AI 界面中提供丰富 UI 体验的需求。Apps SDK 使开发者能够以 MCP 为基础，在 ChatGPT 内构建丰富的交互式应用。
Apps SDK 和 MCP-UI 的架构都对本规范的设计产生了重要影响。
但是，如果没有正式标准化：
- 服务器无法可靠地预期 MCP 支持 UI
- 各宿主可能实现略有不同的行为
- 安全与可审计模式不一致
- 开发者必须为不同宿主维护不同实现或适配器（例如 MCP-UI 与 Apps SDK）
本 SEP 通过一项可选且向后兼容的扩展解决这些现有限制，将 MCP-UI 和 Apps SDK 开创的方法统一为一项开放标准。
规范
完整规范位于 modelcontextprotocol/ext-apps。
从总体上看，MCP Apps 扩展了模型上下文协议，使服务器能够向宿主交付交互式用户界面。该扩展引入：
- UI 资源： 使用
ui://URI scheme 预先声明的资源 - 资源发现： 工具通过元数据引用 UI 资源
- 双向通信： UI iframe 使用标准 MCP JSON-RPC 协议与宿主通信
- 安全模型： 强制使用 iframe 沙箱，并提供可审计的通信
本规范以 HTML 内容（text/html;profile=mcp-app）作为初始内容类型，同时允许未来扩展其他格式。
作为一项扩展，MCP Apps 是可选的，客户端与服务器必须通过扩展能力机制显式协商（参见完整规范中的 Capability Negotiation 一节）。
理由
预先声明资源与内联嵌入
UI 被建模为由工具通过元数据引用的预先声明资源（ui://）。这样可以：
- 让宿主在工具执行前预取模板，从而改善性能
- 将呈现内容（模板）与数据（工具结果）分离，从而便于缓存
- 对 UI 资源进行安全审查
考虑过的替代方案：
- 嵌入式资源： 当前 MCP-UI 的做法，即在工具结果中返回资源。虽然这对服务器开发更方便，但由于性能优化方面存在缺口，且 UI 审查流程面临挑战，因此被延期。
- 资源链接： 预先声明资源，但在工具结果中返回链接。由于性能优化方面存在缺口，因此被延期。
复用 MCP JSON-RPC，而非自定义协议
复用现有 MCP 基础设施（类型定义、SDK 等）。JSON-RPC 提供超时、错误等高级能力。
考虑过的替代方案：
- 自定义消息协议： 当前 MCP-UI 的做法，使用 tool、intent、prompt 等消息类型。这些消息类型可以转换为所提议 JSON-RPC 消息的一个子集。
- 全局 API 对象： 已拒绝，因为它需要宿主特定的注入，并且不适用于外部 iframe 来源。服务器/UI 一侧仍可增加语法糖。
仅支持 HTML 的 MVP
- HTML 得到普遍支持，且广为人知
- 安全模型最简单（标准 iframe 沙箱）
- 支持生成截图/预览（例如通过 html2canvas）
- 足以覆盖大多数已观察到的用例
- 为未来扩展提供清晰基线
考虑过的替代方案：
- 在 MVP 中包含外部 URL： 这是服务器最容易采用的内容类型之一，因为可以嵌入普通应用。但是，考虑到模型可见性、无法截取内容以及审查流程等问题，该方案被延期。SEP 新增的
externalIframes能力实际上可能支持这种方式。
向后兼容性
本提案是核心协议的一项可选扩展。现有实现无需变更即可继续工作。
安全影响
托管来自潜在不可信 MCP 服务器的交互式 UI 内容，需要谨慎考虑安全问题。
根据威胁模型，MCP Apps 提议采取以下缓解措施：
- Iframe 沙箱： 所有 UI 内容都在权限受限的沙箱 iframe 中运行
- 预先声明模板： 宿主可以在渲染前审查 HTML 内容
- 可审计消息： UI 到宿主的全部通信均通过可记录日志的 JSON-RPC
- 用户同意： 宿主可以要求用户显式批准由 UI 发起的工具调用
完整威胁模型分析和缓解措施请参阅完整规范。