MCP-UI-Org/mcp-ui 是什么？

mcp-ui 是一套实现 MCP Apps 标准的 SDK，让 AI 工具能返回可交互的 HTML 界面。本文分析其资源模型、渲染器与适配层，并指出它在沙箱与安全上的取舍。

MCP-UI-Org/mcp-ui 可以商用吗？

可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

MCP-UI-Org/mcp-ui 还在维护吗？

在维护。仓库最近一次提交在 70 天前。

MCP-UI-Org/mcp-ui 是用什么编程语言写的？

主要是 TypeScript（依据 GitHub 的语言统计）。

mcp-ui 评测：MCP Apps 标准下的 UI SDK 实战分析

秒懂

它是什么？: mcp-ui 是一套实现 MCP Apps 标准的 SDK，让 AI 工具能返回可交互的 HTML 界面。本文分析其资源模型、渲染器与适配层，并指出它在沙箱与安全上的取舍。
适合谁用？: mcp-ui 适合已经在用 MCP 构建工具、并且希望把结果展示从纯文本升级为可交互界面的团队，尤其是那些愿意跟随 MCP Apps 规范演进的 TypeScript 项目。Ruby 和 Python 服务端支持让非 Node 后端也能生成 UI 资源。
能商用吗？: 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 70 天前。
用什么语言写的？: 主要是 TypeScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · MCP-UI-Org/mcp-ui

它解决的问题：让 AI 工具的输出不再只是文本

在 MCP 的标准流程里，工具返回内容后，交互就结束了。mcp-ui 在工具定义中增加了一个链接字段 `_meta.ui.resourceUri`，指向一个独立的 UI 资源。宿主发现这个字段后，通过 `resources/read` 获取 HTML，再渲染出来。这样工具的逻辑和界面被拆开，服务端只负责生成 HTML，客户端负责展示。这个设计把 UI 的传输和渲染解耦，但也意味着宿主必须实现额外的协议步骤，不是所有 MCP 客户端都支持。

UIResource 的线格式：HTML 装进资源里

需要注意的是，UIResource 本身并不包含如何渲染的指令。它只是一段带 MIME 类型的 HTML。真正的渲染逻辑在客户端 SDK 里，由 `AppRenderer` 或 `UIResourceRenderer` 组件处理。所以服务端开发者只需要关心生成正确的 HTML 字符串，不需要知道宿主端如何展示。

AppRenderer 与 UIResourceRenderer：两条渲染路径

`UIResourceRenderer` 则是为旧版 MCP-UI 宿主准备的。这类宿主把 UI 资源直接嵌入在工具响应里，而不是通过独立的 resourceUri 链接。所以这个组件只接受一个 `resource` 对象，并通过 `onUIAction` 回调来处理 UI 发出的动作。它还提供了一个 Web Component 形式，可以直接在纯 HTML 页面中使用，不需要 React 环境。两条路径的存在反映了生态的过渡状态：新规范用资源链接，旧模式用内嵌内容。如果你的宿主不支持 MCP Apps，你只能走旧路径，这限制了 UI 资源的复用性。

UI Action：让 HTML 片段能调用工具

这种设计把交互逻辑放在宿主端，而不是 UI 片段内部。好处是 UI 片段不需要知道宿主如何执行工具，它只需要发出请求。坏处是每个宿主都需要实现自己的 action 处理逻辑，否则 UI 只能看不能用。对于服务端开发者，这意味着你不仅要生成 HTML，还要确保宿主端能正确处理你发出的 action 类型。文档提到 action 包括 tool、prompt、link、notify 和 intent 等类型，但具体参数和触发方式需要查阅规范。

平台适配器：跨宿主兼容的代价

这是一个重要的但文档不完整的部分。如果你打算让 UI 组件在多个宿主上运行，适配器是否成熟会直接影响工作量。但既然文档没有给出具体适配器列表，你只能假设目前适配层还在演进中。对于只针对单一宿主的项目，适配器可能无关紧要。对于跨宿主分发 UI 组件的开发者，这可能是最大的不确定性。建议在选型前直接查看仓库中适配器的源码，确认它覆盖了哪些宿主。

安装与运行：从服务端到客户端的代码路径

客户端使用 `@mcp-ui/client`。在 React 中，直接渲染 `<AppRenderer>`，传入 client 和 toolName 等属性。如果使用 Web Component，可以用 `<ui-resource-renderer>` 标签，但需要把 resource 作为 JSON 字符串传入。服务端也有 Ruby 和 Python 的 SDK，分别对应 `mcp_ui_server` gem 和 `mcp-ui-server` PyPI 包，说明服务端生成 UI 资源不限于 TypeScript。但客户端渲染目前只有 TypeScript 和 Web Component 两种方式。

安全与沙箱：iframe 并非万无一失

这是一个需要警惕的地方。MCP 工具可能来自第三方，它们返回的 HTML 可能包含恶意脚本。如果 iframe 的沙箱设置不当，这些脚本可能访问宿主的数据。mcp-ui 把安全责任部分推给了宿主，因为 `sandbox` 的 URL 是由宿主提供的。如果你的代理只是简单转发请求，而没有做内容安全策略或请求过滤，那么 UI 片段理论上可以发起任意网络请求。文档中没有给出默认的安全配置，这可能是生产环境部署前需要自行加固的部分。

维护成本与许可：Apache-2.0 下的活跃开发

许可采用 Apache-2.0，这对商业使用比较友好，允许修改和分发，但需要保留版权声明。项目还提供了 Ruby 和 Python 的 SDK，意味着服务端生态有跨语言支持，但客户端生态仍然集中在 TypeScript。如果你需要在一个非 JavaScript 的宿主中渲染 UI，目前只能通过 Web Component 方式，这可能需要额外的胶水代码。整体来看，维护成本取决于你是否紧跟 MCP Apps 规范的变化，因为规范本身还在演进中。

编辑结论

mcp-ui 适合已经在用 MCP 构建工具、并且希望把结果展示从纯文本升级为可交互界面的团队，尤其是那些愿意跟随 MCP Apps 规范演进的 TypeScript 项目。Ruby 和 Python 服务端支持让非 Node 后端也能生成 UI 资源。不适合那些只需要简单表单或图表、不想引入 iframe 沙箱和资源读取流程的项目。在采用前，先确认你的宿主端是否实现了 MCP Apps 标准，特别是 `_meta.ui.resourceUri` 的解析和 `resources/read` 的调用，否则客户端 SDK 的自动渲染会失效。另外要检查沙箱配置的 URL 是否指向你信任的代理，因为 HTML 内容在 iframe 中执行，跨域通信的安全边界取决于这个代理的设置。

官方来源

社区笔记