> ## Documentation Index > Fetch the complete documentation index at: https://mcp-zh.com/llms.txt > Use this file to discover all available pages before exploring further. # SDK 分级体系 > 模型上下文协议 SDK 的特性完整度、协议支持和维护承诺等级 MCP SDK 分级体系为官方和社区驱动的 SDK 在特性完整度、协议支持和维护承诺方面确立了明确的预期。这有助于开发者为其需求选择合适的 SDK，并为 SDK 维护者提供一条改进采用度预期的清晰路径。 **关键日期：** * **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）。 ## 等级要求 | 要求 | Tier 1：完全受支持 | Tier 2：承诺完整支持 | Tier 3：实验性 | | ------------- | ---------------------------- | ---------------------------------- | ---------- | | **合规测试** | 100% 通过率 | 80% 通过率 | 无最低要求 | | **新协议特性** | 在新规范版本发布之前，时间线基于特性复杂度按发布逐一约定 | 6 个月内 | 无时间线承诺 | | **Issue 分诊** | 2 个工作日内 | 一个月内 | 无要求 | | **严重 Bug 解决** | 7 天内 | 两周内 | 无要求 | | **稳定发布** | 必需，且有清晰的版本控制 | 至少一个稳定发布 | 不要求 | | **文档** | 全面，且为所有特性提供示例 | 涵盖核心特性的基础文档 | 无最低要求 | | **依赖政策** | 已发布的更新政策 | 已发布的更新政策 | 不要求 | | **路线图** | 已发布的路线图 | 已发布的迈向 Tier 1 的计划，或对停留在 Tier 2 的说明 | 不要求 | **Issue 分诊**指为 issue 打标签并判定其是否有效，而非解决该 issue。 **严重 Bug** 指 P0 级 issue（详细标准见[优先级标签](#优先级（仅在可执行时）)）。 **稳定发布**指显式标记为可用于生产的已发布版本（例如版本 `1.0.0` 或更高，且不带 `-alpha`、`-beta` 或 `-rc` 之类的预发布标识符）。 **清晰的版本控制**指遵循惯用的版本控制模式，并有成文的破坏性变更政策，使用户在升级时能够理解兼容性预期。 **路线图**概述具体的步骤和工作项，用以跟踪对所需 MCP 规范组件（[合规测试](#合规测试)中所述的非实验性特性和可选能力）的实现，让用户能够看到即将到来的特性支持。 ## 合规测试 所有 SDK 都使用[自动化合规测试](https://github.com/modelcontextprotocol/conformance)进行评估，这些测试依据已发布的规范验证协议支持。SDK 会根据测试结果获得一个合规分数： * **Tier 1**：要求 100% 合规 * **Tier 2**：要求 80% 合规 * **Tier 3**：无最低要求 合规分数仅针对**适用的必需测试**计算： * 针对该 SDK 所面向规范版本的测试 * 排除标记为待定或跳过的测试 * 排除针对实验性特性的测试 * 排除遗留的向后兼容测试（除非该 SDK 声称支持遗留特性） * 排除在合规仓库中标记为 `disputed` 的测试，直至争议解决 合规测试通过运行标准化的测试场景并检查协议消息交换，来验证 SDK 是否正确实现了协议。关于临时测试失败如何处理，参见[等级降级](#等级降级)。 ## 等级晋升 SDK 维护者可以通过以下方式请求等级晋升： 1. 对照等级要求进行自评 2. 在 [modelcontextprotocol/modelcontextprotocol](https://github.com/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 关闭的时间）。 ### 类型（选其一） | 标签 | 描述 | | ------------- | -------- | | `bug` | 某处无法正常工作 | | `enhancement` | 新特性请求 | | `question` | 需要进一步的信息 | 使用 [GitHub 原生 issue 类型](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization)的仓库无需类型标签即可满足此要求。 ### 状态（选其一） 在所有仓库中使用这些精确的标签名称，以实现一致的报告和分析。 | 标签 | 描述 | | -------------------- | ----------- | | `needs confirmation` | 不确定是否仍然相关 | | `needs repro` | 信息不足以复现 | | `ready for work` | 有足够的信息可以开始 | | `good first issue` | 适合新人 | | `help wanted` | 欢迎熟悉代码库的人贡献 | ### 优先级（仅在可执行时） | 标签 | 描述 | | ---- | ------------------ | | `P0` | 严重：核心功能失败或高严重性安全问题 | | `P1` | 影响许多用户的重大 bug | | `P2` | 中等问题、有价值的特性请求 | | `P3` | 锦上添花的需求、罕见的边界情况 | **P0（严重）** issue 是指： * CVSS 分数 ≥ 7.0（高或严重等级）的**安全漏洞** * 阻碍基本 MCP 操作的**核心功能失败**：连接建立、消息交换，或核心原语（工具、资源、提示）的使用