容器里的 MCP 首启动偏慢，超时阈值该按什么算
把开发机上跑得好好的 MCP 配置搬进容器，常见现象不是报错，是拉不到工具：连接建起来了，工具列表迟迟不回。同样的命令在开发机上一秒出结果，因为缓存早就热了。
差别不在算力，在缓存状态与出网策略——这两件事决定首启动要多久，也决定超时定多少。
先把耗时拆成三段
进程起来到工具列表返回有三段：spawn 与解释器启动、依赖解析与下载、握手与 tools/list 返回。第一段稳定，第二段波动最大，第三段通常最短。
本次采集到 server-time（Python，stdio，uvx mcp-server-time）首启动 7889ms，工具数 2，无认证。这个数字只代表首次，包含从头解析并下载依赖的时间；第二次起依赖已缓存，这一段几乎归零。
拿「首启动最大值」定阈值会出问题：它统计的是只发生一次的部署事件，不是稳态行为。
阈值按分位定，不按最大值
阈值的取样对象是热启动，取值用分位而不是极值。
| 统计量 | 从哪来 | 适合定什么 | 定错了会怎样 |
|---|---|---|---|
| 首次冷启动（本次 7889ms） | 一次部署事件 | 容器 readiness 的初始延迟 | 拿来定工具超时，慢 server 全部放行 |
| 热启动 p95 | 稳态多次采样 | 工具拉取的超时值 | 定得太紧，正常抖动就报错 |
| 宿主默认值（OpenCode 5000ms） | 平台默认 | 判断要不要预热 | 当能力上限用，会误判「不支持」 |
readiness 可以宽，工具超时要紧，宿主默认值只能当对照。
一个必须讲清的反例
数字上看 7889ms > 5000ms，而 OpenCode 默认只等 5000ms（documented），这个 server 似乎必然失败。
但本次 opencode 那一格实测是 pass（1.19.4），读到 2 个工具——说明 5000ms 判的是「从发起到拿到工具列表」，不是「进程启动总耗时」。依赖已缓存时这段远用不了 5 秒；7889ms 的大头在网络与解包，只发生在缓存缺失那次。
所以：用热启动分位定常态超时，用冷启动上界定预热与探针，别用一个数字管两件事。
出网：把运行时拉依赖挪到构建时
容器出网通常受白名单限制，运行时下载还会把不确定性带进生产，更稳的做法是构建时拉完：
FROM python:3.12-slim
RUN pip install --no-cache-dir uv
RUN uv tool install mcp-server-time
ENV UV_OFFLINE=1
后三行分别是拿 uv、固化依赖、断网运行；做完这步，首启动只剩 spawn 与握手。
ECS 侧的三个具体位置
安全组不管出站。 安全组默认只约束入站，出站能不能到包源取决于走弹性公网还是 NAT 网关，白名单要写在这两处而不是入方向。常见误解是入方向开一堆端口，出站照样被拦，表现成 uv 卡在下载。
镜像加速可以省掉这一步。 用 ACR 在构建阶段取完依赖、运行期只留 UV_OFFLINE=1，内网 DNS 解析不到包源的问题也一并绕开，代价是镜像变大。
规格影响的是并发而非单次启动。 7889ms 的大头在网络与解包，跟 vCPU 关系不大；同机并跑多个 stdio server 时内存才是瓶颈。本次没有多进程并发的样本，这里不给核数内存数。
VPC 内网还有一处：server 若要访问同 VPC 的数据库或内部 API，走内网域名能免公网往返，这类启动耗时不能套公网样本。
常驻还是按需
stdio 型 server 是「一个客户端一个进程」，随宿主起落，不适合长驻；要复用就得换成远程形态，用 streamable-http 包一层共享实例。
要常驻的话，健康检查不能只探端口——端口通只说明进程在，不说明 tools/list 有内容。本地合成样本 fixture-zero-tools 实测 17 个宿主全部判不可用，连接状态却可以是绿的；探测应发一次 tools/list 并判非空。
权限收敛
容器内跑 server，权限面就是它能读的范围：非 root、只读根文件系统、只挂载必要目录。
这和「零工具」直接相关：tools/list 返回空数组的常见来源之一就是路径不对或缺读权限——进程起得来、握手也成，只是没有工具可列。权限给多了是风险，给错了是静默失效。
无头环境里没有浏览器的坑
需要 OAuth 的远程 server 在容器里几乎无法完成授权：Gemini CLI 的 OAuth 自动发现要求本机可开浏览器、在 localhost:<port>/oauth/callback 接收重定向（documented），容器里没有浏览器，流程走不下去。
出路是在宿主机授权后把凭据带进来，或改用静态 token。把它记成「server 不可用」是误判——它只是没被验证。
总结
容器里的首启动慢在缓存与出网，不在协议；阈值按热启动分位定，冷启动上界留给探针与预热。想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：要把 MCP server 放进镜像的运维；在受限出网环境里部署的人；要给超时与探针定值的团队。
不适合：本地开发、缓存一直热的读者；想直接抄一个 timeout 数字的人——分位数得自己采；不涉及容器与出网的场景。
标签：MCP、DeepSeek Harness、容器部署、超时治理
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
