SEP-2133 深度解读：Model Context Protocol 扩展框架——标识符、能力协商与治理生命周期

• 人工智能
• AI Agent
• 工具调用

SEP-2133（Extensions，Standards Track，Final）为 Model Context Protocol（MCP）建立了可选的、可组合的扩展框架，让客户端、服务器与 SDK 可以在不触碰核心协议的情况下新增能力。本文以该 SEP 为主体，结合 specification 仓库中的ClientCapabilities/ServerCapabilities模式定义、官方扩展示例与后续 Extensions Track SEP，完整讲解扩展标识符规范、官方/实验扩展治理模型、生命周期、能力协商机制及法律约束，读者读完后可掌握"如何提出、如何实现、如何协商"一个 MCP 扩展的完整链路。

SEP-2133 是什么：为 MCP 引入可组合的扩展机制

SEP-2133 的核心主张是：MCP 需要一个"轻量级"的扩展框架，通过可选的、可组合的扩展（optional, composable extensions）让生态得以演进，同时保持核心协议稳定。扩展允许社区在不强制所有实现采纳的前提下试验新能力，为"提议—评审—采纳"增强功能提供了明确的扩展点（extension points）。

该 SEP 的动机非常直接：彼时 MCP 完全没有关于扩展"如何提出、如何采纳"的任何指导。缺少流程，就说不清扩展如何被治理、实现上有何预期、规范中应如何引用它们。SEP 由此划分了两类受 MCP 治理认可的扩展：

• 官方扩展（Official Extensions）：由 MCP 维护者维护；
• 实验扩展（Experimental Extensions）：作为 Working Groups（WG）与 Interest Groups（IG）在正式接受前进行原型与协作的孵化通道；
• 此外还有非官方扩展（Unofficial Extensions）：不被 MCP 治理认可，可由 MCP 组织之外的开发者自行引入和治理（外部维护的扩展预计在更晚阶段出现）。

扩展的定义与标识符规范

什么是 MCP 扩展

MCP 扩展是规范的可选补充，定义超越核心协议的能力。按 SEP-2133，扩展所启用的功能可以是：

• 模块化（modular）：独立特性，例如认证（authentication）；
• 专用（specialized）：行业专属逻辑，例如金融服务业逻辑；
• 实验性（experimental）：正在孵化、未来可能纳入核心的特性。

扩展标识符：{vendor-prefix}/{extension-name}

每个扩展使用唯一的扩展标识符（extension identifier），格式为{vendor-prefix}/{extension-name}，例如io.modelcontextprotocol/oauth-client-credentials或com.example/websocket-transport。名称规则与规范中_meta键 的规则一致，唯一差别是前缀（prefix）为必填项。

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

破坏性变更（breaking changes）必须使用新的标识符，例如io.modelcontextprotocol/oauth-client-credentials-v2。SEP-2133 对"破坏性变更"给出了明确清单——任何会导致现有合规实现失败或行为错误的修改，包括：

• 删除或重命名字段；
• 改变字段类型；
• 改变既有行为的语义；
• 新增必填字段。

扩展可以带有settings（设置），随客户端/服务器消息发送，用于细粒度配置；每个扩展自行规定其 settings 对象的 schema，空对象表示无设置。

官方扩展：ext-仓库与治理模型

官方扩展位于 MCP GitHub 组织之下，由 MCP 维护者正式开发与推荐，其扩展标识符统一使用io.modelcontextprotocolvendor prefix。

**扩展仓库（extension repository）**是官方 org 内以ext-为前缀的仓库（如ext-auth），其治理要点：

• 仓库由核心维护者酌情创建，用于将某一领域的扩展分组（如 auth、transport、financial services）；
• 每个仓库有一组由核心维护者任命的维护者（通过MAINTAINERS.md标识），负责仓库及其内扩展（如 ext-auth、ext-apps 各自的 MAINTAINERS.md）；
• 扩展 SHOULD 有对应的 working group 或 interest group 引导开发并收集社区意见。

