你让 AI 帮你规划预算，它通常会回一张文字清单。可真正做决定时，你还得反复修改数字、比较方案。如果聊天框里直接出现一块预算面板，能拖动金额、切换选项，结果随之更新，事情就顺手多了。MCP Apps 想解决的正是这个落差：让 AI 工具不只“告诉你答案”，还能把可操作的小应用直接交到对话里。
目前公开信息主要来自 modelcontextprotocol 的项目仓库，属于单一机构信源。它说明了规范和开发方式，但还不足以证明实际采用规模或不同客户端中的一致体验。
从工具回复，走向应用界面
MCP（Model Context Protocol）是一套开放协议，用来统一 AI 客户端连接外部工具和数据源的方式。按这套协议提供工具、资源或提示的程序，叫作 MCP 服务器。
过去，MCP 工具主要返回文字或结构化数据。这适合查询天气、读取记录等任务，却难以承载需要连续操作的场景。比如填写表单、查看可交互图表、调整设计画布，单靠一轮轮文字问答会很笨重。
据 modelcontextprotocol 官方仓库介绍，MCP Apps 是 MCP 核心规范的一项扩展。它为服务器向聊天界面交付嵌入式交互 UI 提供统一方式。这里的 UI，就是用户能点击、输入和操作的界面。官方列出的形态包括图表、表单、仪表盘、设计画布和视频播放器。
换句话说，聊天消息不再只是报告结果的纸张，也可以成为操作结果的工作台。
一块界面怎样进入聊天框？
整个过程可以拆成四步。
首先，MCP 服务器在工具定义中声明一个 ui://resource。它指向配套的 HTML 界面，可以理解为工具随身附带的一张“界面说明书”。随后，大语言模型调用服务器上的工具。宿主——也就是承载对话和工具的客户端——再取得这份资源，把它显示在一个沙箱化的 iframe 中。
iframe 是网页里嵌入另一块网页内容的容器；“沙箱化”则表示这块内容受到隔离和权限限制。这样做的重点，是让外部界面能进入聊天窗口，同时不直接获得宿主页面的全部能力。
界面也不是静态贴图。官方说明中，宿主可通过 notifications（通知消息）把工具数据传给 UI；UI 又能经宿主调用其他工具。比如一个预算面板收到计算结果后可以更新图表，用户修改金额时，也能再次触发计算。数据和操作因此能够双向流动。
它为什么值得现在关注？
这次变化的关键，不是聊天框多了一种展示样式，而是工具的交付单位变了。以前，工具完成调用后主要交付一段回答；现在，它可以交付一个留在上下文中、还能继续操作的 View（交互视图）。AI 负责理解意图和发起调用，界面负责呈现状态、接收精确输入，两者各做擅长的部分。
项目还提供 @modelcontextprotocol/ext-apps SDK。SDK 是帮助开发者接入某项能力的一组代码库、工具和示例。官方把使用者分为三类：制作交互 View 的应用开发者、把 View 嵌入聊天客户端的宿主开发者，以及给 MCP 工具登记 UI metadata（界面元数据）的服务器作者。
仓库同时提供四个 Agent Skills：从零搭建应用的 create-mcp-app、迁移 OpenAI App 的 migrate-oai-app、给现有 MCP 服务器增加界面的 add-app-to-server，以及把已有网页应用改成网页与 MCP App 混合形态的 convert-web-app。这表明项目不只在定义格式，也试图覆盖新建、迁移和改造现有应用的路径。
局限与未知
- 官方称界面可在 Claude、ChatGPT 和其他兼容客户端中渲染，但同时明确提醒宿主支持情况各异。不能据此理解为所有版本或所有环境都已支持。
- 仓库没有提供完整的受支持宿主实现，示例中的
basic-host主要用于参考。项目给出的演示和安装方式，也不能证明生产环境中的稳定性或采用规模。 - 仓库列出日期为 2026 年 1 月 26 日的 Stable 规范，同时保留开发中的 draft。后续草案会如何变化、不同宿主会实现到什么程度，现有材料没有说明。