关键日期：
- 2026 年 1 月 23 日：一致性测试可用
- 2026 年 2 月 23 日：官方 SDK 分级发布
概述
SDK 根据功能完整性、维护承诺和文档质量分为三个层级：- Tier 1：完全支持的 SDK，具有完整的协议实现，包括所有 非实验性功能和可选能力，如采样和诱导
- Tier 2：积极维护的 SDK，致力于完全协议规范支持
- Tier 3：实验性、部分实现或专用的 SDK
层级要求
| 要求 | Tier 1：完全支持 | Tier 2：承诺完全支持 | Tier 3：实验性 |
|---|---|---|---|
| 一致性测试 | 100% 通过率 | 80% 通过率 | 无最低要求 |
| 新协议特性 | 在新规范版本发布之前，根据特性复杂度按版本商定时间表 | 6 个月内 | 无时间表承诺 |
| 问题分类 | 2 个工作日内 | 一个月内 | 无要求 |
| 严重缺陷解决 | 7 天内 | 两周内 | 无要求 |
| 稳定版本发布 | 需要清晰的版本控制 | 至少一个稳定版本 | 不需要 |
| 文档 | 全面，包含所有功能的示例 | 涵盖核心功能的基本文档 | 无最低要求 |
| 依赖策略 | 已发布的更新策略 | 已发布的更新策略 | 不需要 |
| 路线图 | 已发布的路线图 | 已发布的向 Tier 1 推进的计划或保留在 Tier 2 的说明 | 不需要 |
1.0.0
或更高，不带 -alpha、-beta 或 -rc 等预发布标识符）。
清晰版本控制 意味着遵循惯用的版本控制模式并记录
破坏性变更策略，以便用户在升级时能够理解兼容性期望。
路线图 概述了具体的步骤和工作项，跟踪所需 MCP
规范组件的实施（一致性测试 中描述的非实验性功能和可选能力），让用户了解即将到来的功能支持情况。
一致性测试
所有 SDK 均使用 自动化一致性测试 进行评估， 该测试针对已发布的规范验证协议支持。SDK 根据测试结果获得一致性评分：- Tier 1：要求 100% 一致性
- Tier 2：要求 80% 一致性
- Tier 3：无最低要求
- 针对 SDK 目标的规范版本的测试
- 排除标记为待处理或跳过的测试
- 排除实验性功能的测试
- 排除遗留向后兼容性测试（除非 SDK 声称支持遗留）
层级晋升
SDK 维护者可以通过以下方式请求层级晋升：- 根据层级要求进行自我评估
- 在 modelcontextprotocol/modelcontextprotocol 仓库中开设问题并提供支持证据
- 通过自动化一致性测试
- 获得 SDK 工作组维护者的批准
层级降级
如果最新稳定版本上的现有连续性测试连续 4 周失败，SDK 可能会被移至较低层级：- Tier 1 → Tier 2：任何一致性测试失败
- Tier 2 → Tier 3：超过 20% 的一致性测试失败
问题分类标签
SDK 仓库必须使用一致的标签，以便启用关于问题处理指标的自动化报告。 层级计算使用这些指标来衡量分类响应时间（从问题创建到 首次标记的时间）和严重缺陷解决时间（从 P0 标记到问题关闭的时间）。类型（选一个）
| 标签 | 描述 |
|---|---|
bug | 某些功能无法工作 |
enhancement | 请求新功能 |
question | 请求更多信息 |
状态（选一个）
在所有仓库中使用这些确切的标签名称，以启用一致的报告和分析。| 标签 | 描述 |
|---|---|
needs confirmation | 不清楚是否仍然相关 |
needs repro | 信息不足以复现 |
ready for work | 已有足够信息可以开始 |
good first issue | 适合新人 |
help wanted | 欢迎熟悉代码库的人士贡献 |
优先级（仅当可操作时）
| 标签 | 描述 |
|---|---|
P0 | 严重：核心功能故障或高严重性安全 |
P1 | 影响许多用户的重大缺陷 |
P2 | 中等问题，有价值的功能请求 |
P3 | 锦上添花，罕见的边缘情况 |
- 安全漏洞，CVSS 评分 ≥ 7.0（高或严重级别）
- 核心功能故障，阻止基本 MCP 操作：连接建立、 消息交换或使用核心原语（工具、资源、提示）