Skip to main content
MCP SDK 分级系统确立了官方和社区驱动 SDK 在功能完整性、协议支持及维护承诺方面的明确期望。这有助于开发者选择适合其需求的 SDK，并为 SDK 维护者提供一条明确的路径以提高采用期望。
关键日期：
  • 2026 年 1 月 23 日：一致性测试可用
  • 2026 年 2 月 23 日：官方 SDK 分级发布
在 1 月 23 日至 2 月 23 日之间，SDK 维护者可以与 一致性测试工作组合作采用测试，并使用下面定义的标准化标签设置 GitHub 问题 跟踪。

​
概述

SDK 根据功能完整性、维护承诺和文档质量分为三个层级：
  • Tier 1：完全支持的 SDK，具有完整的协议实现，包括所有 非实验性功能和可选能力，如采样和诱导
  • Tier 2：积极维护的 SDK，致力于完全协议规范支持
  • Tier 3：实验性、部分实现或专用的 SDK
任何层级都不要求支持实验性功能和协议扩展（如 Tasks 和 MCP Apps）。

​
层级要求

问题分类 意味着标记并确定问题是否有效，而非解决问题。 严重缺陷 指 P0 问题（详见 优先级标签 以获取 详细标准）。 稳定版本发布 是明确标记为生产就绪的已发布版本（例如，版本 1.0.0 或更高，不带 -alpha、-beta 或 -rc 等预发布标识符）。 清晰版本控制 意味着遵循惯用的版本控制模式并记录 破坏性变更策略，以便用户在升级时能够理解兼容性期望。 路线图 概述了具体的步骤和工作项，跟踪所需 MCP 规范组件的实施（一致性测试 中描述的非实验性功能和可选能力），让用户了解即将到来的功能支持情况。

​
一致性测试

所有 SDK 均使用 自动化一致性测试 进行评估， 该测试针对已发布的规范验证协议支持。SDK 根据测试结果获得一致性评分：
  • Tier 1：要求 100% 一致性
  • Tier 2：要求 80% 一致性
  • Tier 3：无最低要求
一致性评分仅针对 适用的必需测试 计算：
  • 针对 SDK 目标规范版本的测试
  • 排除标记为 pending 或 skipped 的测试
  • 排除实验性功能测试
  • 排除旧版向后兼容性测试（除非 SDK 声称支持旧版）
  • 排除在一致性仓库中标记为 disputed 的测试，直至争议解决
一致性测试通过运行标准化测试 场景并检查协议消息交换，验证 SDK 是否正确实现了协议。请参阅 层级降级 了解如何 处理临时测试失败。

​
层级晋升

SDK 维护者可以通过以下方式请求层级晋升：
  1. 根据层级要求进行自我评估
  2. 在 modelcontextprotocol/modelcontextprotocol 仓库中开设问题并提供支持证据
  3. 通过自动化一致性测试
  4. 获得 SDK 工作组维护者的批准
SDK 工作组审查晋升请求并做出最终层级分配。

​
层级降级

如果最新稳定版本上的现有连续性测试连续 4 周失败，SDK 可能会被移至较低层级：
  • Tier 1 → Tier 2：任何一致性测试失败
  • Tier 2 → Tier 3：超过 20% 的一致性测试失败
如果问题两个月内仍未得到处理，SDK 也可能会被降级。

​
问题分诊标签

SDK 仓库必须使用一致的标签，以便启用关于问题处理指标的自动化报告。 层级计算使用这些指标来衡量分类响应时间（从问题创建到 首次标记的时间）和严重缺陷解决时间（从 P0 标记到问题关闭的时间）。

​
类型（选一个）

使用 GitHub 原生问题类型 的仓库满足此要求，无需类型标签。

​
状态（选一个）

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

​
优先级（仅当可操作时）

P0（严重） 问题是：
  • 安全漏洞，CVSS 评分 ≥ 7.0（高或严重级别）
  • 核心功能故障，阻止基本 MCP 操作：连接建立、 消息交换或使用核心原语（工具、资源、提示）