扩展概览

Model Context Protocol 的可选扩展

MCP 扩展

MCP 扩展是对规范的补充性可选内容，定义了核心协议之外的能力。扩展可用于实现模块化功能（例如身份验证等独立特性）、专用功能（例如特定行业的逻辑）或实验性功能（例如为可能纳入核心而孵化中的特性）。

扩展通过唯一的扩展标识符进行标识，其格式为：{vendor-prefix}/{extension-name}，例如 io.modelcontextprotocol/oauth-client-credentials。标识符遵循与 _meta keys 相同的规则，但必须带有前缀。官方扩展使用 io.modelcontextprotocol 作为厂商前缀。

TIP

如果你正在构建第三方扩展，请使用你拥有的反向域名作为厂商前缀以避免冲突（类似于 Java 包命名）。例如，拥有 example.com 的公司会使用 com.example/ 作为其前缀（例如 com.example/my-extension）。

官方扩展仓库

官方扩展位于 Model Context Protocol GitHub organization 中，仓库名称带有 ext- 前缀。

MCP 授权扩展

modelcontextprotocol/ext-auth

核心规范之外的补充授权机制扩展。

Extension	Description
OAuth Client Credentials	OAuth 2.0 client credentials flow for machine-to-machine authentication.
Enterprise-Managed Authorization	Framework for enterprise environments requiring centralized access control.

MCP Apps

modelcontextprotocol/ext-apps

用于对话式 MCP 客户端中交互式 UI 元素的扩展。

Extension	Description
MCP Apps	Allows MCP Servers to display interactive UI elements (charts, forms, video players) inline within conversations

要开始构建 MCP Apps，请参阅快速入门指南或阅读完整的 MCP Apps 文档。

MCP Tasks

Extension	Description
MCP Tasks	Asynchronous task execution for long-running operations, with polling, mid-flight input, and durable handles.

Skills over MCP

modelcontextprotocol/ext-skills

从 MCP 服务端发现并读取 Agent Skills。

Extension	Description
Skills over MCP	Discover workflow instructions and read supporting files through MCP resources.

请参阅 Skills 概览以开始使用，并查看客户端支持矩阵了解实现支持情况。

实验性扩展

实验性扩展为工作组和兴趣小组提供了一条孵化路径，以便在正式提交 SEP 之前对扩展概念进行原型验证和协作。

实验性扩展仓库位于 MCP GitHub organization 中，名称带有 experimental-ext- 前缀（例如 experimental-ext-interceptors）。

基本规则

每个实验性扩展都需要与一个工作组或兴趣小组关联
仓库和已发布的包需要明确标示其实验性状态（例如在 README 和包名中）
核心维护者保留对实验性扩展仓库的监督权，包括归档或移除它们的权力

晋升为官方状态

要将实验性扩展提升为官方状态，需要经过标准的 SEP 流程（Extensions Track）。欢迎引用实验性仓库以及你在孵化期间构建的任何参考实现，以证明该扩展的实用性。

创建扩展

官方扩展的生命周期遵循基于 SEP 的流程。完整细节请参阅 SEP-2133: Extensions。

提议：使用标准 SEP 指南在主 MCP 仓库中创建一个 SEP，类型为 Extensions Track。
实现：在官方 SDK 中构建至少一个参考实现——这是 SEP 进入评审阶段的必要条件。
评审：核心维护者评审 SEP，并对是否纳入拥有最终决定权。
发布：一旦获批，提交 PR 将扩展添加到扩展仓库中。
采用：此后，其他客户端、服务端和 SDK 也可以实现该扩展。

要求

扩展规范需要使用 RFC 2119 语言（MUST、SHOULD、MAY）
扩展必须关联一个工作组或兴趣小组

SDK 实现

SDK 可以选择实现扩展，但这不是协议一致性所必需的。SDK 维护者完全自主决定支持哪些扩展。在 SDK 支持扩展的情况下，SDK 文档应列出所支持的扩展。

NOTE

扩展始终默认禁用，需要开发者显式选择启用。

演进

扩展独立于核心协议演进。更新由扩展仓库维护者管理，不需要核心维护者审查。

话虽如此，向后兼容性很重要。当你需要更改扩展时，优先在扩展设置对象内使用能力标志或版本控制，而不是创建新的扩展标识符。如果破坏性变更不可避免，请使用新的标识符（例如 io.modelcontextprotocol/my-extension-v2）。

破坏性变更是指任何会导致现有实现失败或行为异常的修改，包括：

删除或重命名字段
更改字段类型
改变现有行为的语义
添加新的必填字段

协商

客户端和服务端在各自的能力声明中的 extensions 字段里声明对扩展的支持。

客户端能力

客户端在每个请求的 _meta["io.modelcontextprotocol/clientCapabilities"] 中声明扩展支持：

json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/ui": {
            "mimeTypes": ["text/html;profile=mcp-app"]
          }
        }
      },
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleClient",
        "version": "1.0.0"
      }
    }
  }
}

服务端能力

服务端在 server/discover 响应中声明扩展支持：