扩展本体是扩展仓库内的版本化规范文档（如specification/draft/oauth-client-credentials.mdx）。扩展规范 MUST 使用与核心规范相同的语言（即 [BCP 14]/RFC 2119/RFC 8174 的 MUST/SHOULD/MAY 语义），且 SHOULD 措辞得像核心规范的一部分。

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

实验扩展：experimental-ext-孵化通道

实验扩展为 WG/IG 提供孵化路径，使跨公司协作能够在中立治理下进行，并具备清晰的反垄断保护与 IP 明确性。实验扩展仓库是 MCP org 内以experimental-ext-为前缀的仓库（如experimental-ext-interceptors），规则如下：

• 任何维护者 MAY 在关联 SEP 仍处于 draft 状态（甚至 SEP 尚未提交）时创建实验扩展仓库；
• 实验扩展 MUST 与某个 WG 或 IG 关联，由该组维护者负责日常治理；
• 仓库 MUST 明确标注实验/非官方状态（例如在 README 中），避免与官方扩展混淆；
• 实验扩展发布的任何包 MUST 使用能清晰体现实验状态的命名；
• 核心维护者保留监督权，包括归档或移除实验仓库。

实验扩展晋升为官方状态时，走标准 SEP 流程（Extensions Track）；孵化期间开发的实验仓库与参考实现 MAY 在 SEP 中被引用，以证明扩展的可行性。

扩展生命周期：从提案到迭代与晋升

创建：Extensions Track SEP

扩展 MAY 先作为实验扩展孵化（鼓励但非必需）。要成为官方扩展，须在主 MCP 仓库中通过Extensions Track类型的 SEP 创建——该类型沿用标准 SEP 指南（见 docs/community/sep-guidelines.mdx）的评审与接受流程，但明确标示提案属于扩展而非核心协议新增。SEP 必须指明负责该扩展的 Working Group 与 Extension Maintainers。

Extension SEP 的硬性要求：

• SHOULD 在提交前于相关 working group 中讨论与迭代；
• MUST 在评审前于至少一个官方 SDK 中拥有参考实现，以确保扩展切实可行、可实现；
• MAY 引用孵化期间开发的实验扩展仓库与实现；
• 由 Core Maintainers 评审，并对其是否纳入官方扩展拥有最终决定权。

批准后，作者 SHOULD 提交 PR 将扩展引入扩展仓库，并在主规范中引用（见下文"规范推荐"）。已批准的扩展 MAY 在更多客户端/服务器/SDK 中实现。

仓库中的 docs/extensions/overview.mdx 将这一流程浓缩为五步：Propose（以 Extensions Track 类型创建 SEP）→Implement（在官方 SDK 中构建至少一个参考实现）→Review（Core Maintainers 评审并拥有最终决定权）→Publish（批准后提交 PR 加入扩展仓库）→Adopt（其他客户端/服务器/SDK 随后实现）。

迭代

扩展一旦被接受，即可无需核心维护者再次评审地持续迭代。扩展仓库维护者负责评审与接受扩展变更，并 SHOULD 通过相关 working group 协调变更。由于扩展独立于核心协议，可随时更新与部署，但变更设计 MUST 考虑向后兼容。

晋升为核心协议（可选）

部分扩展最终 MAY 转型为核心协议特性。这 SHOULD 以 Standards Track SEP 处理并进行独立的核心维护者评审。注意并非所有扩展都适合进入核心协议（如行业专属扩展），它们 MAY 无限期保持扩展身份。

规范推荐与 SDK 实现

SEP-2133 计划在 MCP 网站新增/extensions页面（待创建），集中引用各扩展并链接其规范。核心规范中 MAY 酌情添加指向相关扩展的链接（例如 authorization 章节链接到 ext-auth 扩展），但 MUST 明确标注为可选扩展，且 SHOULD 仅做链接、不得复制规范文本。

