SDK 分级体系

MCP SDK 分级体系为官方和社区驱动的 SDK 在特性完整度、协议支持和维护承诺方面确立了明确的预期。这有助于开发者为其需求选择合适的 SDK，并为 SDK 维护者提供一条改进采用度预期的清晰路径。

​

概览

SDK 依据特性完整度、维护承诺和文档质量被划分为三个等级：

• Tier 1：完全受支持的 SDK，具有完整的协议实现，包括所有非实验性特性和诸如采样、征询之类的可选能力
• Tier 2：积极维护中、正朝着完整协议规范支持推进的 SDK
• Tier 3：实验性的、部分实现的或专门化的 SDK

任何等级都不要求实验性特性和协议扩展（例如 Tasks 和 MCP Apps）。

​

等级要求

Issue 分诊指为 issue 打标签并判定其是否有效，而非解决该 issue。 严重 Bug 指 P0 级 issue（详细标准见优先级标签）。 稳定发布指显式标记为可用于生产的已发布版本（例如版本 1.0.0 或更高，且不带 -alpha、-beta 或 -rc 之类的预发布标识符）。 清晰的版本控制指遵循惯用的版本控制模式，并有成文的破坏性变更政策，使用户在升级时能够理解兼容性预期。 路线图概述具体的步骤和工作项，用以跟踪对所需 MCP 规范组件（合规测试中所述的非实验性特性和可选能力）的实现，让用户能够看到即将到来的特性支持。

​

合规测试

所有 SDK 都使用自动化合规测试进行评估，这些测试依据已发布的规范验证协议支持。SDK 会根据测试结果获得一个合规分数：

• Tier 1：要求 100% 合规
• Tier 2：要求 80% 合规
• Tier 3：无最低要求

合规分数仅针对适用的必需测试计算：

• 针对该 SDK 所面向规范版本的测试
• 排除标记为待定或跳过的测试
• 排除针对实验性特性的测试
• 排除遗留的向后兼容测试（除非该 SDK 声称支持遗留特性）
• 排除在合规仓库中标记为 disputed 的测试，直至争议解决

合规测试通过运行标准化的测试场景并检查协议消息交换，来验证 SDK 是否正确实现了协议。关于临时测试失败如何处理，参见等级降级。

​

等级晋升

SDK 维护者可以通过以下方式请求等级晋升：

1. 对照等级要求进行自评
2. 在 modelcontextprotocol/modelcontextprotocol 仓库中开一个 issue，附上支撑证据
3. 通过自动化合规测试
4. 获得 SDK 工作组维护者的批准

SDK 工作组评审晋升请求并作出最终的等级认定。

​

等级降级

如果最新稳定发布版本上的既有合规测试连续 4 周失败，某个 SDK 可能被移至较低等级：

• Tier 1 → Tier 2：任何一项合规测试失败
• Tier 2 → Tier 3：超过 20% 的合规测试失败

如果 issue 有两个月未获处理，某个 SDK 也可能被降级。

​

Issue 分诊标签

SDK 仓库必须使用一致的标签，以便对 issue 处理指标进行自动化报告。等级计算使用这些指标来度量分诊响应时间（从 issue 创建到首次打标签的时间）和严重 bug 解决时间（从打上 P0 标签到 issue 关闭的时间）。

​

类型（选其一）

使用 GitHub 原生 issue 类型的仓库无需类型标签即可满足此要求。

​

状态（选其一）

在所有仓库中使用这些精确的标签名称，以实现一致的报告和分析。

​

优先级（仅在可执行时）

P0（严重） issue 是指：

• CVSS 分数 ≥ 7.0（高或严重等级）的安全漏洞
• 阻碍基本 MCP 操作的核心功能失败：连接建立、消息交换，或核心原语（工具、资源、提示）的使用