MCP Apps交互界面扩展

摘要： MCP Apps 是 MCP 的可选扩展，允许服务器把一个预先声明的 HTML 界面关联到工具。支持该扩展的宿主可将界面嵌入对话并在用户、界面与服务器之间转发交互；不支持的宿主仍可采用工具的文本结果。

Model Context Protocol（MCP）让客户端连接服务器并调用工具、读取资源。很多任务用文本和结构化数据就能完成；但图表筛选、表单填写、地图缩放、媒体播放或分步编辑，若只靠一轮轮文字描述，交互会显得笨重。MCP Apps 为这类场景定义了一个标准扩展：服务器除工具结果外，还可以提供一份 HTML 界面，让兼容的宿主把它嵌入自己的会话中。MCP 核心维护者在 2026 年 1 月 26 日的公告中宣布该扩展正式发布，并称其已适用于生产环境；这是公告当时对发布状态的描述，不代表每个 MCP 客户端都实现了它。官方公告

这里的“Apps”不是把任意网站直接塞进聊天窗口，也不是替代 MCP 的工具与资源模型。本文沿用规范术语：服务器（Server）提供工具和界面资源；宿主（Host）是连接服务器并展示界面的应用；View 指运行在嵌入式界面中的 HTML 页面。MCP 文档里的“client”有双重语境：宿主相对服务器是 MCP 客户端，而 View 在概念上也会通过宿主建立一条 MCP 风格的通信通道。因此，下文用“宿主”和“View”区分两者。SEP-1865；稳定版规范

一项 MCP App 通常由两部分组成：一个普通 MCP 工具，以及一个预先声明的界面资源。资源使用 ui:// URI，例如 ui://weather-server/dashboard，初始规范要求其内容类型为 text/html;profile=mcp-app。工具元数据引用这个 URI，建立工具与 View 的关联。界面模板和运行时数据分开：宿主可以先读取资源，在连接或工具运行前检查模板；工具结果则在执行时传递给 View。稳定版规范：资源发现与工具元数据

典型流程是：宿主连接服务器并获知其工具；模型或用户触发某个工具；宿主读取该工具关联的 ui:// 资源并在受限 iframe 中加载 View。View 在 ui/initialize 握手响应中接收宿主提供的能力与环境上下文；工具输入和工具结果则可通过 ui/notifications/tool-input、ui/notifications/tool-result 等通知传给 View。View 可以把结果渲染成图表或控件，也可以发起后续工具调用、读取资源、向宿主发送消息，或更新模型上下文。宿主负责在 View 与服务器之间转发请求，并决定是否支持某项能力。对于 View 发起的服务器消息（包括 tools/call），规范允许宿主阻止部分请求或要求进一步的用户批准，但没有规定每次工具调用都必须经用户批准；是否拦截或确认取决于宿主实现。官方实现仓库；稳定版规范：宿主中介规则。一次工具调用的输入与返回值也有不同去向。宿主会把完整的工具输入通知 View；工具返回后，View 收到工具结果。规范建议服务器提供适合模型或纯文本客户端阅读的 content，并可用 structuredContent 提供适合界面展示的数据；_meta 可承载额外信息。这样，模型无需读取一大段界面专用数据，纯文本客户端仍能获得可用说明，而图形界面能以结构化数据绘制交互组件。模板负责呈现方式，工具仍负责业务数据与操作逻辑。稳定版规范：工具结果处理

界面与模型之间也有明确的沟通边界。View 可以通过 ui/message 把内容交给聊天界面，也可以用 ui/update-model-context 更新模型可用的上下文；用户在界面里点选某项，并不意味着所有状态都会自动进入模型上下文。具体哪些操作会引发消息、工具请求或上下文更新，由 View 的实现和宿主的处理方式共同决定。这使界面既能提供直接操作，也能选择性地把重要步骤带回对话，而不是把所有界面状态都暴露给模型。稳定版规范：界面消息与上下文更新

初始化时，View 可声明自己支持的显示模式；宿主则提供当下可用的模式、主题、语言、时区和容器尺寸等上下文。View 应检查宿主实际声明的能力，不能假设所有客户端都支持全屏、画中画、链接打开或相同的视觉主题。宿主可在窗口尺寸或主题变化时再发送更新，让界面适配运行环境。这些上下文项使同一份 HTML 有机会适应不同的聊天客户端，但适配的完成度仍由 View 作者和宿主共同决定。规范还列出一组可选的 CSS 自定义属性，用来让界面的文字、颜色、边框和字体与宿主主题协调；宿主可以只提供其中一部分，也可以完全不提供。View 应准备自己的默认样式和回退值，不能假定总有统一组件库或完整设计系统。由此可见，协议标准化的是连接、消息、资源和部分样式接口，而不是强制规定每个 App 的布局或所有宿主的视觉外观。稳定版规范：主题变量

