MCP 扩展

MCP 扩展是规范的可选补充，定义了核心协议之外的能力。扩展支持模块化（例如，身份验证等独立功能）、专业化（例如，特定行业的逻辑）或实验性（例如，正在孵化以潜在纳入核心的功能）的功能。扩展使用唯一的 extension identifier 进行标识，其格式为：{vendor-prefix}/{extension-name}，例如 io.modelcontextprotocol/oauth-client-credentials。标识符遵循与 _meta keys 相同的规则，但必须带有前缀。官方扩展使用 io.modelcontextprotocol 供应商前缀。

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

官方扩展仓库

官方扩展位于模型上下文协议 GitHub 组织内，仓库名称带有 ext- 前缀。

MCP 授权扩展

modelcontextprotocol/ext-auth

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

扩展	描述
OAuth 客户端凭证	用于机器到机器身份验证的 OAuth 2.0 客户端凭证流程。
企业托管授权	需要集中访问控制的企业环境框架。

MCP 应用

modelcontextprotocol/ext-apps

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

扩展	描述
MCP 应用	允许 MCP 服务器在对话中内联显示交互式 UI 元素（图表、表单、视频播放器）

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

MCP Tasks

扩展	描述
MCP Tasks	用于长时间运行操作的异步任务执行，支持轮询、执行中的输入以及持久化句柄。

Skills over MCP

modelcontextprotocol/ext-skills

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

扩展	描述
Skills over MCP	通过 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 Apps

Authorization Extensions

Tasks

Skills

扩展概述

MCP 扩展

官方扩展仓库

MCP 授权扩展

modelcontextprotocol/ext-auth

MCP 应用

modelcontextprotocol/ext-apps

MCP Tasks

Skills over MCP

modelcontextprotocol/ext-skills

实验性扩展

基本规则

晋升为官方状态

创建扩展

要求

SDK 实现

演进

协商

客户端能力

服务器能力

优雅降级

​MCP 扩展

​官方扩展仓库

​MCP 授权扩展

modelcontextprotocol/ext-auth

​MCP 应用

modelcontextprotocol/ext-apps

​MCP Tasks

​Skills over MCP

modelcontextprotocol/ext-skills

​实验性扩展

​基本规则

​晋升为官方状态

​创建扩展

​要求

​SDK 实现

​演进

​协商

​客户端能力

​服务器能力

​优雅降级

MCP 扩展

官方扩展仓库

MCP 授权扩展

MCP 应用

MCP Tasks

Skills over MCP

实验性扩展

基本规则

晋升为官方状态

创建扩展

要求

SDK 实现

演进

协商

客户端能力

服务器能力

优雅降级