OpenAI与Anthropic联手力推：MCP Apps提案发布，告别纯文本交互

机器之心报道

编辑：Panda

作为连接 AI 模型与广阔数字生态的「神经中枢」，MCP 协议已然成为智能体（AI Agent）不可或缺的基础设施。然而，长期以来，MCP 的交互仅限于文本和结构化数据，这种「盲人摸象」般的体验限制了更复杂应用场景的落地。

变革正在发生。

近日，MCP 社区正式提出了MCP Apps提案（SEP-1865），旨在填补这一关键拼图：规范对交互式用户界面（UI）的支持，使 MCP 服务器能够直接向主机提供可视化的操作界面。

具体来说，MCP Apps Extension 引入了一种标准化的模式，用于声明 UI 资源、将它们链接到工具，并实现嵌入式接口和主机应用之间的双向通信。

通俗地解释一下：过去的 MCP 就像是只能通过「发短信」来沟通的客服，它只能给你发送文字或数据代码；而 MCP Apps 则是把这个客服升级成了能给你发送「小程序」的智能助理。 试想一下，当你要求 AI 分析服务器日志时，它不再是吐出一堆枯燥的 JSON 文本，而是直接在对话框里变出一个可视化的仪表盘，你甚至可以直接点击图表进行筛选和缩放；当你需要配置参数时，它直接弹出一个表单让你勾选，而不是让你输入复杂的命令。这让 AI 不再仅仅是陪聊，而是真正拥有了类似操作系统图形界面的交互能力。

这一提案一经发布便引发了社区好评：

不仅因为它解决了开发者最迫切的需求，更因为其背后的推手阵容极其豪华 —— 该提案由 OpenAI 和 Anthropic 的 MCP 核心维护者，联手 MCP-UI 创建者及社区主力共同编写。

这强烈的信号表明：MCP Apps 这个基于 MCP-UI 和 OpenAI Apps SDK 的交互标准，极有可能成为未来行业的通用范式。

从「命令行」迈向「图形化」，MCP Apps 将如何重塑 AI 交互体验？让我们来看看详细解读。

交互式界面标准化

目前，MCP 服务器仅限于与主机交换文本和结构化数据。虽然这在许多应用场景下都能很好地满足需求，但当工具需要呈现可视化信息或收集复杂的用户输入时，就会产生阻碍。

官方举了个例子：假设有一个数据可视化 MCP 服务器，它以 JSON 格式返回图表数据。主机应用必须解析这些数据并进行渲染。在这种情况下，处理各种特殊数据会给客户端开发者带来沉重的负担，他们需要构建自己的逻辑来渲染用户界面。随着用户界面需求的增加，例如需要收集用户的多个相关设置，复杂性会急剧上升。或者，如果没有用户界面支持，这些交互将变成笨拙的文本提示和响应交换。

MCP 社区虽然一直在积极探索如何克服这些限制，但由于不同的实现方式采用了不同的约定和架构，服务器难以在不同客户端之间保持一致性。这种缺乏标准化的现状会造成生态系统碎片化的风险。

共同构建中

由 Ido Salomon 和 Liad Yosef 创建并由一个活跃的社区维护的 MCP-UI 项目 ，引领了具有交互式界面的智能体应用的愿景。

该项目开发了将丰富的用户界面作为一流的 MCP 资源交付的模式，证明了智能体应用能够自然地融入 MCP 架构。该项目拥有庞大的社区支持，并提供丰富的 SDK ，已被 Postman、Shopify、Hugging Face、Goose 和 ElevenLabs 等领先公司和项目采用。

OpenAI Apps SDK 进一步验证了对话式 AI 界面对丰富用户界面体验的需求。该 SDK 使开发者能够以 MCP 为基础，在 ChatGPT 内部构建丰富的交互式应用。为了确保互操作性，并在整个生态系统中建立一致的安全性和使用模式，Anthropic、OpenAI 和 MCP-UI 也正在合作开发官方的 MCP 交互式界面扩展。

MCP Apps Extension 规范

MCP 社区博客表示：「我们正在为 MCP 中的 UI 资源提出一项规范，但其影响远不止于一系列模式转移。MCP Apps Extension 正逐渐演变成一个智能体应用运行时（agentic app runtime）：为 AI 模型、用户和应用之间全新的交互奠定基础。」

该提案有意保持精简，首先从核心模式入手，MCP 社区计划随着时间的推移逐步扩展。

下面介绍其关键设计决策。

预先声明的资源

UI 模板是具有 ui:// URI 方案的资源，可在工具元数据中引用。

// Server registers UI resource

uri: "ui://charts/bar-chart",

name: "Bar Chart Viewer",

mimeType: "text/html+mcp"}

// Tool references it in metadata

name: "visualize_data_as_bar_chart",

description: "Plots some data as a bar chart",

inputSchema: {

type: "object",

properties: {

series: {type: "array", items: ....}

},

_meta: {

"ui/resourceUri": "ui://charts/bar-chart",

这种方法使主机能够在工具执行前预取和审查模板，从而提高性能和安全性。它还将静态呈现（模板）与动态数据（工具结果）分离，从而实现更好的缓存。

MCP 传输通信

UI 组件无需创建自定义消息协议，而是通过 postMessage 使用现有的 MCP JSON-RPC 基础协议与主机通信。这意味着：

• UI 开发者可以使用标准的 @modelcontextprotocol/sdk 来构建他们的应用。
• 所有沟通都结构化且可审计。
• 未来的 MCP 功能将自动与 UI 扩展程序协同工作。

从 HTML 开始

初始扩展规范仅支持在沙盒化的 iframe 中渲染的 text/html 内容。这提供了以下功能：

• 通用浏览器支持
• 易于理解的安全模型
• 屏幕截图和预览生成功能
• 为未来的扩展奠定清晰的基础

其他内容类型，例如外部 URL、远程 DOM 和原生小部件，都将在未来的版本中实现。

安全第一

从 MCP 服务器托管交互式内容需要谨慎考虑安全性。该方案通过多层措施来解决这个问题：

• iframe 沙盒 ：所有 UI 内容都在权限受限的沙盒 iframe 中运行。
• 预先声明的模板 ：主机可以在渲染之前查看 HTML 内容。
• 可审计消息 ：所有 UI 与主机之间的通信都通过可记录的 JSON-RPC 进行。
• 用户同意 ：主机可以要求用户明确批准通过用户界面发起的工具调用。

这些缓解措施可以构建针对恶意服务器的纵深防御，同时保持开发人员所需的灵活性。

向后兼容性

MCP Apps 是一个可选扩展。现有实现无需更改即可继续运行，主机可以根据自身情况逐步采用 UI 支持。服务器应为所有启用 UI 的工具提供纯文本回退方案，并在 UI 不可用时返回有意义的内容，以便同时服务于支持 UI 和仅支持文本的主机。

你也可以参与进来！

为了演示规范提案中描述的模式和类型，目前该社区已经构建了早期访问 SDK：

https://github.com/modelcontextprotocol/ext-apps

MCP-UI 客户端和服务器 SDK 均支持这些模式。

如果你有兴趣，也可参与贡献：

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865

https://x.com/MCP_Community/status/1992109099434353045

https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/