SEP-2133：扩展

社区译文；来源： MCP 29affa6b

本 SEP 已达到 Final 状态，并作为已接受设计的历史记录保留。定稿后对协议所做的更改不会反映在此处。权威要求请参阅当前规范及其变更日志。

字段	值
SEP	2133
标题	扩展
状态	Final
类型	标准跟踪
创建日期	2025-01-21
作者	Peter Alexander (@pja-ant)
发起人	无（正在寻求发起人）
PR	#2133

摘要

本 SEP 建立一个轻量级框架，通过可选、可组合的扩展来扩展模型上下文协议。本提案为扩展定义治理模型和呈现结构，使 MCP 生态系统能够在保持核心协议稳定的同时持续演进。扩展为社区提出、评审和采用增强功能提供清晰的扩展点，从而可以试验新能力，而不强迫所有实现采用它们。

本 SEP 同时定义官方扩展（由 MCP 维护者维护）和实验性扩展（为工作组与兴趣组提供孵化路径，使其可以在正式接受前对扩展构想进行原型验证与协作）。外部维护的扩展可能会在后续阶段引入。

动机

MCP 目前没有关于如何提出或采用扩展的任何指导。缺少流程时，扩展由谁治理、实现应满足什么预期、应如何在规范中引用等问题都不明确。

规范

定义

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

扩展使用唯一的_扩展标识符_，格式为：{vendor-prefix}/{extension-name}，例如 io.modelcontextprotocol/oauth-client-credentials 或 com.example/websocket-transport。其名称遵循与 _meta 键相同的规则，但前缀是必需的。

为防止标识符冲突，供应商前缀 应该（SHOULD） 使用扩展作者拥有或控制的反向域名（类似 Java 包命名约定）。例如，拥有 example.com 的公司会使用 com.example/ 作为前缀。

破坏性变更 必须（MUST） 使用新的标识符，例如 io.modelcontextprotocol/oauth-client-credentials-v2。凡是会导致现有合规实现失败或行为错误的修改，都属于破坏性变更，包括：删除字段或重命名字段、更改字段类型、改变现有行为的语义，或增加新的必填字段。

扩展可以包含设置，并在客户端/服务器消息中发送这些设置，以实现细粒度配置。

本 SEP 定义_官方扩展_和_实验性扩展_。实验性扩展在 MCP 组织内维护，作为孵化路径，但尚未得到正式接受。_非官方扩展_不受 MCP 治理认可，可由 MCP 组织外的开发者引入并治理。

官方扩展

官方扩展位于 https://github.com/modelcontextprotocol/ 下的 MCP GitHub 组织内，由 MCP 维护者正式开发并推荐。官方扩展在其扩展标识符中使用 io.modelcontextprotocol 供应商前缀。

_扩展仓库_是官方 modelcontextprotocol GitHub 组织中带有 ext- 前缀的仓库，例如 https://github.com/modelcontextprotocol/ext-auth。

核心维护者可以自行决定创建扩展仓库，用于将特定领域（例如 auth、transport、financial services）的扩展归组。
一个仓库拥有一组由核心维护者任命的维护者（在 MAINTAINERS.md 中标识），他们负责该仓库及其中的扩展（例如 ext-auth MAINTAINERS.md、ext-apps MAINTAINERS.md）。
扩展 应该（SHOULD） 有关联的工作组或兴趣组，用于指导开发并收集社区意见。

_扩展_是扩展仓库中的版本化规范文档，例如 https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/2026-07-28/oauth-client-credentials.mdx。

扩展规范 必须（MUST） 使用与核心规范相同的语言（即 [BCP 14]、[RFC2119]、[RFC8174]），并且 应该（SHOULD） 按照它们属于核心规范的方式措辞。

虽然日常治理委托给扩展仓库维护者，但核心维护者保留对官方扩展的最终权限，包括修改、弃用或移除任何扩展的权力。

实验性扩展

实验性扩展为工作组（WG）和兴趣组（IG）提供孵化路径，使其能够在正式提交 SEP 之前促进发现、对构想进行原型验证，并就扩展概念开展协作。实验性扩展允许在中立治理下进行跨公司协作，同时提供清晰的反垄断保护和知识产权边界。

_实验性扩展仓库_是官方 modelcontextprotocol GitHub 组织中带有 experimental-ext- 前缀的仓库，例如 https://github.com/modelcontextprotocol/experimental-ext-interceptors。

当关联 SEP 仍处于 draft 状态时（或在提交 SEP 之前），任何维护者 可以（MAY） 创建实验性扩展仓库。
实验性扩展 必须（MUST） 与工作组或兴趣组关联，由该组的维护者负责仓库的日常治理。
实验性扩展仓库 必须（MUST） 清楚表明其实验性/非正式状态（例如在 README 中），避免与官方扩展混淆。
实验性扩展发布的任何软件包 必须（MUST） 使用能清楚表明其实验状态的命名。
核心维护者保留对实验性扩展仓库的监督权，包括将其归档或移除的权力。

