人工智能AI Agent工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载SEP-2133ExtensionsStandards TrackFinal为 Model Context ProtocolMCP建立了可选的、可组合的扩展框架让客户端、服务器与 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 GroupsWG与 Interest GroupsIG在正式接受前进行原型与协作的孵化通道此外还有非官方扩展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 中构建至少一个参考实现→ReviewCore 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-inSDK 文档 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;profilemcp-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;profilemcp-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 SpecifiedSEP-2133 有意不规定扩展系统的全部细节明确留待后续的清单包括Schema未规定扩展如何宣传其对 schema 的修改机制依赖未规定扩展是否/如何依赖特定核心协议版本或与其他扩展或扩展版本之间的相互依赖Profiles未规定扩展分组方式。这些省略并非不重要而是因为可能稍后补充——该 SEP 的目标是先让初步的扩展结构落地把更复杂、更具争议的技术细节讨论推迟。设计理性RationaleSEP-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-authOAuth Client Credentials机器对机器认证、Enterprise-Managed Authorization企业集中访问控制框架ext-appsMCP Apps允许服务器在对话中内联展示交互式 UI 元素图表、表单、视频播放器ext-skills通过 MCP 资源发现与读取 Agent SkillsMCP 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工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载相关推荐SEP-994 深度解读Model Context Protocol 社区共享沟通实践与协作指南SEP 994 深度解读Model Context Protocol 社区共享沟通实践与协作指南 导读 本文围绕 Model Context Protocol人工智能AI Agent工具调用Model Context Protocol 社区治理SEP-1302 工作组WG与兴趣组IG机制完全解读Model Context Protocol 社区治理SEP 1302 工作组WG与兴趣组IG机制完全解读 本篇指南围绕 SEP 1302 https人工智能AI Agent工具调用Model Context ProtocolMCP项目治理机制与 SEP 提案流程全解从 SEP-932 到 Contributor Ladder 的完整治理体系Model Context ProtocolMCP项目治理机制与 SEP 提案流程全解从 SEP 932 到 Contributor Ladder 的完整人工智能AI Agent工具调用上一篇MaterializeCSS终极指南如何快速构建现代化Material Design网站下一篇突破中断瓶颈Linux内核GICv3中断控制器的ITS翻译表黑科技深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考