工具调用通常把结果重新交给模型，再由模型写成一段文字。对于查天气或读取一个字段，这已经足够；但面对配置面板、数据图表、地图、表单和多项选择，文字会把原本一次点击能完成的动作拆成多轮对话。
MCP Apps 让 MCP 工具可以同时返回一个交互界面。用户不必离开当前对话，也不必逐项告诉模型“把第三个选项改成蓝色”，而是可以直接在界面里查看和操作。
颜色选择器 MCP App 在 Claude 中直接运行
它代表一种不同于“模型生成任意页面”的生成式 UI 路线：应用界面由服务端开发者预先实现，模型负责判断何时调用、传入什么数据，宿主负责安全承载。
#一个工具如何带上一张界面
MCP Apps 在现有 MCP 原语上增加了少量约定。工具在元数据中声明一个 ui:// 资源地址，告诉宿主这次结果可以使用哪张 UI 模板展示。客户端读取资源后，把它加载到沙箱化 iframe，再把工具结果传入界面。
基本链路是：
- 模型根据用户意图调用 MCP 工具。
- 工具返回结构化结果，并关联预先声明的 UI 资源。
- 宿主在沙箱 iframe 中加载应用。
- 宿主与应用通过基于
postMessage的 JSON-RPC 通信。 - 用户操作界面后，应用可以继续调用服务端工具或更新模型上下文。
界面不是截图，也不是一次性渲染结果。它可以读取工具数据、维护交互状态，并把用户已经完成的选择带回对话。
#App API 让人、模型和工具共享状态
如果嵌入界面只能展示数据，它只是更漂亮的工具结果。MCP Apps 的 App API 让界面可以继续参与 Agent 流程。
应用可以接收最初的工具结果，调用同一个 MCP 服务端上的其他工具，也可以向模型上下文写入更新。例如，用户在可视化面板中圈选一组数据后，模型可以知道选中了哪些项目，再继续解释或执行下一步。
这形成一个双向闭环：模型擅长理解模糊意图和编排能力，人擅长在高密度视觉界面中比较、确认和微调，工具负责真实读写外部状态。三者不必被强行压缩成纯文本轮次。
#安全边界比嵌入网页更严格
在对话中运行第三方界面，最大的风险是把宿主权限意外交给应用。MCP Apps 通过多层约束减少这类问题。
界面运行在 sandbox iframe 中，不能任意接触宿主页面；模板资源需要预先声明，客户端可以在加载前审查；应用与宿主之间的消息使用明确的协议，便于记录和审计；敏感工具调用仍由宿主执行，因此可以继续触发用户同意流程。
不过，沙箱并不会自动解决所有风险。宿主仍需限制网络、剪贴板、下载、弹窗等能力，工具服务端也必须验证权限和参数。界面发来的请求不能因为“来自应用”就被默认信任。
#可移植性来自同一份应用包
MCP Apps 的目标之一，是让同一个交互应用可以出现在不同 MCP 客户端中，而不是为每个聊天产品重新开发一遍。
官方文章发布时展示了 Claude 和 Visual Studio Code 中的运行效果，并说明 ChatGPT 的支持正在启动。具体客户端支持会持续变化，但协议层试图稳定的是应用与宿主之间的契约。
同一个颜色选择器 MCP App 在 Visual Studio Code 中运行
真正的可移植性仍取决于宿主实现质量。iframe 尺寸、主题、键盘操作、文件能力和授权体验都可能不同，因此应用需要能力探测、降级路径和无障碍测试，不能假设所有客户端完全一致。
#它与 A2UI 解决的不是同一层问题
MCP Apps 与 A2UI 经常被放在一起讨论，但两者的控制权不同。
MCP Apps 交付的是开发者已经实现好的可执行交互界面，适合复杂、稳定、需要精细状态管理的工具。A2UI 交付的是声明式界面描述，由客户端自己的组件目录渲染，适合让 Agent 根据当前任务动态组合界面。
前者更像“把一个可信应用带进对话”，后者更像“让 Agent 用客户端的设计语言现场组织页面”。实际产品可以同时使用：稳定工具以 MCP App 承载，动态结果以声明式组件呈现，简单信息继续使用文字。
#对话不应该成为所有操作的唯一入口
聊天界面的优势是低门槛和表达自由，但它不擅长承载每一种交互。颜色、时间范围、图表筛选、地图区域和批量选择，本来就更适合直接操作。
MCP Apps 的重要性在于承认这条边界：Agent 产品不必在“传统应用”和“纯聊天机器人”之间二选一。模型可以成为入口与协调者，而成熟的图形界面继续承担它最擅长的高密度交互。
生成式 UI 的未来未必是每次现场写一个页面，也可能是模型在正确时刻，把正确的微型应用带到用户面前。