SEP-1730：SDK 分级体系

社区译文；来源： MCP 29affa6b

摘要

本 SEP 为 Model Context Protocol（MCP）SDK 提议一套分级体系，用于明确特性支持、维护承诺和质量标准方面的预期。该体系定义三个 SDK 支持等级，并为等级划分提供客观、可衡量的标准。

动机

MCP 生态系统需要协调各 SDK，帮助用户作出有依据的选择。用户目前面临以下问题：

• 特性支持不确定：没有标准化方式判断某个 SDK 支持哪些 MCP 特性（OAuth、客户端/服务器/系统特性，例如 sampling 和传输）
• 维护预期不明确：对于 bug 修复、安全补丁和特性更新，没有清晰的承诺等级
• 实现时间线不可见：无法了解 SDK 何时会支持新的协议版本和特性

规范

等级定义

Tier 1：完全支持

此等级的 SDK 完整实现协议，并获得良好支持。

要求：

• 特性完整并完全支持协议
  • 通过全部一致性测试
  • 在新规范版本发布前实现新的协议特性。（Release Candidate 与新协议版本发布之间有两周窗口）
• SDK 维护
  • 在两个工作日内确认并分类 issue
  • 在七天内解决安全问题和严重 bug
  • 清楚记录稳定版本发布与 SDK 版本控制方式
• 文档
  • 为所有特性提供包含示例的完整文档
  • 发布依赖更新政策

Tier 2：承诺达到完全支持

已有成熟实现，并在积极推进完整协议支持的 SDK。

要求：

• 特性完整并完全支持协议
  • 通过 80% 的一致性测试
  • 在六个月内实现新的协议特性
• SDK 维护
  • 主动跟踪和管理 issue
  • 至少有一个稳定版本
• 文档
  • 提供覆盖核心特性的基础文档
  • 发布依赖更新政策
• 承诺晋升到 Tier 1
  • 发布路线图，说明达到 Tier 1 的计划；如果 SDK 将无限期停留在 Tier 2，则公开说明 SDK 的发展方向以及特性不完整的原因

Tier 3：实验性

探索协议空间的早期或专用 SDK。

特征：

• 不保证特性完整性
• 不要求稳定版本
• 可以专注于特定用例或实验性特性
• 不承诺更新时间线
• 适合可能长期停留在此等级的小众实现

一致性测试

所有 SDK 都必须使用协议 trace 验证进行一致性测试；详情参见一致性测试 RFC（待发布）。本 SEP 不以一致性测试为重点。对于分级体系的初始版本，我们将采用简化方案：为每个 SDK 提供一个示例服务器，并针对这些服务器运行简化的一致性测试。

  sequenceDiagram
    participant SDK
    participant Test Suite
    participant Validator

    Test Suite->>SDK: Execute test scenario
    SDK->>Test Suite: Protocol messages
    Test Suite->>Validator: Submit trace
    Validator->>Test Suite: Compliance report
    Test Suite->>SDK: Pass/Fail result

符合度评分：

• SDK 根据测试结果获得百分比分数
• 分数可以显示为徽章（例如“90% MCP Compliant”）
• Tier 1：要求 100% 符合
• Tier 2：要求 80% 符合
• Tier 3：没有最低要求

等级晋升流程

1. 自我评估： 维护者根据等级标准评估其 SDK
2. 申请： 提交附带证据的等级晋升申请
3. 评审： 社区评审期（两周）
4. 验证： 自动化一致性测试以及 GitHub issue 统计
5. 决定： 由 MCP 维护者确定等级

等级降级流程

1. 自动验证：
   1. Tier 1 的一致性测试连续四周未通过
   2. Tier 2 有 20% 的一致性测试连续四周未通过
2. Issue：
   1. Issue 在两个月内未得到处理

要求矩阵

理由

为什么设为三个等级？

• Tier 1 确保用户获得支持良好、特性完整的 SDK
• Tier 2 为 SDK 改进提供清晰路径
• Tier 3 允许实验，同时不设置准入障碍

为什么采用有时限的承诺？

社区虽然对严格时间线提出过担忧，但时间线可以提供：

• 面向用户的明确预期
• 面向维护者的可衡量目标
• 通过等级晋升提供灵活性

为什么不只使用特性矩阵？

仅靠特性矩阵无法表达：

• 维护承诺
• 质量标准
• 支持预期

分级体系将特性支持与质量保证结合起来。

已考虑的替代方案

1. 仅使用特性矩阵

拒绝原因： 无法表达维护承诺或质量标准

2. 基于百分比的评分

拒绝原因： 过于细碎，且无法体现支持等定性因素

3. 基于属性的体系

拒绝原因： 多项彼此重叠的属性可能使用户困惑

4. 仅列出最新版本

拒绝原因： 仅列出“支持 MCP 日期”无法反映关键信息：

• 版本支持可能并不完整（例如支持 <日期>，但 OAuth 除外）
• 没有说明维护承诺或 issue 响应时间
• 缺少安全补丁时间线信息
• 无法表达依赖更新政策
• 仅靠版本号无法说明是否已可用于生产

5. 不建立正式体系

拒绝原因： 当前的临时方式给用户带来不确定性

向后兼容性

本提案引入一种新的分类体系，不包含破坏性变更：

• 现有 SDK 继续正常运行
• 分类最初采取自愿加入方式
• 为现有 SDK 留出达到相应等级的宽限期

安全影响

• Tier 1 SDK 必须在 7 天内处理安全问题
• 鼓励所有等级遵循安全最佳实践
• 一致性测试包含安全验证

实施计划

• 完成简化的一致性测试套件 - 2025 年 11 月 4 日
• SDK 维护者自我评估并申请等级 - 2025 年 11 月 14 日
• 初始等级分配 - 11 月规范版本发布前
• 实现完整的一致性测试
• 为 SDK 实现自动化 issue 跟踪分析

社区影响

SDK 维护者

• 明确的改进目标
• 对高质量实现的认可
• 结构化的晋升路径

SDK 用户

• 有依据地选择 SDK
• 明确的支持预期
• 对 Tier 1 实现的信心

生态系统

• 提升 SDK 整体质量
• 标准化特性支持
• 在不同实现之间形成良性竞争

参考资料

• SDK 维护者会议记录（#1648）
• SDK 协调目标（#1444）
• 一致性测试 SEP（DRAFT）

附录

简化的一致性测试

我们正在制定完整的一致性测试提案，其实施需要一段时间；与此同时，我们希望至少先提供某种自动化方式，检查 SDK 是否具备完整的特性集合。我们会从服务器特性集合开始，因为服务器数量远多于客户端，而且绝大多数 SDK 开发者都是服务器实现者。

最直接的方法是为每个 SDK 提供一个示例服务器，类似于 Everything Server。然后，我们会提供一个 Conformance Test Client，其中包含希望测试的全部测试用例，例如：

• 执行“hello world”工具
• 获取 prompt
• 获取 completion
• 获取资源模板
• 接收通知

SDK 维护者需要完成的工作： 根据一份规范实现 everything server。规范将类似于：

• 工具“say_hello”返回简单文本
• 工具“show_image”返回一张图片
• 工具“tool_with_logging”以格式 <> 返回结构化输出，并记录三个事件：start、process、end
• 工具“tool_with_notifications”以格式 <> 返回结构化输出，并发出两条通知 <>

服务器规范定义清楚并配有 SDK 文档后，借助任意编程 Agent 应当很容易完成实现。我们希望将它签入每个 SDK 仓库，使其成为服务器实现者的示例。

每个 SDK 都有 Everything server 后，我们会针对它运行 Conformance Test Client。