扩展

MCP 扩展

MCP 扩展是规范的可选补充,定义了核心协议之外的功能。扩展使功能可以是模块化的(例如,身份验证等不同功能)、专业化的(例如,行业特定逻辑)或实验性的(例如,正在为核心 inclusion 而孵化的功能)。

扩展使用唯一的_扩展标识符_识别,格式为:{vendor-prefix}/{extension-name},例如 io.modelcontextprotocol/oauth-client-credentials。官方扩展使用 io.modelcontextprotocol 供应商前缀。

官方扩展仓库

官方扩展位于 MCP GitHub 组织 中带有 ext- 前缀的仓库内。

ext-auth

仓库: github.com/modelcontextprotocol/ext-auth

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

扩展描述规范
OAuth Client Credentials用于机器对机器身份验证的 OAuth 2.0 客户端凭证流程链接
Enterprise-Managed Authorization需要集中访问控制的企业环境的框架链接

ext-apps

仓库: github.com/modelcontextprotocol/ext-apps

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

扩展描述规范
MCP Apps允许 MCP 服务器在对话内联显示交互式 UI 元素(图表、表单、视频播放器)链接

创建扩展

官方扩展的生命周期类似于 SEP,但委托给扩展仓库维护者:

  1. 提案:作者使用标准 SEP 指南在主 MCP 仓库中创建类型为扩展跟踪的 SEP。
  2. 审查:扩展 SEP 由相关的扩展仓库维护者审查。
  3. 实现:扩展 SEP 必须在被接受之前在官方 SDK 中至少有一个参考实现。
  4. 发布:一旦批准,作者创建 PR 将扩展引入扩展仓库。
  5. 采用:批准的扩展可以在额外的客户端、服务器和 SDK 中实现。

要求

  • 扩展规范必须使用 RFC 2119 语言(MUST、SHOULD、MAY)
  • 扩展应该有相关的工作组或兴趣组

SDK 实现

SDK 可以实现扩展。如果实现:

  • 扩展必须默认禁用并需要显式选择加入
  • SDK 文档应该列出支持的扩展
  • SDK 维护者对他们支持的扩展拥有完全自主权
  • 扩展支持不是协议一致性所必需的

演化

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

扩展必须在其设计中考虑向后兼容性:

  • 扩展应该通过能力标志或扩展设置对象内的版本控制来保持向后兼容,而不是创建新的扩展标识符
  • 当向后不兼容的更改不可避免时,必须使用新的扩展标识符(例如,io.modelcontextprotocol/my-extension-v2