MCP Server 的配置能否证明其工具能力会保持稳定？

MCP Server 配置不能证明工具能力会保持稳定。配置能展示 transport、启动命令、URL、参数、凭据引用、文件路径和 sandbox 等静态暴露面，却无法保证本地代码不被修改、远程服务不重新部署、同一版本号背后的工具定义不变化。稳定性只能通过不可变制品、持久化契约基线和重复运行验证逐步建立证据。

local 与 remote 回答的是可达性，不是稳定性

本地 stdio Server 可能直接运行 Git working tree 中的脚本，每次进程重启都加载磁盘最新内容；也可能由包管理器在启动时重新解析并下载代码。它虽然只本机，却可以是更新最频繁的 Server。

远程 HTTP Server 可以随时由运营方部署新版本，但也可能数月不变。因此 transport 主要回答进程在哪里、谁能访问、网络边界如何，不应被转化为“本地稳定、远程易变”的评分。

配置可以证明哪些静态事实

扫描 `mcp.json` 可以确认声明的连接类型、URL、command 与 args，识别是否使用包管理器启动、是否引用 latest 或未固定镜像、是否传入超出项目范围的文件路径，以及是否开启 sandbox。

还可以检查配置中是否出现明文凭据，或只是环境变量引用。后者降低配置文件直接泄密风险，但不能证明环境变量权限合理，也不能证明 Server 不会把凭据或数据发送到其他地方。

配置能证明“可能变化”，不能证明“不会变化”

`npx package`、`uvx package`、latest 标签和未固定容器镜像明确表示启动时可能重新解析代码，这是可观察的 change capability。扫描器应把它们标为需要关注。

但没有这些模式不等于稳定。固定的本地路径可以被覆盖，远程 URL 可以在后端切流，固定版本标签可以被错误重发，依赖锁之外的运行时配置也能改变行为。安全报告应避免给出无法证明的绿色“稳定”勾选。

版本字符串不是不可变证据

包版本、Server version 和 README 标注有助于关联发布，但本质上是声明。远程服务可以在不改版本号时部署新代码，内部脚本也可能没有正式版本。只比较字符串会漏掉实际契约漂移。

版本变化可作为触发重新检查的信号；版本未变则不能跳过检查。判断工具契约是否一致，仍要比较实际初始化信息和 `tools/list` 结果。

第一层证据：不可变制品

对于可打包 Server，优先解析到不可变制品，例如固定包版本及 lockfile、容器 image digest、签名发布包或内容寻址构建。记录制品摘要，并在启动前验证签名或 provenance。

这证明运行代码与已审查制品一致，但不能证明外部 API、数据库、动态配置或远程依赖没有变化。它控制供应链输入，不等于证明业务语义永久稳定。

工作树脚本需要内容基线

直接运行 `/path/to/server.py` 或仓库目录时，没有可供固定的发布制品。可以对入口脚本、依赖锁、关键模块和配置生成内容清单摘要，或先构建可审查制品再运行。

仅哈希入口文件可能漏掉动态 import 与模板。更可靠的是定义明确的构建上下文，排除日志和缓存等非运行内容，对真正参与执行的文件生成 manifest。开发态 Server 若频繁变化，应限制权限并避免继承长期批准。

第二层证据：观测到的能力契约

客户端连接后保存 Server 身份、协商协议版本、capabilities，以及完整工具名称、描述、inputSchema、outputSchema 和安全 annotations。规范化后计算摘要，并与此前持久化基线比较。

摘要必须跨客户端重启保留。若每次启动都把当前目录重新当作初始基线，恰好在客户端离线期间发生的变化会被静默吸收。基线应按 Server 身份、endpoint、租户和授权 scope 存储。

为什么“连接期间固定”仍不够

只在内存里保存当前 session 的工具摘要，可以发现连接存续期间的 listChanged，却无法发现 Server 重启或客户端关闭期间的变化。对于由进程重启加载新代码的本地 Server，变化与重新连接恰恰发生在同一时间。

新连接建立后，先读取持久基线、比较新目录，再决定是否沿用工具许可。不能因为 session age 为零就把所有能力视为新鲜和可信。