在基础 MCP 连接中，宿主充当服务器的客户端；在界面通信中，View 则通过 postMessage 与宿主交互，并在概念上像一个 MCP 客户端。宿主在两端之间代理通信：View 不是直接连到任意服务器，也不应被理解为拥有宿主的全部权限。协议使用 JSON-RPC 消息表达初始化、工具调用、结果通知、资源读取、界面消息和上下文更新等操作，避免另造一套完全无关的消息格式。对于网页宿主，稳定规范还要求通过不同源的 sandbox proxy 包裹 View，再由代理与内层界面传递消息。稳定版规范：通信协议与 Web 宿主

工具还可以声明可见范围。默认情况下，工具可由模型和 View 使用；标为仅供 app 使用的工具不会出现在模型可调用的工具列表中，但可以让 View 执行刷新、分页或提交表单等界面操作。规范将这类工具限定在同一服务器连接之内，并要求宿主拒绝不符合可见性规则的调用；跨服务器调用不属于 app-only 工具权限。这是一个范围控制机制，并不等于对工具业务逻辑、服务器身份或用户数据作安全担保。稳定版规范：可见性规则

MCP Apps 不是所有 MCP 服务器和客户端都必须实现的核心要求。规范将其定义为可选、向后兼容的扩展，标识符为 io.modelcontextprotocol/ui。宿主在初始化能力中声明支持的内容类型，服务器据此决定是否提供带 UI 的工具；稳定版规范所列的初始类型是 text/html;profile=mcp-app。若宿主没有声明支持，服务器仍应返回有意义的文本或结构化结果，让常规工具路径可用。这样的降级是设计目标，但具体效果仍取决于服务器实现。稳定版初始范围只接收上述 HTML 内容类型；外部网址嵌入和其他界面格式被留作后续扩展，不应把“能显示网页”误认为初始规范已经规定了任意网页的接入方式。服务器也可以在同一工具结果中保留文本说明，确保不显示界面时用户依然能理解结果。稳定版规范：能力协商、MVP 范围与降级

服务器提供的界面可能含有恶意或有缺陷的代码，MCP Apps 因而要求宿主把 View 放在受限 iframe 中。View 与宿主之间的交互通过 postMessage 传输，并采用可检查的 JSON-RPC 消息；宿主应校验来自 iframe 的消息，限制不符合协议的请求，并可审阅预先声明的资源。服务器还能在资源元数据中声明网络连接、静态资源和嵌套 iframe 所需域名；宿主依据这些声明施加内容安全策略（CSP），不能把未声明的域名无条件放行。稳定版规范：安全影响与 CSP

这些措施提供隔离、权限约束和审计入口，不会把风险归零。规范的威胁模型仍把恶意 HTML、越权工具调用、数据外传和钓鱼或社会工程列为需要考虑的情形。宿主的审查、日志、提示和用户审批能力各有实现差异；用户仍应谨慎选择 MCP 服务器，并确认界面要求的能力是否合理。安全模型是宿主和扩展共同落实的工程约束，不应被宣传为“绝对安全”。规范也指出恶意界面可能消耗过多 CPU 或内存，宿主应考虑资源限制；即使界面无法直接越过 iframe 边界，它仍可能呈现误导内容、诱导用户操作或造成资源消耗。稳定版规范：威胁模型与资源消耗风险；官方发布公告：安全模型

扩展已经有正式规范和 SDK，但这不意味着每个 MCP 兼容客户端都能显示相同界面或支持所有交互。而且“支持”并非简单的开关：宿主还会逐项报告可用能力、显示模式、样式变量和沙箱权限。View 应读取初始化结果并对未提供的字段采用回退行为；服务器作者也应在目标宿主上验证实际工具调用与界面交互。稳定版规范：宿主能力与上下文官方 ext-apps 仓库明确提示宿主支持情况各不相同，并指向客户端支持信息；其中的 basic-host 是用于演示和开发的参考宿主，不等同于完整的生产客户端。2026 年 1 月的发布公告列出当时支持 MCP Apps 的 Claude、Goose、VS Code Insiders，以及当周开始支持的 ChatGPT。名单和具体能力可能随产品更新，开发者应在目标宿主的当前文档和实际版本上核对，不应仅凭“支持 MCP”推断它也支持 MCP Apps。官方仓库：宿主支持提示；官方公告：发布时客户端状态

MCP Apps 适合那些确实需要可视化或直接操作的工具：例如在数据查询后筛选图表、在生成内容旁调整参数，或在某个工作流中填写多步表单。对于只需返回一个答案的工具，文本结果可能更简单。它为服务器提供了一种与宿主协作的界面表达方式；界面资源仍由服务器提供，宿主负责承载和中介，模型继续通过 MCP 工具与文本结果参与任务。

SEP-1865 于 2025 年 11 月 21 日创建，MCP 主仓库将其标为 Final；官方扩展仓库把 2026 年 1 月 26 日版本标为 Stable。主仓库同时保留独立的开发草案，因此本文的协议细节以该日期的稳定版规范为准。后续提案、草案、SDK 变化和客户端支持状态都可能继续演进；使用时应核对项目当前规范与宿主文档。SEP-1865 状态；稳定版规范