MCP 服务没挂，为什么工具调用会在排队时过期？

现象：健康检查通过，但某次调用就是失败

历史 MCP 排障笔记把几种看似矛盾的现象放在一起：Tunnel 仍健康、本地 MCP Server 仍运行、Shell 工作也可能继续执行，但上游报告 command response deadline reached。日志里还可能出现 retired stdio request。

这让我需要把“进程活着”与“这一轮请求能按时把结果交回去”分开看。前者只是服务健康，后者还受到排队时间、执行时间、多个独立 deadline共同约束。

从一次 GCP 运行日志找证据

原 Note 记录了一次 2026 年 9 月 30 日的历史日志统计：

• command response deadline reached 出现 17 次；
• 本地最大观察并发为 3；
• 275 次调用达到或超过 30 秒，169 次达到或超过 45 秒；
• 99 次接近 60 秒；
• 当时没有工具真正超过本地 61 秒的执行上限。

这组数据不足以证明所有失败都由队列造成，却足以提示：只把本地工具 timeout 设为 60 秒，并不能保证上游请求还有完整的 60 秒可以等待。

假设请求排队了 25 秒才开始执行，若上游的预算从请求建立时就开始扣减，真正留给后半段的时间就比本地 shell 允许的时间短。多个请求提前预取、队列没有背压时，这种错位更明显。

修复方向不是机械增大 timeout

我开始考虑三条改进路径：让同步 RPC 明显短于上游不可完全控制的 deadline；把超出同步预算的任务改成异步 Job；限制控制面的预取与执行并发，使请求不要在队列里白白消耗生命期。

这些调整的目标是减少排队时间对 RPC deadline 的消耗。真正是否解决了超时，还要查看任务队列和请求分布的变化，不能只靠把超时数字调大。

同样是 MCP 故障，Tunnel 身份导致的 404 与此不同：那一例优先检查链路身份；这里优先看请求生命周期和负载预算。

完整历史日志、调用预算和内部执行参数保留在私人技术笔记中。