实验性扩展若要晋升为官方扩展，应采用标准 SEP 流程（扩展跟踪）。在孵化期间开发的实验性仓库和任何参考实现 可以（MAY） 在 SEP 中引用，用于证明该扩展的实用性。

生命周期

创建

扩展 可以（MAY） 选择从实验性扩展开始（参见_实验性扩展_一节），以便在正式提交前开展原型验证与协作。我们鼓励但不要求经历这一孵化期。

扩展若要成为官方扩展，需要在主 MCP 仓库中通过 SEP 创建，遵循标准 SEP 指南，但使用一种新类型：扩展跟踪。该类型沿用标准跟踪 SEP 的评审与接受流程，同时明确表明提案针对扩展，而非核心协议新增项。SEP 必须标识负责该扩展的工作组和扩展维护者。维护者任命方式参见 SEP-2148。

扩展 SEP：

在提交前，应该（SHOULD） 在相关工作组中讨论并迭代。
在评审前，必须（MUST） 至少在一个官方 SDK 中提供参考实现，以确保扩展切实可行且能够实现。
可以（MAY） 引用孵化期间已有的实验性扩展仓库和所开发的实现。
将由核心维护者评审；核心维护者对是否将其纳入官方扩展拥有最终决定权。

获得批准后，作者 应该（SHOULD） 提交一个 PR，将该扩展引入扩展仓库，并在主规范中添加引用（参见_规范推荐_一节）。已批准的扩展 可以（MAY） 在其他客户端、服务器和 SDK 中实现（参见 SDK 实现）。

迭代

扩展一经接受，后续迭代无需核心维护者再次评审。扩展仓库维护者负责评审和接受对扩展的更改，并且 应该（SHOULD） 通过相关工作组协调变更。扩展独立于核心协议，因此可以随时更新和部署，但变更 必须（MUST） 确保其设计考虑向后兼容性。

晋升为核心协议（可选）

部分扩展最终 可以（MAY） 转为核心协议特性。此类变更 应该（SHOULD） 作为标准跟踪 SEP 处理，并由核心维护者单独评审。并非所有扩展都适合纳入核心协议（例如行业专用扩展），它们可以无限期地保持扩展形态。

规范推荐

MCP 网站将新增 modelcontextprotocol.io/extensions 页面（待创建），并从该页面引用扩展及其规范。

也 可以（MAY） 酌情在核心规范中添加相关扩展的链接（例如 https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization 可以链接到 ext-auth 扩展），但 必须（MUST） 清楚标明它们是可选扩展，并且 应该（SHOULD） 只提供链接（而非复制规范文本）。

SDK 实现

SDK 可以（MAY） 实现扩展。实现扩展时，扩展 必须（MUST） 默认禁用，并要求显式选择启用。SDK 文档 应该（SHOULD） 列出所支持的扩展。

SDK 维护者对其 SDK 的扩展支持拥有完全自主权：

维护者对自己选择支持的任何扩展的实现和维护负全部责任。
维护者没有义务实现任何扩展或接受他人贡献的实现。100% 协议一致性或即将推出的 SDK 一致性等级都不要求支持扩展。
本 SEP 不规定 SDK 应如何组织或打包扩展。维护者可以提供扩展点、插件系统或任何其他其认为合适的机制。

演进

所有扩展都独立于核心协议演进，即扩展的新版本 可以（MAY） 在未经核心维护者评审的情况下发布。扩展的次要更新、错误修复和非破坏性增强不需要新的 SEP；这些变更由扩展仓库维护者管理。

扩展 应该（SHOULD） 进行版本化，但此处不规定具体的版本控制方式。

协商

客户端和服务器分别在 ClientCapabilities 与 ServerCapabilities 字段中声明其扩展支持，并在 Server Card 中声明（目前仍在进行中）。

将在两者中分别引入一个新的“extensions”字段，它是从_扩展标识符_到各扩展设置对象的映射。每个扩展自行规定其设置对象的 schema；空对象表示没有设置。

客户端能力

客户端在 initialize 请求中声明扩展支持：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "extensions": {
        "io.modelcontextprotocol/ui": {
          "mimeTypes": ["text/html;profile=mcp-app"]
        }
      }
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}

服务器能力

服务器在 initialize 响应中声明扩展支持：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {},
      "extensions": {
        "io.modelcontextprotocol/ui": {}
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "version": "1.0.0"
    }
  }
}

服务器端能力检查

服务器在提供扩展特定功能前，应该（SHOULD） 检查客户端能力：

