什么是 MCP 应用？
MCP 应用（MCP Apps）是 Model Context Protocol 的官方可选扩展，使 MCP Server 能把 Tool 与交互式 HTML UI Resource 关联，并由兼容 Host 在会话中渲染。
快速了解
| 全称 | 模型上下文协议应用 |
|---|---|
| 创建时间 | 2025 年（随 MCP 生态增长而诞生的概念） |
| 规范文档 | 官方规范 |
工作原理
扩展边界
MCP Apps 是首个官方 MCP 扩展，标识为 io.modelcontextprotocol/ui，而不是核心 Tool、Resource 或 Transport 原语。它规范 Server 如何声明交互式 View，以及支持扩展的 Host 如何嵌入它；并不定义应用商店、计费模型、发布者信任计划、业务对象鉴权或所有 Client 的统一支持。
发现与渲染生命周期
Server 发布一个 Tool，并在 _meta.ui.resourceUri 中指向预声明的 ui:// Resource。Host 发现 Metadata、获取 HTML 资源、创建 Sandboxed iframe、完成 ui/initialize 交换，再把 Tool Input 与 Result 交给 View。资源可声明 UI 专用 CSP 和权限请求，但是否授予由 Host 决定。
双向数据流
View 与 Host 通过 postMessage 交换 UI 专用 JSON-RPC。Host 暴露相应能力时，View 可以接收 Tool Input 与结构化结果、请求允许的 Tool Call、发送用户可见消息或更新 Context。Host 始终是执行策略的代理；不能因为 HTML 来自某个 Server，就向 iframe 直接交付凭据或权限。
安全与用户同意
iframe Sandbox 会阻止 View 直接访问 Host DOM、Cookie、Storage 与父级执行环境，但它只是其中一层。Host 仍应校验 Origin 与 CSP、最小化 Capability、对有后果的 UI 发起调用要求用户同意，并在 Server 侧执行认证、对象级鉴权、外链与数据外发限制、消息审计和 View 生命周期结束后的销毁。
兼容与降级
不同 Host 的支持程度不同，扩展也可能独立于核心协议演进。Server 应协商 Capability，固定并测试发布所用扩展与 SDK 版本，保证非 UI Tool Result 仍有意义，并覆盖初始化、Resize、重连、Teardown、权限拒绝、重复操作和不支持扩展的 Host。若体验不依赖会话内嵌，普通 Web 应用通常更简单。
主要特点
- 官方可选扩展：Host 必须声明并实现 UI 支持
- Tool 与 View 绑定：`_meta.ui.resourceUri` 将 Tool 指向预声明的 `ui://` Resource
- 会话内交互：兼容 Host 在 Sandboxed iframe 中渲染 HTML
- 代理式通信：View 通过 `postMessage` 上的 JSON-RPC 通信，不直接访问 Host 或 Server
- 渐进增强：没有 UI 支持时仍保留文本或结构化 Tool Result
- 应用侧控制：身份、鉴权、同意、外发、审计与副作用安全仍由部署系统负责
常见用途
- 在不离开会话的情况下探索图表、地图、表格或其他密集 Tool Result
- 通过表单收集多字段配置，避免反复 Prompt 询问
- 使用交互控件审查文档、媒体、代码差异或生成产物
- 通过进度、日志、筛选器和状态更新监控长任务
- 由 Host 代理每次有后果的 Tool Call，完成审批或分诊流程
示例
Loading code...常见问题
MCP Apps 是官方 MCP 标准的一部分吗？
是。MCP Apps 是官方可选扩展，而不是强制核心能力。Server 与 Host 都支持扩展时才能渲染交互式 View，因此实现必须协商 Capability，并保留非 UI 降级结果。
MCP App 与 MCP Server 有什么区别？
MCP Server 暴露 Tool、Resource 等协议能力；MCP App 是叠加在这些能力上的交互式 UI 扩展：Tool 引用 UI Resource，兼容 Host 渲染其 View。Server 可以不提供 App，一个 Server 也可以提供多个支持 UI 的 Tool。
Host 不支持 MCP Apps 时会怎样？
Tool 应继续返回有用的文本或结构化内容。Server 在依赖 UI 行为前检查协商得到的 Host Capability，客户端只展示普通 Tool Result。这种渐进增强模式避免 UI 支持成为每个 MCP Client 的前提。
Sandbox 能否单独保证 MCP App 安全？
不能。Sandbox 隔离浏览器能力，但 Host 与 Server 仍须执行认证、对象级鉴权、用户同意、CSP、外部 Origin 规则、结果限制、审计日志和副作用幂等。UI 内容与 UI 发起的 Tool 参数仍是不可信输入。
什么时候应改用普通 Web 应用？
当用户需要独立入口、完整浏览器能力、自主导航，或体验与当前会话无关时，普通 Web 应用更合适。MCP Apps 最适用于需要把对话上下文、Tool Result 和紧凑交互流程保留在一起的场景。