MCP Server 上线前怎么检查？只读 Inspector 预检

MCP Server 上线前最常见的测试方式，是直接连 Inspector 然后点一个 Tool 看能不能执行。但对生产端点来说，这个顺序不一定合理。基础协议和目录能力完全可以先用只读请求验证，不需要先触发任何业务副作用。

MCP 2026-07-28 已经把核心改成 stateless request/response，并提供 server/discover。它可以一次返回 Server 支持的协议版本、能力和身份信息；随后再用 tools/list、resources/list、prompts/list 检查公开目录。对于需要鉴权的服务，HTTP challenge 本身也是重要的预检结果。

上线前先检查什么

我会把 preflight 分成六层：

Endpoint：URL 是否可达，TLS、重定向和 HTTP 状态是否符合预期；
Protocol：是否支持 2026-07-28，还是只能走 legacy 生命周期；
Discovery：server/discover 是否返回合法 JSON-RPC 结果以及支持的版本/能力；
Catalogs：tools/list、resources/list、prompts/list 是否能返回结构正确的目录；
Authorization：未授权访问时是否给出正确的 401/metadata/challenge，而不是返回含糊 500；
Operational signals：响应耗时、缓存提示、错误码是否稳定。

这六层通过以后，再进入真实 Tool 调用测试，会更容易定位失败究竟发生在协议层还是业务层。

MCP 服务器只读预检范围：server discover、tools list、resources list 与 prompts list

2026-07-28 的 server/discover 应该怎么看

现代 MCP Server 必须实现 server/discover。一个典型请求会携带协议版本、Client 信息和能力元数据，响应则可以告诉客户端：

supportedVersions；
capabilities；
Server identity；
可选的 instructions；
ttlMs / cacheScope 等缓存提示。

这里有两个容易误判的点。

第一，Client 不一定每次都必须先调用 server/discover。官方规范允许客户端直接发业务 RPC，再根据 UnsupportedProtocolVersionError 处理版本不兼容。

第二，Server 自报的 serverInfo 适合显示和调试，不应该被当成安全身份认证。真实授权仍然需要 OAuth、Token audience、权限和业务校验。

Modern MCP 与 Legacy MCP 在发现、元数据、兼容性和鉴权上的对比

为什么还要检查三个 list 方法

server/discover 告诉你“Server 声称支持什么”，而 list 方法让你观察“当前真正公开了什么”。

server/discover
  ↓
tools/list
resources/list
prompts/list

如果 capability 声明里有 Tools，但 tools/list 返回结构错误，你就知道问题不是网络连接，而是目录实现。如果一台 Server 的 Tools 数量在灰度发布后突然变成 0，也可以在真正调用业务动作之前发现。

MCP 预检鉴权状态判断：无鉴权、Bearer API Key、OAuth、401 与不兼容

XBSTACK 为什么只读

官方 MCP Inspector 本身是完整开发工具，Web/CLI/TUI 都可以执行 tools/call。这很适合开发者调试自己控制的 Server。

XBSTACK 的 MCP Inspector 对公开远程 endpoint采取更窄的边界：默认只做 discovery、兼容识别和第一屏 list，不发送 tools/call。原因不是“Tool 调用危险”这种泛化判断，而是公开在线检查器没有业务上下文，也不应该替用户触发一个未知 Tool 的副作用。

因此它更接近：

MCP endpoint preflight

而不是完整的交互式 MCP Client。

只读 MCP 检查与 tools call 执行操作的安全边界对照

我用同一套探测跑了 15 个公开端点

当前 MCP Protocol Radar 已把这套只读检查扩到 15 个公开远程端点，包括 Context7、Microsoft Learn、DeepWiki、GitHub、Vercel、Atlassian Rovo 和多组 Cloudflare MCP Server。

同一时间、同一探测边界下记录：

endpoint 是否可达；
modern / legacy / unknown；
protocolVersion；
tools/resources/prompts 数量；
auth challenge；
最近验证时间。

这类数据最适合做兼容性观察，不应该被包装成“谁的 MCP Server 最安全”或官方认证排行。

MCP Inspector 单端点预检结果示例：可达性、协议、鉴权、Tools、Resources 与 Prompts

MCP Inspector 与 MCP Radar 的关系：单端点深度检查与多端点生态观察

一个实用的上线顺序

1. 公共/受控环境只读 preflight
2. 确认协议与鉴权边界
3. 在测试账号调用只读 Tool
4. 验证写 Tool 的授权和确认
5. 验证失败、超时、重试、重复调用
6. 最后才放生产流量

如果第一步就出现 JSON-RPC parse error、目录为空、版本不匹配或 OAuth metadata 错误，先修基础问题，不要继续用真实业务 Tool 掩盖协议故障。

MCP 只读预检完整流程：端点、连通性、协议、鉴权、能力发现与结果输出

只读 PASS 代表什么，不代表什么

它代表这个端点在当前时间点通过了所执行的基础检查。

它不代表：

每个 Tool 都能成功；
Tool 权限一定最小化；
Tool 返回内容没有 prompt injection 风险；
Server 没有业务漏洞；
未来版本不会变化；
XBSTACK 或 MCP 官方对它进行了认证。

所以工具页会保留 verifiedAt、stale 和方法说明，而不是给一个永久“安全”标签。

如果你只是想确认远程 MCP endpoint 是否值得继续调试，可以先用 MCP Inspector 做只读预检；如果你要看多个公开 Server 的协议采用情况，可以直接看 MCP Protocol Radar。

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单订阅

小白 / Xiaobai

MCP Server 上线前怎么检查？用只读 Inspector 验证协议、Tools、Resources 和 Prompts