const hasUISupport = clientCapabilities?.extensions?.[
  "io.modelcontextprotocol/ui"
]?.mimeTypes?.includes("text/html;profile=mcp-app");

if (hasUISupport) {
  // Register tools with UI features
} else {
  // Register text-only fallback
}

平稳降级

如果一方支持某个扩展，而另一方不支持，支持方 必须（MUST） 二选一：回退到核心协议行为；或者，如果该扩展是强制要求，则返回适当错误以拒绝请求。扩展 应该（SHOULD） 记录其预期回退行为。例如，提供 UI 增强工具的服务器仍应为不支持 UI 扩展的客户端返回有意义的文本内容；而要求特定身份验证扩展的服务器 可以（MAY） 拒绝不支持该扩展的客户端连接。

法律要求

商标政策

在扩展标识符中使用 MCP 商标，并不授予商标权。第三方不得以暗示认可或关联关系的方式使用“MCP”“Model Context Protocol”或容易混淆的类似标志。
MCP 不判断扩展中所用术语的商标有效性。

反垄断

扩展开发者确认：自己可能与其他参与者竞争，没有义务实现任何扩展，可以自由开发竞争性扩展与协议，也可以将其技术许可给包括竞争性解决方案在内的第三方。
官方扩展身份不建立排他关系。
扩展仓库维护者以个人身份行事，并运用其最佳技术判断。

许可

官方扩展 必须（MUST） 采用 Apache 2.0 许可证。

贡献者许可授予

向官方 MCP 扩展仓库提交贡献，即表示你声明：

你拥有授予本协议中权利的合法权限
你的贡献是原创作品，或者你拥有提交该贡献所需的充分权利
你向 Linux Foundation 和规范接收者授予永久、全球性、非独占、免费、免版税且不可撤销的许可，使其可以：
- 复制贡献、创作衍生作品、公开展示、公开表演、再许可和分发贡献
- 制造、委托制造、使用、要约销售、销售、进口及以其他方式转让实现

不授予其他权利

除本节明确规定外，本协议不授予任何其他专利、商标、版权或其他知识产权，包括通过默示、弃权或禁止反言授予的权利。

未规定的事项

本 SEP 并未规定扩展系统的所有方面。以下是本 SEP 未处理事项的不完整列表：

Schema： 未规定让扩展声明其如何修改 schema 的机制。
依赖关系： 未规定扩展是否或如何依赖特定核心协议版本，或与其他扩展（或扩展版本）相互依赖。
Profile： 未规定扩展的分组方式。

省略这些内容并不是因为它们不重要，而是因为未来可以补充它们。本 SEP 的目标只是先建立一套初始扩展结构，并将围绕扩展中更复杂或更具争议部分的详细技术讨论留待后续。

理由

本扩展设计遵循以下原则：

从简单开始： 目标是提供一种相对简单的机制，使人们能够以结构化方式开始构建和提出扩展。
清晰治理： 现阶段重点在于明确治理，而非实现细节。
后续完善： 随着我们积累更多扩展经验，可以适当调整方法。

一些具体设计选择：

为何使用扩展仓库，而不是单个/独立扩展？ 仓库提供自然的分组和治理结构，使仓库维护者能够保证扩展的结构与一致性。这样可避免同一领域内不同扩展以不兼容方式工作的失败情况，也能委派大量治理工作。
为何不要求核心维护者评审官方扩展？ 委托评审使扩展可以自主演进，而不必受制于核心维护者评审这一已经往往需要数月的流程。
为何单独进行版本控制？ 扩展是规范的可选补充，无需绑定版本。单独版本允许更快速地迭代。

向后兼容性

扩展框架本身完全是对核心协议的加法，因此不会给核心规范带来向后兼容问题。

本 SEP 所描述的设计与现有官方扩展（ext-apps 和 ext-auth）一致；它们已经使用此处规定的能力协商与扩展标识符模式。

但是，各个扩展可能有自己的向后兼容问题。扩展在设计中 必须（MUST） 考虑并处理跨核心协议版本和扩展版本的向后兼容性。扩展内的破坏性变更 必须（MUST） 使用新的扩展标识符（参见_定义_一节）。扩展还 应该（SHOULD） 记录其向后兼容性与稳定性策略（例如，扩展 可以（MAY） 将自己标记为“experimental”，表示它可能在不另行通知的情况下发生破坏性变更）。

安全影响

扩展 必须（MUST） 实施其所扩展领域中的所有相关安全最佳实践。

客户端和服务器 应该（SHOULD） 将扩展引入的任何新字段或数据视为不可信输入，并且 应该（SHOULD） 对其进行全面验证。

参考实现

待提供。

SEP-2127：MCP Server Card——HTTP 服务器发现 SEP-2148：MCP 贡献者阶梯