在 AI 聊天机器人中嵌入交互式 UI 元素（如图表、表单或 3D 渲染）是一个复杂的工程挑战。MCP Apps 协议（SEP-1865）通过两项核心设计来应对这一挑战：工具与 UI 资源的双注册模式，以及针对 Web 主机的沙箱 iframe 渲染管线。这两项机制共同实现了标准化、安全且高效的 UI 嵌入方案。
双注册模式：工具与 UI 资源的分离与关联
注册机制的设计原理
MCP Apps 协议要求 MCP 服务器执行两个层面的独立注册操作。第一层是传统的工具注册，通过 tools/list 方法向主机暴露可调用的工具函数；第二层是 UI 资源注册，通过 resources/list 方法声明可用的 ui:// URI 资源。这种分离设计源于对性能优化、安全审查和架构清晰度的综合考量。
工具注册采用标准的 MCP 工具定义格式，但额外包含 _meta.ui 元数据字段。该字段通过 resourceUri 属性引用一个预先声明的 UI 资源 URI，建立工具与渲染模板之间的映射关系。例如，一个天气查询工具可能引用一个交互式仪表板模板，而数据可视化工具则引用图表渲染模板。这种引用机制使得工具定义保持简洁，同时允许 UI 模板独立演进和复用。
元数据驱动的资源发现
UI 资源的声明遵循标准 MCP 资源模式，但强制使用 ui:// URI 方案以区分于普通资源。每个 UI 资源声明包含名称、描述和 MIME 类型（text/html;profile=mcp-app），并通过可选的 _meta.ui 字段配置渲染行为和权限需求。这种声明式配置允许主机在工具执行前预取和缓存 UI 模板，显著降低首次渲染延迟。
工具的可见性通过 _meta.ui.visibility 数组控制，默认值为 ["model", "app"]。该数组决定工具对模型和应用层的可见程度：包含 "model" 时，智能体可以感知和调用该工具；包含 "app" 时，仅允许从 UI 内部发起调用。这种细粒度的访问控制机制使得服务器可以实现仅供 UI 内部使用的辅助功能（如刷新数据、提交表单），而这些功能对智能体保持不可见。
性能与安全优势
双注册模式的核心优势在于模板与数据的分离。UI 模板作为静态资源可以独立缓存和预取，而工具执行产生的数据动态传递给模板填充。这种分离使得主机可以在连接建立阶段预先加载所有 UI 模板，避免工具调用时的额外网络往返。同时，由于 UI 资源在连接阶段已知，主机可以实现安全审查机制，在渲染前检测潜在的恶意内容模式。
沙箱 iframe 渲染管线：双 iframe 架构详解
Web 主机的特殊挑战
对于基于 Web 的聊天主机（如浏览器内嵌的聊天界面），渲染来自第三方 MCP 服务器的 HTML 内容面临严峻的安全风险。恶意服务器可能注入窃取用户数据的脚本、执行未经授权的操作，或尝试突破 iframe 沙箱限制。MCP Apps 协议针对这一场景设计了专用的沙箱 iframe 渲染管线，采用双 iframe 架构实现安全隔离与消息转发。
代理层与视图层的职责划分
渲染管线的核心是外层 sandbox proxy iframe 和内层 view iframe 的协作。Host 页面与 sandbox proxy 必须不同源，这是安全架构的基础前提。Sandbox proxy 被授予 allow-scripts 和 allow-same-origin 权限，但内层 view iframe 的权限由 sandbox proxy 根据资源元数据动态决定。这种权限分层确保即使内层视图被攻破，攻击者也无法直接访问 host 页面的上下文。
Sandbox proxy 的核心职责是消息转发和安全边界控制。它接收 host 发送的 ui/notifications/sandbox-resource-ready 通知，加载指定的 HTML 内容并应用 Content Security Policy 配置，然后创建内层 view iframe 呈现 UI。所有 host 与 view 之间的 JSON-RPC 消息都经过 sandbox proxy 转发，但以 ui/notifications/sandbox- 前缀开头的消息被保留用于沙箱内部控制协议。这种消息过滤机制防止恶意 UI 伪造沙箱控制消息。
CSP 动态构建与权限策略
Sandbox proxy 根据资源声明的 _meta.ui.csp 配置构建 Content Security Policy。连接域（connectDomains）控制 fetch、XHR 和 WebSocket 的目标来源；资源域（resourceDomains）限制静态资源的加载来源；嵌套帧域（frameDomains）决定内层 iframe 可加载的外部来源。如果资源未声明 CSP 配置，协议规定使用严格的默认策略：禁止所有外部连接，仅允许同源脚本和内联样式。
权限策略通过 iframe 的 allow 属性实现。资源元数据中的 permissions 字段声明所需的功能特性（如摄像头、麦克风、地理位置），sandbox proxy 将这些特性映射为 allow 属性值传递给内层 view iframe。这种声明式权限请求机制使得 UI 明确表达其能力需求，而 host 可以据此做出授权决策。
生命周期管理
渲染管线遵循严格的初始化序列。首先，sandbox proxy 准备就绪后向 host 发送 ui/notifications/sandbox-proxy-ready 通知；host 收到后发送 ui/notifications/sandbox-resource-ready，携带 HTML 内容、CSP 配置和权限声明；sandbox proxy 应用 CSP 策略并创建 view iframe；view iframe 初始化 MCP 连接，通过 ui/initialize 请求建立通信；host 返回初始化结果，包含 host capabilities 和上下文信息；view iframe 发送 ui/notifications/initialized 完成握手。
工程实践要点与配置建议
在实际部署中，主机实现者应当注意几个关键配置点。sandbox proxy 的来源选择直接影响安全边界，推荐使用专用域名或唯一生成的子域名。CSP 配置应采用最小权限原则，仅授予资源明确声明的域访问权限。对于敏感场景，可以考虑实现资源哈希校验机制，在渲染前验证 UI 模板的完整性。
对于 UI 开发者，理解双注册模式有助于设计高效的交互流程。模板应当设计为可缓存的静态结构，通过工具调用获取动态数据填充。工具定义应准确声明所需权限，避免因权限不足导致功能异常。良好的实践是在工具描述中明确标注 UI 依赖关系，帮助智能体理解交互式输出的上下文。
MCP Apps 协议的双注册模式与沙箱渲染管线共同构建了一个平衡安全性、性能和开发便利性的 UI 嵌入框架。这一设计体现了协议设计者对 Web 安全模型的深刻理解，也为未来扩展留出了充足的空间。
资料来源：Model Context Protocol - ext-apps GitHub Repository、SEP-1865: MCP Apps Specification (2026-01-26)