MCP Apps 详解：让 MCP 工具在聊天里长出交互界面
MCP Apps 详解：让 MCP 工具在聊天里长出交互界面
MCP 工具一直只会"说话"——现在它们学会"长界面"了。
传统 MCP 工具的返回值是文本、图片或结构化数据，由宿主（比如 Claude Desktop）显示在对话里。这够用，但有天花板：用户问"按地区显示销售额"，你返回一串数字；用户要审批一叠报销单，你来回问答"选哪个区域？""实例规格多大？"——文本响应只能走到这么远。
MCP Apps 是 MCP 官方的扩展规范，解决的问题正是这个：让 server 返回交互式 HTML 界面（数据可视化、表单、仪表盘），直接渲染在聊天里。 用户在对话里就能点地图下钻、填表单配置、旋转 3D 模型——不用切出聊天窗口。
这篇文章基于 modelcontextprotocol.io/extensions/apps/overview 官方文档，讲清楚 MCP Apps 是什么、怎么工作、安全模型长什么样、什么时候该用它。
本文提纲
- MCP Apps 是什么：对话内的交互式 UI
- 为什么不直接建个 Web App？
- 工作原理：从工具调用到界面渲染的四步
- 安全模型：沙箱 iframe 与 postMessage
- 什么场景该用（和不该用）
- 框架与客户端支持
- 官方示例与上手路径
MCP Apps 是什么：对话内的交互式 UI
官方定义一句话：在 MCP 宿主（如 Claude Desktop）内渲染的交互式 UI 应用。
它扩展了 MCP 的传统模式：普通工具返回文本/图片/资源/结构化数据，宿主把它们显示为对话的一部分；MCP Apps 允许工具在自己的描述里声明一个交互式 UI 的引用，宿主就地把这个界面渲染出来。
核心模式组合了两个 MCP 原语：
- 一个工具（tool）：在描述里声明它有 UI
- 一个 UI 资源（resource）：把数据渲染成交互式 HTML 界面
举个具体的画面：你接了一个 Excalidraw 的 MCP App，在 Claude 里说"画个系统架构图"，对话流里直接出现可编辑的 Excalidraw 画布——不是截图，不是链接，是活的界面。
为什么不直接建个 Web App？
你完全可以做一个独立 Web 应用然后甩给用户一个链接。但官方文档列了四个独立页面给不了的优势：
1. 上下文保留（Context preservation） 应用活在对话里。用户不用切 tab、不会丢位置、不用回忆哪个聊天线程里有那个仪表盘——UI 就在讨论它的对话旁边。
2. 双向数据流（Bidirectional data flow） 你的应用可以调用 MCP server 上的任何工具，宿主也能把新结果推给你的应用。独立 Web 应用要自己搞 API、认证、状态管理；MCP Apps 用现成的 MCP 模式就把这些全解决了。
3. 与宿主能力集成 应用可以把动作委托给宿主，宿主再去调用用户已经连接的能力和工具（需用户同意）。不是每个应用都要自己实现一遍和所有工具的集成——用户的"连接"是共享的。
4. 安全保证 MCP Apps 跑在宿主控制的沙箱 iframe 里。它们不能访问父页面、偷 cookie、逃出容器。这意味着宿主可以安全地渲染第三方应用，而不必完全信任 server 作者。
文档也坦诚：如果你的用例吃不到这些属性，普通 Web 应用可能更简单。但如果你要和 LLM 对话紧集成，MCP Apps 是更好的工具。
工作原理：从工具调用到界面渲染的四步
当 LLM 决定调用一个支持 MCP Apps 的工具时，发生四件事：
第一步：UI 预加载（UI preloading）
工具描述里包含 _meta.ui.resourceUri 字段，指向一个 ui:// 资源。宿主可以在工具被调用之前就预加载这个资源——这解锁了一个很妙的特性：流式把工具输入传给应用，界面比结果先就位。
第二步：资源获取（Resource fetch）
宿主从 server 获取 UI 资源。这个资源是一个 HTML 页面，通常把 JavaScript 和 CSS 一起打包（为了简单）。应用也可以从 _meta.ui.csp 指定的外部源加载脚本和资源。
第三步：沙箱渲染（Sandboxed rendering）
Web 宿主通常把 HTML 渲染在对话内的沙箱 iframe 里。沙箱限制应用对父页面的访问，保证安全。资源的 _meta.ui 对象可以包含 permissions，申请额外能力（比如麦克风、摄像头），并控制应用能从哪些外部源加载资源。
第四步：双向通信（Bidirectional communication）
应用和宿主之间通过 JSON-RPC 协议通信——它构成 MCP 的一个"方言"：有些请求和通知与核心 MCP 协议共享（如 tools/call），有些相似（如 ui/initialize），大部分是新的、带 ui/ 方法名前缀。应用可以请求工具调用、发消息、更新模型上下文、从宿主接收数据。
一句话总结这个架构：应用与宿主隔离，但通过安全的 postMessage 通道仍然能调用 MCP 工具。
安全模型：沙箱 iframe 与 postMessage
安全是 MCP Apps 设计的重心，因为第三方代码要在宿主里渲染。
强隔离：应用跑在沙箱化的 iframe 里，无法访问父窗口的对象、读宿主的 cookie 或 localStorage、导航父页面、或在父上下文里执行脚本。
通信受限：应用与宿主的所有通信都走 postMessage API——这是浏览器提供的、有明确边界的信息通道。
宿主说了算：宿主控制应用能访问哪些能力。比如宿主可以限制应用能调用哪些工具，或直接禁用 sendOpenLink 能力。沙箱的设计目标就是防止应用逃逸去访问宿主或用户数据。
这个模型对宿主的意义重大：宿主不必完全信任 server 作者，就可以放心渲染第三方应用。 这和浏览器渲染第三方网页的信任模型同源——MCP Apps 把 Web 的这套安全架构搬进了 AI 对话。
什么场景该用（和不该用）
官方给了五类适合的场景，每个都对应"文本响应做不到"的痛点：
| 场景 | 文本响应的尴尬 | MCP App 的做法 |
|---|---|---|
| 复杂数据探索 | "按地区显示销售额"返回一串数字 | 交互地图：点击下钻、悬停看详情、切换指标，无需额外 prompt |
| 多选项配置 | 部署配置要来回问答："选哪个区？""什么规格？""开自动扩容？" | 表单一次看全所有选项，带校验和默认值 |
| 富媒体查看 | PDF、3D 模型、生成图片用文字描述不完 | 直接嵌入查看器：平移、缩放、旋转 |
| 实时监控 | 得反复问"现在状态如何？" | 仪表盘持续更新，数据变化即刷新 |
| 多步工作流 | 审批报销、审代码、triage issue 一件件来很痛苦 | 导航控件 + 动作按钮 + 跨交互持久的状态 |
反过来，如果这些属性你用不上——比如你只是要展示一段静态内容——普通 Web 应用更简单。选择标准不是"新酷炫"，而是交互是否真的需要在对话上下文里发生。
框架与客户端支持
框架：完全自由。 MCP Apps 用自己的 MCP 方言，构建在 JSON-RPC 上（和核心协议一样），传输层是 postMessage 而不是 stdio 或 HTTP。全是标准 Web 原语，所以任何框架都能用，不用框架也行。
官方 SDK（@modelcontextprotocol/ext-apps）里的 App 类是便利封装，不是必需品——想避免依赖或需要更紧控制，可以直接实现 postMessage 协议。
官方 examples 目录有 React、Vue、Svelte、Preact、Solid 和原生 JavaScript 的起步模板，展示各框架体系下的推荐模式——是例子而非要求。
客户端：正在铺开。 目前支持 MCP Apps 的宿主：
- Claude（claude.ai 与 Claude Desktop）
- VS Code GitHub Copilot
- Microsoft 365 Copilot
- Goose
- Postman
- MCPJam
- Archestra.AI
如果你在构建 MCP 客户端、想支持 MCP Apps，有两条路：用 @mcp-ui/client 包（React 组件，渲染和交互 MCP Apps 视图），或基于 SDK 的 AppBridge 模块（处理沙箱 iframe 渲染、消息传递、工具调用代理、安全策略执行）。
官方示例与上手路径
ext-apps 仓库有一批可以直接跑的示例，按用途分类：
- 3D 与可视化：map-server（CesiumJS 地球）、threejs-server（Three.js 场景）、shadertoy-server（着色器效果）
- 数据探索：cohort-heatmap-server（队列热力图）、customer-segmentation-server（客户分群）、wiki-explorer-server
- 商业应用：scenario-modeler-server（情景建模）、budget-allocator-server（预算分配）
- 媒体：pdf-server、video-resource-server、sheet-music-server（乐谱）、say-server（文字转语音）
- 工具类：qr-server、system-monitor-server、transcript-server（语音转文字）
想动手的话，路径很清晰：先读 overview 理解模式 → 选一个框架起步模板 → 参考最接近你场景的官方示例 → 看 build guide。理解工作原理的四个步骤（预加载、获取、渲染、通信）后，剩下的就是普通的 Web 开发了。
参考链接
- MCP Apps 官方 Overview - 本文核心来源
- MCP Apps 完整规范文档 - API 文档、高级模式、完整规范
- ext-apps 仓库 - SDK 与全部官方示例
- MCP 扩展支持矩阵 - 各客户端对扩展的支持情况
- MCP-UI 文档 - 客户端侧渲染组件
- 我的 MCP server 设计最佳实践 - MCP 工具与服务端设计指南
- 我的 Claude 插件构建指南 - MCP Apps 作为插件组件的用法
你会给什么 MCP 工具加上交互界面？评论区聊聊你的想法，觉得有用点个赞让更多人看到。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
