MCP 扩展

MCP 扩展是规范的可选补充，用于定义核心协议之外的能力。扩展可以提供模块化功能（例如身份验证等独立功能）、专用功能（例如特定行业的逻辑）或实验性功能（例如正在孵化、未来可能纳入核心协议的功能）。

扩展使用唯一的_扩展标识符_进行标识，格式为 {vendor-prefix}/{extension-name}，例如 io.modelcontextprotocol/oauth-client-credentials。标识符遵循与 _meta 键相同的规则，但必须包含前缀。官方扩展使用 io.modelcontextprotocol 作为供应商前缀。

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

官方扩展仓库

官方扩展位于 Model Context Protocol GitHub 组织中，仓库名称以 ext- 为前缀。

MCP 授权扩展

modelcontextprotocol/ext-auth

提供核心规范之外的补充授权机制。

扩展	说明
OAuth 客户端凭据	用于机器间身份验证的 OAuth 2.0 客户端凭据流程。
企业托管授权	面向需要集中式访问控制的企业环境的框架。

MCP Apps

modelcontextprotocol/ext-apps

为对话式 MCP 客户端提供交互式 UI 元素的扩展。

扩展	说明
MCP Apps	允许 MCP 服务器在对话中以内联方式显示交互式 UI 元素（图表、表单、视频播放器）

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

MCP Tasks

扩展	说明
MCP Tasks	面向长时间运行操作的异步任务执行，支持轮询、执行中输入和持久句柄。

基于 MCP 的 Skills

modelcontextprotocol/ext-skills

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

扩展	说明
基于 MCP 的 Skills	通过 MCP 资源发现工作流指令并读取其支持文件。

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

实验性扩展

实验性扩展为工作组和兴趣组提供孵化路径，使其能在正式提交 SEP 之前验证想法原型并协作完善扩展概念。

实验性扩展仓库位于 MCP GitHub 组织中，名称以 experimental-ext- 为前缀（例如 experimental-ext-interceptors）。

基本规则

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

晋升为官方扩展

实验性扩展要晋升为官方扩展，必须经过标准 SEP 流程（扩展轨道）。你可以引用实验仓库以及孵化期间构建的任何参考实现，以证明该扩展的实用性。

创建扩展

官方扩展的生命周期遵循基于 SEP 的流程。完整细节请参阅 SEP-2133：扩展（英文）。

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

要求

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

SDK 实现

SDK 可以选择实现扩展，但协议一致性并不要求这样做。SDK 维护者可以完全自主决定支持哪些扩展。SDK 支持扩展时，应在 SDK 文档中列出所支持的扩展。

扩展始终默认禁用，必须由开发者明确选择启用。

演进

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

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

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

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

协商

客户端和服务器在各自能力声明的 extensions 字段中公布其扩展支持情况。

客户端能力

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

{
  "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 响应中公布扩展支持情况：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "extensions": {
        "io.modelcontextprotocol/ui": {}
      }
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "ExampleServer",
        "version": "1.0.0"
      }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

每个扩展都会规定其设置对象的模式；空对象表示没有设置。

优雅降级

如果一方支持某个扩展而另一方不支持，支持扩展的一方需要回退到核心协议行为；如果该扩展不可缺少，则应使用适当的错误拒绝请求。

在扩展中记录预期的回退行为是一项良好实践。例如，提供 UI 增强工具的服务器仍应向不支持 UI 扩展的客户端返回有意义的文本内容。另一方面，要求使用特定身份验证扩展的服务器可以拒绝不支持该扩展的客户端连接。

构建 MCP App 扩展支持矩阵