mcp-release-qa

MCP 发布质量保证

测试用户实际运行的服务。架构审查或单元测试通过，并不构成运行时证据。

此技能是安全审查的补充，重点关注协议行为、已发布契约偏差、传输正确性和可复现的发布证据。

规则

• 针对由候选修订版本构建的新鲜服务进程运行检查。
• 在同一会话中完成 initialize、notifications/initialized、发现和调用。新进程就是新的 STDIO 会话。
• 将源码中的注册内容视为实现事实，并将公开文档视为必须与之匹配的契约。
• 记录准确的命令和原始响应。不要用“看起来没问题”代替缺失的证据。
• 不要针对生产数据调用具有变更能力的工具。请使用测试夹具或沙盒；如果没有安全的测试环境，则停止并指出缺失项。
• 每次运行都要根据候选源码推导预期能力清单。

1. 确定发布范围

识别以下内容：

• 候选提交和构建命令；
• 服务入口点和传输方式：STDIO、Streamable HTTP 或 SSE；
• 支持的 MCP 协议版本；
• 注册工具、资源、资源模板和提示词的源码文件；
• 生成的目录、清单、README 表格和安装说明；
• 现有的协议、集成和冒烟测试命令。

优先使用仓库原生命令。自行设计测试框架之前，请先检查 package.json、pyproject.toml、Makefile、CI 工作流和贡献者说明。

2. 启动干净的服务

构建候选版本，并使用安全的测试配置启动文档所述的入口点。记录：

• 准确的命令；
• 提交 SHA；
• 环境变量名称，值需脱敏；
• 标准输出、标准错误和退出状态；
• 客户端使用的端点或子进程传输方式。

对于 STDIO，标准输出只能用于协议通信。日志、启动横幅和堆栈跟踪应输出到标准错误。对于 HTTP 传输，记录状态、相关 MCP 标头和会话标识符的处理方式，但不要打印凭据。

如果服务无法按照文档中的说明启动，请将其报告为发布失败，并逐字保留启动错误。

3. 执行一个完整会话

通过真实的 MCP 客户端或仓库的集成测试框架运行以下序列：

1. 使用服务声称支持的协议版本执行 initialize。
2. 确认协商后的版本和公布的能力。
3. 发送 notifications/initialized。
4. 调用 ping。
5. 调用每个受支持的发现方法：
   • tools/list
   • resources/list
   • resources/templates/list
   • prompts/list
6. 从每种已公布的能力类别中至少选取一项只读内容进行验证。
7. 如果列表方法支持分页，则持续翻页，直到没有游标为止。

不要通过单次运行即结束的独立进程发送初始化后的请求。那样测试的是多个不完整会话，而不是一个有效会话。

4. 证明清单一致性

根据当前证据构建四份清单：

范围	证据
源码	已注册的工具、资源、模板和提示词定义
运行时	实时发现方法的结果
生成的元数据	目录、清单或生成的索引
文档	README、参考页面和安装输出

按稳定标识符进行比较。报告：

• 源码中存在但运行时缺失的条目；
• 运行时存在但元数据或文档中缺失的条目；
• 过时的名称、描述、参数、URI 或提示词参数；
• 无法启动候选服务的文档安装命令。

使用仓库自身的构建命令重新生成派生文件。如果工作树中仍有无法解释的生成文件变更，则判定失败。

5. 检查已发布契约

对于每个发现的条目，将运行时定义与其源码进行核对：

工具

• 名称和描述应稳定且具体。
• inputSchema 应在需要时定义类型、必填字段、枚举值和边界。
• 工具契约为封闭时，应拒绝未知属性。
• 关于修改操作、幂等性、只读行为和开放世界的注释应与实际行为一致。
• 如果发布了 outputSchema，成功调用应符合该定义。
• 错误应为协议错误或结构化工具失败，不应泄露堆栈跟踪。

资源和模板

• URI 和 MIME 类型应与注册的定义一致。
• 静态资源应可读取。
• 模板参数应在解析前进行验证。
• 对缺失或禁止访问的资源应明确报错。

提示词

• 必填和可选参数应与发现结果一致。
• 对有效参数调用 prompts/get 应返回可用消息。
• 对缺少必填参数的请求和未知提示词名称应明确报错。

6. 测试失败路径

至少测试以下情况：

• 初始化完成前收到请求；
• JSON 格式错误或 JSON-RPC 信封无效；
• 未知方法；
• 不支持的协议版本；
• 重复初始化；
• 未知的工具、资源和提示词名称；
• 缺少、多余、类型错误和超出范围的参数；
• 请求大小达到文档规定的传输限制，以及超过该限制的请求；
• 受控的内部故障，且凭据和堆栈跟踪已脱敏。

验证每个响应的请求 ID 正确、错误消息有用，且不会产生成功的副作用。对于 STDIO，还应确认每一行 stdout 都是完整的协议消息，并且健康会话的 stderr 保持干净，除非服务端明确记录了诊断输出。

7. 安装冒烟测试

当项目发布了安装命令时：

1. 在源码检出目录之外创建临时目标目录。
2. 严格按照文档运行公开的安装命令。
3. 启动已安装的产物，确保不依赖源码树中的文件。
4. 重复初始化、发现和一次只读调用。
5. 保存命令输出后，删除临时目标目录。

仅检查过但未实际运行的安装命令未经验证。

8. 报告证据

使用以下格式：

# MCP Release QA

Candidate: [commit]
Transport: [STDIO | Streamable HTTP | SSE]
Verdict: PASS | PASS WITH CAVEATS | FAIL

## Commands and results
- `[exact command]` — [exit status and result]

## Session transcript
- initialize: [result]
- discovery: [result]
- representative calls: [result]
- negative paths: [result]

## Parity
| Identifier | Source | Runtime | Metadata | Docs | Result |
|---|---|---|---|---|---|

## Findings
| Severity | Evidence | Impact | Narrowest fix |
|---|---|---|---|

## Missing evidence
- [check that could not run and why]

如果服务端无法启动、无法完成有效会话、无法保持传输内容可解析，或无法安全拒绝无效输入，则标记为 FAIL。仅当文档或元数据存在有限偏差，且不会误述危险能力时，才标记为 PASS WITH CAVEATS。其他情况标记为 PASS。