SDK 实现遵循"可选 + 显式同意"原则：

• SDK MAY 实现扩展；若实现，扩展MUST 默认禁用并要求显式 opt-in；
• SDK 文档 SHOULD 列出其支持的扩展；
• SDK 维护者对扩展支持拥有完全自主权：独自负责所支持扩展的实现与维护；无义务实现任何扩展或接受贡献的实现；扩展支持不要求达到 100% 协议一致性，也不影响即将推出的 SDK 一致性分层；
• 本 SEP 不规定 SDK 如何组织或打包扩展，维护者可采用扩展点、插件系统或任何其他机制。

演进与版本化

所有扩展独立于核心协议演进：扩展的新版本 MAY 无需核心维护者评审即可发布。扩展的次要更新、bug 修复与非破坏性增强不需要新的 SEP，由扩展仓库维护者管理。扩展 SHOULD 进行版本化，但具体版本化方式不在本 SEP 规定范围内。

能力协商：initialize握手中的extensions字段

客户端与服务器分别在ClientCapabilities与ServerCapabilities字段中声明对扩展的支持（并计划纳入尚在推进中的 Server Card）。SEP 在每个能力对象中引入一个新的extensions字段，它是从扩展标识符到每个扩展 settings 对象的映射（空对象表示无设置）。

这一设计已落地到本仓库的模式定义中：在 schema/2026-07-28/schema.ts 中，ClientCapabilities的extensions字段被描述为"客户端支持的可选 MCP 扩展，键为扩展标识符（如io.modelcontextprotocol/oauth-client-credentials），值为每扩展 settings 对象，空对象表示无设置支持，键 MUST 遵循_meta键命名规则且前缀必填"；ServerCapabilities 中同样有对应字段（示例键为io.modelcontextprotocol/tasks）。schema 目录还提供了官方示例文件：ClientCapabilities/extensions-ui-mime-types.json（声明io.modelcontextprotocol/ui扩展并携带mimeTypes设置）与 ServerCapabilities/extensions-tasks.json（声明io.modelcontextprotocol/tasks，无设置）。

客户端能力声明（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 在提供扩展专属特性前检查客户端能力。SEP-2133 给出的 TypeScript 示例：

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 }

优雅降级（Graceful Degradation）

若一方支持某扩展而另一方不支持，支持方 MUST 要么回退到核心协议行为，要么（若该扩展为强制要求）以恰当错误拒绝请求。扩展 SHOULD 文档化其预期回退行为。例如：

• 提供 UI 增强工具的服务器，对不支持 UI 扩展的客户端仍应返回有意义的文本内容；
• 而要求特定认证扩展的服务器 MAY 拒绝不支持该扩展的客户端的连接。

值得注意的是，随着协议演进（2026-07-28 及 draft 版本），docs/extensions/overview.mdx 展示了协商位置的后续调整：客户端在请求_meta["io.modelcontextprotocol/clientCapabilities"]中声明扩展支持，服务器在server/discover响应的capabilities.extensions中声明——协商字段的语义与"每扩展 settings 对象、空对象表示无设置"的规则保持不变。

法律要求

SEP-2133 对官方扩展的运营设定了明确的法律边界：

• 商标政策：在扩展标识符中使用 MCP 商标不授予商标权。第三方不得以暗示背书或隶属关系的方式使用 "MCP"、"Model Context Protocol" 或易混淆的相似标记；MCP 对扩展所用术语的商标有效性不作判断。
• 反垄断：扩展开发者承认可能与其他参与者竞争、无义务实现任何扩展、可自由开发竞争性扩展与协议，并可向第三方（包括竞争性方案）许可其技术；官方扩展身份不构成排他关系；扩展仓库维护者以个人身份、运用最佳技术判断行事。
• 许可：官方扩展 MUST 以 Apache 2.0 许可提供。
• 贡献者许可授予：向官方 MCP 扩展仓库提交贡献，即表示你有法律权限授予相应权利、贡献为原创或你有充分权利提交，并向 Linux Foundation 及规范接收者授予永久的、全球性的、非排他、免费、不可撤销的许可（包括复制、制作衍生作品、公开展示/表演、再许可与分发，以及制造、使用、要约出售、销售、进口与转让实现）。
• 无其他权利：除本节明确规定的之外，不授予任何专利、商标、版权或其他知识产权（包括通过暗示、放弃或禁止反言）。

