Model Context Protocol（MCP）自发布以来，已成为 AI 智能体与外部工具交互的事实标准。然而，传统的 MCP 工具只能返回文本和结构化数据，这一局限性在需要可视化交互的场景中尤为突出 —— 图表、表单、视频播放器、数据看板等交互式 UI 元素无法直接嵌入对话界面。MCP Apps 协议（SEP-1865）的出现，正是为了解决这一核心痛点，它提供了一套标准化的机制，允许 MCP 服务器向支持协议的客户端交付交互式用户界面，并在沙箱环境中安全渲染。
核心问题：文本交互的局限性
在传统的 MCP 架构中，工具调用的结果以结构化数据或纯文本形式返回给大语言模型，再由模型生成描述性回复。这种模式在信息查询类场景中运作良好，但面对复杂数据可视化时捉襟见肘。当用户询问「本季度销售趋势如何」时，理想体验是直接展示一个可交互的折线图，用户可以悬停查看具体数值、切换时间维度或筛选特定品类。然而，传统方案只能返回一段 JSON 数据，模型将其转化为文字描述，用户无法与数据进行真正的交互。
这一局限性催生了两个并行的社区探索：MCP-UI 项目和 OpenAI 的 Apps SDK。前者在社区驱动下发展出了双向通信模型和多种内容类型，后者于 2025 年 11 月推出，验证了对话式 AI 中富 UI 体验的市场需求。两者虽然实现路径相似，但各自为政导致了生态碎片化 —— 开发者需要为不同客户端维护适配层，安全审查标准不一，能力协商机制缺失。MCP Apps 协议正是在这一背景下诞生，它将两种探索的精华整合为统一规范，同时保持向后兼容和扩展性。
技术架构：UI 资源的声明与发现
MCP Apps 协议的核心设计理念是将 UI 元素建模为可声明的资源（resources），通过 ui:// URI 方案进行标识，并与工具定义建立显式关联。这一设计选择背后有深刻的工程考量。
在工具定义阶段，开发者需要在工具的 uiResources 字段中声明该工具可能渲染的 UI 界面。每个 UI 资源包含 URI、描述性元数据以及可选的初始化参数模板。例如，一个「显示销售趋势图」的工具可能声明一个指向 ui://sales-trend-chart 的资源，附带图表类型、时间范围等默认参数。当大语言模型决定调用该工具时，主机（Host）在执行前即可预取 UI 模板，实现渲染准备与工具执行的并行化。这种 predeclared resources 模式相较于 MCP-UI 的嵌入式资源（资源直接嵌入工具返回结果）具有明显优势：模板与数据分离便于缓存策略实施，主机可在渲染前对 HTML 内容进行安全审查，且工具调用的语义更加清晰 —— 返回结果明确分为供模型阅读的数据和供用户查看的界面。
协议当前聚焦于 HTML 内容类型（text/html;profile=mcp-app），这一选择平衡了能力覆盖与实现复杂度。HTML 是 Web 平台的通用语言，几乎所有现代应用都能渲染；其安全模型成熟，iframe 沙箱机制提供了可靠的隔离基础；同时，HTML 内容易于生成预览缩略图，便于在对话历史中展示 UI 摘要。协议已预留扩展机制，未来可支持外部 URL 嵌入、远程 DOM 内容等更丰富的内容类型。
沙箱安全模型：多层防护机制
允许来自不受信任 MCP 服务器的代码在用户浏览器中执行，显然需要严密的安全设计。MCP Apps 协议构建了多层防护体系，覆盖资源声明、渲染隔离、通信审计和用户授权四个环节。
渲染隔离是安全模型的核心。所有 UI 内容必须在沙箱化的 iframe 中渲染，协议建议主机启用以下 sandbox 属性：allow-scripts 需严格审查后授予、allow-same-origin 谨慎使用、allow-forms 按需开启、allow-popups 原则上禁用、allow-top-navigation 必须禁用以防止导航劫持。更关键的是，UI 代码无法直接访问主页面 DOM 或 LocalStorage，实现了与聊天主界面的强隔离。主机应配置 Content Security Policy（CSP），限制资源加载来源，防止 UI 内嵌的脚本发起未授权的网络请求。
通信审计机制确保所有 UI 与主机之间的交互可追溯。UI 通过 MCP JSON-RPC 协议与主机通信，调用工具或订阅资源变更时，所有请求和响应均通过 MCP 的日志机制记录。这一设计不仅服务于安全审计，也为调试和问题排查提供了完整上下文。当 UI 尝试执行敏感操作（如调用具有副作用的工具）时，主机可配置为要求用户显式确认，实现「人在回路」的安全控制。
用户授权是最后一道防线。协议建议主机在首次加载某个 MCP 服务器的 UI 时，向用户展示清晰的安全提示，说明该 UI 将能执行的操作范围。某些主机可能选择要求用户逐次确认 UI 发起的工具调用，而非预先授权所有操作。协议同时引入了 externalIframes 能力标识，允许服务器声明其 UI 可能嵌入外部来源的内容，主机可据此实施更细粒度的策略。
双向通信：JSON-RPC 的复用与扩展
MCP Apps 协议的通信层直接复用 MCP 的 JSON-RPC 基础设施，而非另起炉灶设计自定义消息协议。这一决策具有多重考量：现有 MCP SDK 无需改动即可支持 App 通信，开发者无需学习新的 API 风格，时间超时、错误传播、批量请求等 JSON-RPC 高级特性开箱即用。
通信方向分为两类。主机到 UI 的通知（notifications）用于传递工具执行结果、订阅的资源变更事件或用户交互状态更新。当工具调用完成后，主机将结果通过 app/data 通知发送至 UI，UI 据此更新渲染。UI 到主机的请求（requests）主要用于调用工具或读取资源。UI 通过 tools/call 方法发起工具调用，主机执行后返回结果；UI 还可订阅特定资源的变化通知，实现响应式更新。
值得注意的是，UI 发起的工具调用对模型而言是「透明」的 —— 模型看到的是工具调用的结果（通过标准的 tools/listChanged 和 tools/call 消息），而非 UI 内部的状态变化。这一设计保持了 MCP 的核心抽象：模型始终通过工具与外界交互，不会因 UI 的存在而需要理解不同的交互范式。同时，UI 可以访问 MCP 的完整能力集，包括调用其他工具、读取资源、发送采样请求等，形成了丰富的交互可能性。
SDK 分层与工程实践
MCP Apps 协议提供了分层的 SDK 支持，分别面向应用开发者、主机开发者和智能体（Agent）开发者。
对于构建 UI 应用的开发者，官方提供了 @modelcontextprotocol/ext-apps 核心包和 @modelcontextprotocol/ext-apps/react React 集成包。核心包定义了与主机通信的基础 API，包括连接初始化、消息发送与接收、工具调用、资源订阅等。React 钩子包在此基础上提供了 useMcpTool、useMcpResource 等声明式接口，UI 代码可以像调用本地函数一样调用远程 MCP 工具，状态变更自动触发组件重渲染。SDK 支持 React、Vue、Svelte、Preact、Solid 和 Vanilla JS 六种框架，官方示例仓库提供了各框架的 starter template，开发者可快速起步。
对于实现聊天客户端的主机开发者，官方提供 @modelcontextprotocol/ext-apps/app-bridge 包。该包封装了 iframe 通信的底层细节，包括协议握手、消息路由、连接状态管理、错误处理等。主机开发者只需配置 iframe 元素，实例化 AppBridge，SDK 自动处理与 UI 的双向通信。对于需要深度定制的主机，SDK 的内部实现也作为参考设计公开。此外，社区项目 MCP-UI 提供了功能更完整的主机框架，已被 Postman、HuggingFace、Shopify、Goose、ElevenLabs 等平台采用。
官方仓库还提供了丰富的示例服务器，覆盖地图渲染（map-server）、3D 场景（threejs-server）、PDF 查看（pdf-server）、系统监控（system-monitor-server）、数据可视化（cohort-heatmap-server、customer-segmentation-server）等典型场景。这些示例均可通过 npx 直接运行，或配置到 Claude Desktop 等 MCP 客户端中本地体验。
能力协商与向后兼容
作为 MCP 的可选扩展，MCP Apps 协议通过 MCP 的能力协商机制（Capability Negotiation）声明支持。服务器在初始化握手时，通过 capabilities.extensions.apps 字段声明其 UI 支持；客户端若不支持该扩展，则忽略相关能力声明，服务器仍可提供传统工具。协商机制确保了渐进式部署 —— 早期采用者可以自由实验，不影响现有功能。
协议版本管理采用日期后缀命名（如 2026-01-26），当前稳定版本为 2026 年 1 月 26 日发布的规范。草案版本（draft）中包含尚在讨论的新特性，如外部 iframe 嵌入能力。开发者在实现时应关注规范演进，及时适配新特性。
实施建议与工程参数
对于计划采用 MCP Apps 协议的开发团队，以下参数和策略可作为实施参考。
在主机端 iframe 配置方面，推荐的 sandbox 属性组合为 allow-scripts allow-same-origin allow-forms，明确禁用 allow-popups 和 allow-top-navigation-by-user-activation。若 UI 需要发起跨域请求，应通过主机的代理层转发，避免直接放宽 CSP。UI 加载完成后，主机应验证 iframe 的 postMessage 消息来源仅限预期域名，防止消息注入攻击。
在服务器端 UI 开发方面，建议将 UI 模板与工具逻辑解耦，模板可独立开发、测试和缓存。UI 代码应处理连接中断场景，实现重连逻辑和状态恢复。敏感操作（如数据修改、支付确认）应通过用户确认机制而非自动执行，UI 应清晰展示操作影响范围。
在监控与运维方面，主机应记录 UI 相关消息的完整日志，包括消息类型、时间戳、来源标识、载荷摘要。异常模式（如高频工具调用、异常资源请求）应触发告警。UI 渲染错误应捕获并上报，便于服务端定位问题。
MCP Apps 协议为 AI 聊天机器人引入了真正的交互式 UI 能力，其标准化设计降低了生态碎片化风险，分层 SDK 简化了开发门槛，多层安全机制确保了可信执行。随着越来越多的客户端和服务器采用这一协议，AI 应用的交互体验将迎来质的飞跃。
资料来源：