Skip to main content
最终版扩展轨道
字段值
SEP1865
TitleMCP Apps - MCP 的交互式用户界面
Status最终版
Type扩展轨道
Created2025-11-21
Author(s)Ido Salomon (@idosal), Liad Yosef (@liadyosef), Olivier Chafik (@olivierchafik),
Sponsor无（正在寻找赞助者）
PR#1865

​
摘要

本 SEP 提议对 MCP 进行扩展（根据 SEP-1724），使服务器能够向主机交付交互式用户界面。MCP Apps 引入了一种通过 ui:// URI 方案声明 UI 资源、通过元数据将它们与工具关联，并使用 MCP 的 JSON-RPC 基础协议促进 UI 与主机之间双向通信的标准模式。此扩展解决了 MCP 赋能应用程序中对丰富、交互式体验日益增长的社区需求，同时保持了安全性、可审计性并与 MCP 的核心架构保持一致。初始规范侧重于 HTML 资源（text/html;profile=mcp-app），并为未来扩展提供了清晰的路径。

​
动机

MCP 缺乏一种标准化的方式，让服务器向主机交付丰富的交互式用户界面。这一缺口阻碍了许多需要视觉呈现和交互性的用例，这些用例超出了纯文本或结构化数据的范畴。随着更多主机采用此功能，碎片化和互操作性挑战的风险也在增加。 MCP-UI 已经证明了基于 UI 资源构建 MCP 应用程序的可行性和价值，并作为 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 方案预声明的资源
  • 资源发现： 工具通过元数据引用 UI 资源
  • 双向通信： UI iframes 使用标准 MCP JSON-RPC 协议与主机通信
  • 安全模型： 强制 iframe 沙箱化与可审计的通信
本规范侧重于 HTML 内容（text/html;profile=mcp-app）作为初始内容类型，并为未来格式提供了可扩展性。 作为一个扩展，MCP Apps 是可选的，必须通过扩展能力机制在客户端和服务器之间明确协商（参见完整规范中的能力协商部分）。

​
理由

​
预声明资源与内联嵌入

UI 被建模为预声明资源（ui://），由工具通过元数据引用。这允许：
  • 主机在工具执行前预取模板，提高性能
  • 将展示层（模板）与数据（工具结果）分离，便于缓存
  • 对 UI 资源进行安全审查
考虑的替代方案：
  • 嵌入资源： 当前的 MCP-UI 方法，资源在工具结果中返回。虽然这对服务器开发更方便，但由于性能优化方面的差距以及 UI 审查流程的挑战，此方案被推迟。
  • 资源链接： 预声明资源但在工具结果中返回链接。由于性能优化方面的差距而被推迟。

​
复用 MCP JSON-RPC 而非自定义协议

复用现有的 MCP 基础设施（类型定义、SDK 等）。JSON-RPC 提供高级功能（超时、错误等）。 考虑的替代方案：
  • 自定义消息协议： 当前的 MCP-UI 方法，带有工具、意图、提示等消息类型。这些消息类型可以翻译为提议的 JSON-RPC 消息的子集。
  • 全局 API 对象： 被拒绝，因为它需要特定于主机的注入，并且不适用于外部 iframe 源。语法糖仍可在服务器/UI 端添加。

​
仅 HTML 的 MVP

  • HTML 被普遍支持且易于理解
  • 最简单的安全模型（标准 iframe 沙箱）
  • 允许生成截图/预览（例如，通过 html2canvas）
  • 足以满足大多数观察到的用例
  • 为未来扩展提供清晰的基线
考虑的替代方案：
  • 在 MVP 中包含外部 URL： 这是服务器最容易采用的内容类型之一，因为可以嵌入常规应用程序。然而，由于模型可见性、无法截取内容截图以及审查流程的担忧，此方案被推迟。它实际上可以通过 SEP 的新 externalIframes 能力得到支持。

​
向后兼容性

该提议是核心协议的一个可选扩展。现有实现无需更改即可继续工作。

​
安全影响

托管来自潜在不可信 MCP 服务器的交互式 UI 内容需要仔细的安全考虑。 基于威胁模型，MCP Apps 提出了以下缓解措施：
  • Iframe 沙箱化：所有 UI 内容都在具有受限权限的沙箱 iframes 中运行
  • 预声明模板：主机可以在渲染前审查 HTML 内容
  • 可审计消息：所有 UI 到主机的通信都通过可记录日志的 JSON-RPC 进行
  • 用户同意：主机可以要求对 UI 发起的工具调用进行明确批准
完整的威胁模型分析和缓解措施可在完整规范中找到。

​
参考实现

  • MCP-UI 客户端和服务器 SDK 支持本规范中提出的模式。
  • ext-apps 仓库包含由 Olivier Chafik 编写的原型实现。