OpenAI 与 Anthropic 联合推出了 MCP Apps 扩展提案 (SEP-1865)，旨在为模型上下文协议 (MCP) 引入标准化的交互式用户界面支持。通过允许 MCP 服务器直接提供预声明的 UI 资源（如 HTML 模板），该提案解决了以往仅靠文本和数据交互的局限性，极大地提升了复杂数据展示和用户输入的体验。这一举措不仅基于双方及社区的实践经验，旨在统一生态系统标准以防止碎片化，同时也充分兼顾了安全性和向后兼容性。
为什么需要标准化的交互界面？
目前，MCP 服务器与宿主应用之间的交流仅限于文本和结构化数据。虽然这能满足基础需求，但在处理视觉信息或复杂交互时，就会遇到明显的瓶颈。
- 开发负担重： 如果 AI 工具想要展示图表，宿主应用必须自己去编写逻辑来渲染这些数据。随着需求增加（如用户设置表单），复杂性会成倍增长。
- 交互体验差： 如果没有 UI 支持，用户与 AI 的交互往往会退化为尴尬的纯文字对话。
- 生态碎片化风险： 社区虽然尝试了各种变通方法，但缺乏统一标准意味着不同的服务器在不同的客户端上表现不一。
我们正在积极防止生态系统的碎片化，这也是标准化工作的重要目标。
MCP Apps 的核心设计方案
该提案并非仅仅是对协议的简单修改，它更像是一个代理应用运行时（Agentic App Runtime），为 AI 模型、用户和应用程序之间的新型交互奠定了基础。
1. 预先声明的 UI 资源
系统引入了标准化的模式来声明 UI 资源。这意味着宿主应用可以在执行工具之前，预取并审查模板。
- 这不仅提高了性能，还通过分离静态展示（模板）和动态数据，实现了更好的缓存机制。
- 增强了安全性，让宿主应用对即将渲染的内容有更多控制权。
2. 复用现有的通信协议
设计团队没有发明新的复杂协议，而是利用现有的 MCP JSON-RPC 基础协议进行通信。
- 开发者友好： UI 开发者可以直接使用标准 SDK 构建应用。
- 可审计性： 所有的通信都是结构化的，且可以被记录和审计。
3. 以 HTML 为起点的通用性
目前的规范主要支持 HTML 内容，并在沙盒化的 iframe 中渲染。
- 这保证了通用的浏览器支持。
- 提供了一个业界熟知的安全模型。
- 未来可扩展支持更多内容类型，但目前专注于建立一个清晰的基准。
安全第一的设计原则
允许从服务器加载交互式内容必须非常谨慎。该提案通过多层防御机制来确保安全：
- 沙盒隔离： 所有 UI 内容都在权限受限的 iframe 中运行。
- 内容审查： 宿主应用可以在渲染前检查 HTML 内容。
- 用户授权： 对于 UI 发起的工具调用，宿主可以要求用户进行显式批准。
兼容性与未来
MCP Apps 是一个可选扩展。 现有的实现不需要任何更改即可继续工作。
- 服务器应为启用 UI 的工具提供纯文本回退方案。
- 这意味着即使在不支持 UI 的客户端上，工具也能返回有意义的内容，确保了最大的兼容性。
这一提案凝聚了 OpenAI、Anthropic 以及 MCP-UI 社区工作组的共同努力，目前正处于征求社区反馈的阶段，旨在通过统一的标准推动 AI 交互体验的进化。