MCP服务器会静默失败。你的仪表盘不会告诉你。

你的MCP服务器对每个请求都返回200 OK。你的仪表盘一片绿色。你的用户却很沮丧。

HTTP状态码衡量的不是这里真正重要的东西。工具返回了数据。它是正确的工具吗？响应有用吗？模型真的用了吗？

Anthropic公开的一项对代理工具使用的评测（MCP Bench，2025年末）测得超过六个工具的主流MCP服务器上工具选择错误率在28%到46%之间。生产环境也呈现同样的模式：服务器日志里写着完美的正常运行时间、低于200ms的延迟、零5xx错误——而模型将近一半的时间在调用错误的工具。

服务器不知道。团队不知道。用户只是说AI不好用。

这就是静默故障。一个MCP服务器可以通过每一项传统健康检查，仍然在每次调用上回答错误的问题。

对于REST API，正常工作意味着接受有效请求并返回正确响应。验证这点的工具已经存在了几十年。

对于MCP服务器，正常工作是一条四步链。模型选对工具。发送正确的参数。收到有用的响应。把响应整合进回答。每一步都可能独立失败。这些失败没有一个会出现在传统监控里。

工具错了？200。参数通过了schema校验但偏离了用户意图？200。响应被忽略了？200。

你可以在仪表盘上看到100%的成功率，而生产中只有40%。用户就在那条鸿沟里说"AI不好用"——不管SRE指标怎么说，他们都没错。

一旦你接受传统指标不够用，问题就变成该衡量什么。五件事。

**工具选择准确率。** 如果你有`search_invoices`和`list_documents`，用户要"上个月的发票"，哪个被调用了？追踪预期选择和实际选择之间的差距。这是MCP可观测性里最具揭示性的指标。

**参数有效性。** 不是参数是否通过schema校验——那是底线。日期范围和用户要求匹配吗？搜索查询捕捉了他们的意图吗？

**响应利用率。** 模型真的用了响应吗？如果你返回了50行而模型在回答中一行都没引用，那要么工具描述不对，要么格式不对，要么数据不相关。

**错误恢复率。** 当调用失败时，模型是带着修正后的参数重试、换工具，还是放弃？恢复模式告诉你错误消息是否有用。

**每次成功调用的成本。** 不是每次调用的成本。是每次产出有用答案的调用的成本。浪费的重试和用错工具的调用通常会把实际成本推到原始API支出的3-5倍。

这五个比所有传统指标加起来更能说明MCP服务器的健康。

Datadog、New Relic和Grafana在它们的领域都很出色。它们追踪延迟分布、错误率、吞吐量和资源利用率。对于调用方是浏览器或移动应用、发送确定性请求的API来说，这是对的形态。

MCP服务器的调用方不是确定性的。它是在推理时做决策的模型。故障模式不是"请求超时"。是"模型判断这是正确的工具，但其实不是"。这是决策质量问题，传统APM不是为衡量决策质量而造的。

具体来说：如果你的代理同时拥有`get_customer`和`search_customers`，而模型总是用猜测的ID选`get_customer`，你的p99一直平稳，错误率一直平稳，但每一次用户交互都以失败告终。现有工具没有信号可以发出。

你需要在模型和工具之间加一层可观测性——一层能把用户意图、工具选择、参数和响应利用率关联起来。传统APM是地板。对于MCP服务器来说，它连一半都算不上。

先做的三件具体事情。不必一步到位。

**1. 用完整prompt上下文记录每次调用。** 不只是工具名和参数。导致调用的对话、系统prompt、用户最后一条消息。没有上下文就无法评估选择是否正确。

**2. 追踪预期工具对比选中工具。** 你需要基准真值——样本上的人工标注、用户的点赞点踩信号，或启发式规则（一个匹配"发票|账单|付款"的用户问题却落到`list_contacts`调用，那就是缺陷）。粗糙的启发式也比没有强。

**3. 衡量响应利用率。** 把工具返回的内容和模型最终回答中出现的内容做对比。大的差距意味着响应格式不对、数据不相关，或者工具描述没有帮助模型使用结果。

这三个信号——调用上下文、选择准确率、响应利用率——告诉你MCP服务器是否真正在帮用户。五个九的正常运行时间仪表盘告诉你进程还活着。这是两个不同的问题。