SDK 分级系统

Documentation Index

Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt

Use this file to discover all available pages before exploring further.

MCP SDK 分级系统确立了官方和社区驱动 SDK 在功能完整性、协议支持及维护承诺方面的明确期望。这有助于开发者选择适合其需求的 SDK，并为 SDK 维护者提供一条明确的路径以提高采用期望。

​

概述

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

• Tier 1：完全支持的 SDK，具有完整的协议实现，包括所有 非实验性功能和可选能力，如采样和诱导
• Tier 2：积极维护的 SDK，致力于完全协议规范支持
• Tier 3：实验性、部分实现或专用的 SDK

实验性功能（如任务）和协议扩展（如 MCP 应用）不是 任何层级的必需项。

​

层级要求

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

​

一致性测试

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

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

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

• 针对 SDK 目标的规范版本的测试
• 排除标记为待处理或跳过的测试
• 排除实验性功能的测试
• 排除遗留向后兼容性测试（除非 SDK 声称支持遗留）

一致性测试通过运行标准化测试 场景并检查协议消息交换，验证 SDK 是否正确实现了协议。请参阅 层级降级 了解如何 处理临时测试失败。

​

层级晋升

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

1. 根据层级要求进行自我评估
2. 在 modelcontextprotocol/modelcontextprotocol 仓库中开设问题并提供支持证据
3. 通过自动化一致性测试
4. 获得 SDK 工作组维护者的批准

SDK 工作组审查晋升请求并做出最终层级分配。

​

层级降级

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

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

​

问题分类标签

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

​

类型（选一个）

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

​

状态（选一个）

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

​

优先级（仅当可操作时）

P0（严重） 问题是：

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