内容
# mcp-spec-check
[](https://www.npmjs.com/package/mcp-spec-check)
[](https://github.com/Roee-Tsur/mcp-spec-check/actions/workflows/ci.yml)
> 您的远程MCP服务器是否已准备好迎接 **2026-07-28 MCP规格发布**？30秒内即可了解。
```bash
npx mcp-spec-check https://your-server.com/mcp
```
> **7月28日不会发生任何问题。** 该日期是规格文本发布的日子，而不是一个开关。版本协商继续有效，废弃的功能至少保留12个月。该工具衡量的是新无状态核心的 **采用率**，而不是倒数计时到故障。
[MCP 2026-07-28发布](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) 是自启动以来最大的协议修订版。`initialize` 握手和 `Mcp-Session-Id` 被删除，取而代之的是无状态核心，`Mcp-Method` / `Mcp-Name` 路由头成为必填项，SSE诱导被多轮请求取代，多个错误代码发生变化。SDK和客户端已经迁移到无状态核心，因此如果服务器不迁移，在支持窗口过期时就会被落下。`mcp-spec-check` 对您的实时端点进行黑盒探测（无需代码访问），并告诉您当前的状态，提供迁移文档的链接。
## 生态系统扫描
我于2026-07-12探测了官方MCP注册表中所有远程服务器，共计7,850个。在可以公开访问的4,356个服务器中，恰好有1个通过了所有三个必填检查，90.8%尚未准备就绪。迁移到无状态核心刚刚开始，这是在规格正式发布前可以预料的。完整的报告，包括每个百分比及其分母，以及主机折叠的敏感性视图： **[docs/scan-2026-07.md](docs/scan-2026-07.md)** （已提交的聚合数据： [scan-2026-07.aggregates.json](docs/scan-2026-07.aggregates.json)).
## 检查内容
报告首先给出一行判决， **`准备好迎接2026-07-28：是 / 否 / 未知`**, 仅由以下三个必填检查决定（`discover`，`routing-headers`，`session-independence`）：所有三个检查通过给出“是”，任何一个检查失败给出“否”，否则给出“未知”。每个检查后的字母等级作为次要信号。
只有前三个检查会失败服务器。其余检查是 `warn`: 可选或前瞻性检查，单独不会计为“未准备好”。
如果服务器的答案过于模糊，检查标记为 `inconclusive`，与跳过检查一样，不计入评分。如果太多检查结果为`inconclusive`，工具报告等级 `?`（“无法评估”，退出代码2），而不是猜测。
| 检查 | 含义 |
| --- | --- |
| `discover` | `server/discover` 取代了初始化握手；服务器必须实现它 |
| `routing-headers` | `Mcp-Method` / `Mcp-Name` 在每个请求上是必需的，以便网关可以路由 |
| `session-independence` | 协议级会话被删除；会话固定的服务器无法在负载均衡器后面提供无状态核心服务 |
| `error-codes` | （警告）资源未找到从 `-32002` 重新编号为 `-32602` |
| `cache-metadata` | （警告）新的 `ttlMs` / `cacheScope` 在列表/读取结果上的缓存元数据 |
| `mrtr` | （警告）结果带有 `resultType` 字段（多轮请求取代SSE诱导） |
| `deprecated-features` | （警告）依赖于废弃的日志记录或删除的 `resources/subscribe` 功能 |
| `auth-metadata` | （警告）OAuth受保护的资源元数据（RFC 9728）在 `/.well-known/oauth-protected-resource` 处可发现 |
## 判决验证
探测的正确性是关键，因此每个检查都针对已知的真实服务器进行验证，而不仅仅是断言：
- **两个参考服务器在CI中运行。** 一个真正的旧规格服务器（官方SDK v1）和一个RC服务器（2026-07-28 SDK测试版）在每次构建时启动，`mcp-spec-check`必须对这两个服务器的所有八个检查产生预期的判决（`npm run verify:refs`）。任一方向的回归都会导致构建失败。
- **一个已知的真实面板** 交叉检查具有已建立行为的实时公共服务器，包括GitHub的MCP服务器（身份验证墙，RFC 9728通过）和应该读取为未准备好或不确定的服务器。
- 官方 [一致性套件](https://github.com/modelcontextprotocol/conformance) 在RC参考服务器上运行，作为独立的共同预言者。
如果工具对您的服务器给出了错误的判决，这是一个最高优先级的错误。请提交问题并附上 `--json` 输出。
## 用法
```bash
npx mcp-spec-check <url> # 人类可读的报告 + 字母评分
npx mcp-spec-check <url> --json # 机器可读，用于脚本
npx mcp-spec-check <url> --verbose # 包括每个检查的“原因”
npx mcp-spec-check <url> --timeout 30000 # 每次探测的超时时间（毫秒）（默认15000）
```
### 身份验证服务器
```bash
npx mcp-spec-check <url> --bearer <token> # 发送 Authorization: Bearer <token>
npx mcp-spec-check <url> --header "X-Api-Key: k" # 任意头部；可重复
```
在没有凭证的情况下，`mcp-spec-check` 可以对身份验证墙服务器进行分类，但无法对其进行评分：检查报告为 `skipped`，退出代码为2（无法测试）。`auth-metadata` 检查仍然运行，因为其RFC 9728探测 `/.well-known/oauth-protected-resource` 是源级别的，不需要令牌，因此即使在墙后，也可以获得就绪信号。
### CI
退出代码是CI友好的：`0` 已准备好，`1` 至少有一个检查失败，`2` 无法测试（探测错误；端点身份验证墙 / 无法访问 / 不是MCP；或者服务器对我们的探测回应过于模糊，无法评分）。
```yaml
- run: npx mcp-spec-check ${{ env.MCP_SERVER_URL }}
```
## 工作原理
纯黑盒HTTP探测您的实时端点。无需代码访问，无需安装任何东西，也无需存储任何东西。运行时依赖项为零。
**探测伦理。** 注册表扫描仅触及官方公共MCP注册表中发布的端点作为连接URL。探测是主机串行的（每个主机一次请求，因此没有服务器看到并行负载），只读协议调用，无副作用，发送带有命名 `mcp-spec-check-scan` 用户代理的请求，该请求链接回此存储库。每个服务器的结果保留在运行扫描的机器上；仅发布聚合计数和百分比。
## 与其他工具的比较
官方 [一致性套件](https://github.com/modelcontextprotocol/conformance) 是一个规范测试框架，供实现者使用，包括草案规范场景，您需要将其与自己的代码连接起来。[YawLabs/mcp-compliance](https://github.com/YawLabs/mcp-compliance) 将A到F的合规性评分应用于 *当前* 2025-11-25规格。官方检查工具用于交互式调试。`mcp-spec-check` 不是其中任何一个：它是针对 *下一个* 版本（2026-07-28）的30秒黑盒判决，针对托管的URL。
## 贡献
欢迎提出问题和PR，参见 [CONTRIBUTING.md](CONTRIBUTING.md)。探测正确性是首要任务：如果判决看起来是错误的，请附上 `--json` 输出。
## 许可证
MIT
MCP 市场