“服务器启动了，tools/list返回一个干净的schema，所以它就在正常工作。”这几乎是每个接入MCP（模型上下文协议）服务的团队最先形成的直觉，但这份直觉正在制造大量掩耳盗铃式的集成故障。开发者很快会发现，一台MCP服务器能通过initialize握手、能广播完所有预计的工具，却依然在每一个实际调用里搞砸——因为认证跳转、租户边界、环境变量、下游权限或者只读角色已经悄然断裂。这种落差正是mcp-probe决定向真正CI门禁方向收缩的直接原因，而1.8.0版选择把“不充分”这件事摆上台面，让闹着玩式的自检彻底暴露在流水线里。

新版本没有增加炫目的大功能，而是把三处一直被敷衍的缺口焊接成了硬性检查。第一个转变直指灰色地带：警告现在可以终止CI流程。早前mcp-probe即便发现认证交接异常或权限告警，仍然返回exit 0，免得干扰老用户的自动化。但对于生产级门禁来说，把“降级运行”当成“通过”是不被容忍的。只要带上`--fail-on-warn`，工具立即引入一条零容忍规则——任何OAuth需要浏览器跳转而代理无法完成的情形、任何服务启动后每个工具调用都返回401的状态、任何数据库工具在管理员凭据下正常但在只读角色下失败的现象，或者工作流里虽提到了探测但根本没跑生产边界检查的步骤，都不再被悄悄放过。因为这些恰是最常见的软性崩溃，它们不报错，却让自动化代理在真实任务里反复死掉。

第二个收紧的动作落在工作流自身的合规证明上。`mcp-probe doctor`此前只要扫到GitHub Actions工作流存在就算交差，但新版本把验证逻辑推到了单次执行步骤的粒度上：关键标记必须出现在同一条mcp-probe实际运行命令里。简单说，如果CI里拆成两条命令来处理，比如一条不带`--github-summary`和`--fail-on-warn`的`npx @k08200/mcp-probe --config mcp-probe.config.json`，另一条在别的步骤里补齐这些标记，新版医生会判定门禁并未真正落地。它检查的是：有且只有那一步承载了完整的`npx @k08200/mcp-probe@latest --config mcp-probe.config.json --github-summary --fail-on-warn`，才能被视作“这扇门在用它信任的配置严控质量”。这背后的意图很明确——门禁不是配置片段的拼凑，它必须是一条完整的入口证据。

第三个变化把关注点从工具是否“存在”转向了工具是否“切实被验证”。在配置文件驱动的检查方式下，使用者可以声明期望的工具目录，同时给出`expectedTools`数组和`toolsFile`引用。一旦两者共存，每个期望的工具就都需要一份配套的侧车样本输入。这意味着CI不再满足于“这个工具有没有在列表上打勾”，而是进一步追问“依赖这个工具的代理，我们是否真的为它供了一个有意义的干跑样本？”原来的自动生成输入大多局限于模式校验，只证明结构没坏，却不触及实际语义。侧车输入的引入，实质上是把集成测试的合约提前锁入了门禁，让每一次提交都在演练代理将来会用到的那条真实路径。

从表面看，这些只是检查项的加重。但当门禁不再容忍静默降级、不再接受分散标记、不再把协议层面的列表视为工作的全部证据时，服务器的交付质量才会从“看起来连上了”逐步收敛到“任何时候都可信”。1.8.0没有发明新的安全框架，它只是把现实中反复栽坑的点焊成了混凝土，这正是基础设施化的MCP服务当下最需要的那份“无聊的稳定性”。