未指定的部分（Not Specified）

SEP-2133 有意不规定扩展系统的全部细节，明确留待后续的清单包括：

• Schema：未规定扩展如何宣传其对 schema 的修改机制；
• 依赖：未规定扩展是否/如何依赖特定核心协议版本，或与其他扩展（或扩展版本）之间的相互依赖；
• Profiles：未规定扩展分组方式。

这些省略并非不重要，而是因为可能稍后补充——该 SEP 的目标是先让初步的扩展结构落地，把更复杂、更具争议的技术细节讨论推迟。

设计理性（Rationale）

SEP-2133 的设计遵循三条原则：

• Start simple：采用相对简单的机制，让人们能以结构化方式开始构建和提出扩展；
• Clear governance：现阶段聚焦清晰的治理，而非实现细节；
• Refine later：随着扩展经验积累，后续再适当调整方法。

几个关键设计抉择及其理由：

• 为何用扩展仓库而非独立的单个扩展？仓库提供了自然的组织与治理结构，便于维护者强制结构与一致性，避免同一领域不同扩展以不兼容方式工作，也便于下放治理工作。
• 为何官方扩展不要求核心维护者评审？委托评审让扩展能自主演进，不被核心维护者评审（往往长达数月）阻塞。
• 为何独立版本化？扩展是对规范的可选补充，无需将版本绑定在一起；独立版本支持更快的迭代。

向后兼容与安全影响

扩展框架本身对核心协议是纯增量的，因此对核心规范没有向后兼容性问题。SEP-2133 的设计与已有官方扩展（ext-apps、ext-auth）一致——它们在能力协商与扩展标识符上已采用本 SEP 规定的模式。

但单个扩展可能有各自的向后兼容问题：扩展 MUST 在设计时考虑并兼顾跨核心协议版本与扩展版本的兼容；扩展内的破坏性变更 MUST 使用新标识符；扩展 SHOULD 文档化其向后兼容与稳定性策略（例如可自我标注为 "experimental"，表示可能无通知地破坏）。

安全方面：扩展 MUST 在其扩展领域落实所有相关安全最佳实践；客户端与服务器 SHOULD 将扩展引入的任何新字段或数据视为不可信，并全面校验。

从 SEP 到现实：仓库中的扩展生态

SEP-2133 并非停留在纸面——本仓库中可看到其后继的 Extensions Track SEP 与已落地的官方扩展。在 docs/extensions/overview.mdx 中，官方扩展已按仓库组织：

• ext-auth：OAuth Client Credentials（机器对机器认证）、Enterprise-Managed Authorization（企业集中访问控制框架）；
• ext-apps：MCP Apps，允许服务器在对话中内联展示交互式 UI 元素（图表、表单、视频播放器）；
• ext-skills：通过 MCP 资源发现与读取 Agent Skills；
• MCP Tasks：面向长时运行操作的异步任务执行。

Extensions Track 类型的后继 SEP 也已在仓库中成型，例如 SEP-2640: Skills Extension 定义了用skill://URI 将技能目录映射为资源的约定，以及 SEP-2663: Tasks Extension。它们正是在 SEP-2133 定义的框架下，用扩展标识符、能力协商与独立版本化规则运作的具体实例——读者若想深入学习扩展的实际形态，可直接从这些后继 SEP 与schema/2026-07-28/schema.ts中的extensions字段定义入手。

• 人工智能
• AI Agent
• 工具调用