SDK 分级体系

SDK 分级体系

社区译文；来源： MCP 80041ab0

MCP SDK 分级体系为官方和社区驱动 SDK 的功能完整性、协议支持和维护承诺建立明确预期。这有助于开发者选择适合自身需求的 SDK，也为 SDK 维护者提供一条提高采用预期的清晰路径。

关键日期：

在 1 月 23 日至 2 月 23 日之间，SDK 维护者可以与 Conformance Testing 工作组协作采用这些测试，并使用下文定义的标准化标签设置 GitHub issue 跟踪。

概述

SDK 按功能完整性、维护承诺和文档质量分为三个等级：

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

要求	Tier 1：全面支持	Tier 2：承诺全面支持	Tier 3：实验性
一致性测试	通过率 100%	通过率 80%	无最低要求
新协议功能	在新规范版本发布前完成；每次发布根据功能复杂度约定时间线	6 个月内	不承诺时间线
Issue 分类处理	2 个工作日内	一个月内	无要求
严重错误解决	7 天内	两周内	无要求
稳定发行版	必须提供并具有清晰版本控制	至少一个稳定发行版	不要求
文档	全面，所有功能均有示例	覆盖核心功能的基础文档	无最低要求
依赖策略	已发布更新策略	已发布更新策略	不要求
路线图	已发布路线图	已发布迈向 Tier 1 的计划，或说明保持 Tier 2 的原因	不要求

Issue 分类处理是指添加标签并判断 issue 是否有效，而不是解决 issue。

严重错误指 P0 issue（详细标准参见优先级标签）。

稳定发行版是明确标记为可用于生产环境的已发布版本（例如版本 1.0.0 或更高，且不含 -alpha、-beta 或 -rc 等预发布标识符）。

清晰版本控制是指遵循符合相应语言生态惯例的版本模式，并记录破坏性变更政策，使用户升级时能够理解兼容性预期。

路线图列出跟踪 MCP 规范必要组件实现情况的具体步骤和工作项（即一致性测试中所述的非实验性功能和可选能力），让用户了解即将提供的功能支持。

所有 SDK 均使用自动化一致性测试评估，以验证其对已发布规范的协议支持。SDK 根据测试结果获得一致性分数：

一致性分数仅根据适用的必需测试计算：

一致性测试通过运行标准化测试场景并检查协议消息交换，验证 SDK 是否正确实现协议。有关临时测试失败的处理方式，参见等级降级。

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

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

如果最新稳定发行版持续 4 周无法通过现有一致性测试，SDK 可能会被降至较低等级：

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

SDK 仓库必须使用一致的标签，以便自动报告 issue 处理指标。等级计算使用这些指标衡量分类响应时间（从 issue 创建到首次添加标签的时间）和严重错误解决时间（从添加 P0 标签到关闭 issue 的时间）。

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

所有仓库都应使用以下准确标签名称，以便进行一致的报告和分析。

P0（严重） issue 包括：