Schema 一致也不能证明行为稳定

Server 可以保持完全相同的工具名称和 Schema，却改变内部实现、数据源、排序、费用、写入对象或错误处理。契约摘要只能证明声明表面一致，不能证明相同输入仍产生同等语义结果。

这也是为什么稳定性无法由单一配置或哈希证明。摘要用于检测结构变化，运行测试用于检测行为变化，最小权限用于限制尚未检测出的风险。

第三层证据：可重复 canary

为关键只读工具设计固定输入和可机器检查的结果，定时通过真实客户端路径执行。比较成功率、结果结构、关键事实、p95 延迟、重试与空响应。结果逐步变差时，即使 Schema 未变也能发现。

高副作用工具不适合直接在生产反复调用。可以使用沙箱租户、dry-run、计划接口、模拟后端或只验证到执行前的确定性策略层。若无法安全 canary，应明确标记验证缺口，而不是假装它已被覆盖。

对副作用工具采用分层验证

第一步只验证工具仍存在、Schema 与批准基线一致。第二步在隔离环境执行完整调用。第三步在生产使用无副作用预览或查询对应资源状态。真正写入只在业务请求和明确批准下发生。

例如付款工具可以在测试商户执行小额模拟，在生产只调用 quote 或 validate；发消息工具使用测试收件箱；文件删除工具在临时目录验证。测试隔离必须由执行层保证，不能只要求模型“不要碰真实数据”。

风险评分应使用多轴模型

不要把 Server 压缩成 stable 或 unstable 一个标签。至少分别展示代码可变性、网络可达性、凭据暴露、文件范围、写入能力、契约漂移、行为 canary 覆盖和隔离强度。

本地 working-tree Server 可能网络不可达但代码高度可变；远程只读 Server 可能代码不可见但权限很小；固定 digest 的容器可能制品稳定却拥有整个主机文件系统。多轴信息比一个总分更能支持决策。

变更分类要避免告警疲劳

契约摘要变化后生成字段级 diff。工具删除、required 增加、类型收紧、annotations 转向 destructive 或扩大数据范围属于高优先级。工具新增和纯描述变化可以较低等级记录，但描述仍可能改变模型路由，不能完全忽略。

若所有变化都弹同样的阻断告警，用户会机械批准。UI 应展示变化字段、风险含义和旧新值，让人工判断有信息基础。

配置扫描结果应该怎样表达

推荐使用“已观察到”与“未验证”措辞。例如：已观察到启动时解析未固定包、已观察到明文 token、已观察到 workspace 外路径、未验证制品完整性、未建立持久契约基线、未运行行为 canary。

不要写“安全”“稳定”或“不会变化”，除非有明确、持续且覆盖对应范围的证据。即使所有检查通过，也只能说明在特定时间、身份和测试范围内未发现变化。

一个可落地的证据链

configuration scan
  -> declared exposure report

resolve launch target
  -> immutable artifact or content manifest

connect and discover
  -> persisted capability fingerprint

run safe scenarios
  -> behavioral canary evidence

enforce sandbox and policy
  -> bounded impact if assumptions fail

每层回答不同问题，不能互相代替。配置扫描最便宜，适合快速发现明显风险；运行时证据更接近真实能力；sandbox 与授权策略则在检测失败时限制损害。

测试扫描器自身

准备同一 Server 的多种配置：固定包、latest 包、本地 working tree、固定镜像 digest、远程 URL、带环境变量凭据和明文凭据。断言扫描器报告事实而不做过度稳定性推断。

随后保持配置不变，修改本地代码或远程工具 Schema，确认运行时基线能发现；保持 Schema 不变，修改 canary 行为，确认行为坚控能发现。这样证明三层各自覆盖的边界。

结论

MCP 配置能证明声明的启动与暴露方式，却不能证明工具能力未来稳定。local、remote、固定版本和未固定版本都只是风险信号，不是稳定性证明。

更可靠的单位是“不可变制品或内容清单 + 跨重启持久化的观测契约 + 安全 canary”。再配合最小权限、sandbox 和字段级变更分类，才能在不制造虚假绿色保证的前提下管理 MCP Server 的变化风险。