SDK 分级体系

Model Context Protocol SDK 的功能完整度、协议支持与维护承诺等级

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

NOTE

关键日期：

2026 年 1 月 23 日：一致性测试可用
2026 年 2 月 23 日：官方 SDK 分级发布

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

概述

SDK 根据功能完整度、维护承诺与文档质量分为三个等级：

Tier 1：完全支持的 SDK，具备完整的协议实现，包括所有非实验性功能以及诸如采样与征询之类的可选能力
Tier 2：积极维护的 SDK，正在朝着完整协议规范支持的方向推进
Tier 3：实验性、部分实现或专用型 SDK

实验性功能与协议扩展（例如 Tasks 与 MCP Apps）对任何等级都不是必需的。

等级要求

Requirement	Tier 1: Fully Supported	Tier 2: Commitment to Full Support	Tier 3: Experimental
Conformance Tests	100% pass rate	80% pass rate	No minimum
New Protocol Features	Before new spec version release, timeline agreed per release based on feature complexity	Within 6 months	No timeline commitment
Issue Triage	Within 2 business days	Within a month	No requirement
Critical Bug Resolution	Within 7 days	Within two weeks	No requirement
Stable Release	Required with clear versioning	At least one stable release	Not required
Documentation	Comprehensive with examples for all features	Basic documentation covering core features	No minimum
Dependency Policy	Published update policy	Published update policy	Not required
Roadmap	Published roadmap	Published plan toward Tier 1 or explanation for remaining Tier 2	Not required

Issue Triage 指为 issue 打标签并判断其是否有效，而非解决该 issue。

Critical Bug 指 P0 级 issue（详细标准见 Priority labels）。

Stable Release 指明确标记为生产就绪的已发布版本（例如版本 1.0.0 或更高，且不带 -alpha、-beta 或 -rc 之类的预发布标识符）。

Clear Versioning 指遵循惯用的版本管理方式并记录破坏性变更策略，使用户在升级时能够理解兼容性预期。

Roadmap 概述跟踪所需 MCP 规范组件（如一致性测试中所述的非实验性功能与可选能力）实现情况的具体步骤与工作项，让用户了解即将支持的功能。

一致性测试

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

Tier 1：要求 100% 一致性
Tier 2：要求 80% 一致性
Tier 3：无最低要求

一致性得分仅针对适用的必需测试计算：

针对 SDK 所面向规范版本的测试
排除标记为 pending 或 skipped 的测试
排除实验性功能的测试
排除传统向后兼容性测试（除非该 SDK 声明支持传统版本）
排除一致性仓库中标记为 disputed 的测试，直至争议解决

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

等级晋升

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

对照等级要求进行自评
在 modelcontextprotocol/modelcontextprotocol 仓库中提交 issue 并附上支持性证据
通过自动化一致性测试
获得 SDK 工作组维护者的批准

SDK 工作组负责审查晋级请求并做出最终层级评定。

层级降级

如果最新稳定版上的现有一致性测试连续 4 周失败，SDK 可能会被移至较低层级：

Tier 1 → Tier 2：任何一致性测试失败
Tier 2 → Tier 3：超过 20% 的一致性测试失败

如果问题在两个月内仍未得到处理，SDK 也可能被降级。

Issue 分类标签

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

类型（选择一项）

标签	描述
`bug`	某些功能无法正常工作
`enhancement`	新功能请求
`question`	请求提供更多信息

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

状态（选择一项）

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

标签	描述
`needs confirmation`	尚不清楚是否仍然相关
`needs repro`	信息不足以复现
`ready for work`	已有足够信息可以开始
`good first issue`	适合新手
`help wanted`	欢迎熟悉代码库的人贡献

优先级（仅在可操作时）

标签	描述
`P0`	关键：核心功能故障或高严重性安全问题
`P1`	影响许多用户的重大 bug
`P2`	中等程度的问题、有价值的功能请求
`P3`	锦上添花的功能、罕见的边缘情况

P0（关键） issue 包括：

安全漏洞，CVSS 评分 ≥ 7.0（高或严重级别）
核心功能故障，导致基本 MCP 操作无法进行：连接建立、消息交换或核心原语（工具、资源、提示模板）的使用