MCP连接≠工具调用正确：调试盲区警示

如果你在过去几个月里接入了一个 MCP 服务器，你可能已经注意到了图标变绿、工具列表被填充，这一切让人感觉最难的部分已经完成了。其实没有。真正的难题才刚刚开始。

MCP 是一个访问协议，而不是能力协议。它回答的是"这个 Agent 能否访问那个 API"——至于 Agent 是否正确地调用了那个 API，它完全不置一词。这是两个可以独立分析的失败模式，把它们混为一谈，正是大量调试时间被浪费在错误地方的原因。

连接状态所掩盖的失败

一个已连接的 MCP 服务器会愉快地放任 Agent：

猜一个参数名——接近正确但不完全正确——收到 schema 校验错误，静默重试换一个猜法，最终用错误的值而非预期的值调用成功。

调用一个普通读取端点而非分页端点，然后把第一页的内容总结为整个结果。

把错误响应 paraphrase 成听起来像成功的样子，因为在 Agent 自己的解释中，"调用完成了"和"调用做了我想做的事"被合并成了同一句话。

以上种种都不会以连接问题的形式出现。服务器在线，握手成功，工具图标是绿的。问题出在更上面一层——Agent 如何使用一个它技术上完全能触及的工具——这更容易被忽略，因为上游的一切看起来都很健康。

三个真正能发现问题的检查

1. 读取原始响应，而不是 Agent 的摘要。 在 Agent paraphrase 之前，先拿到工具调用返回的原始 JSON/输出。被悄悄截断、分页或部分报错的响应，一旦被摘要之后往往读起来像一次干净的成功——摘要恰好抹平了恰恰你最需要看到的东西。

2. 在信任写操作之前先手动抽查。 一次略微错误的读操作浪费一个轮次。一次略微错误的写操作——错误的 ID、错误的字段、错误的范围——会持久化。如果一个 Agent 即将重复执行同一次写操作（批量更新、批量插入），在无人值守地运行其余之前，先手动对实际系统做一次验证。

3. 当 schema 薄弱时，警惕参数猜测。 一些 MCP 服务器暴露的工具 schema 稀疏或模糊。一个 Agent 面对一个约束不足的参数时，会 pattern-match 一个看似合理的值而不是停下来询问——这正是"自信地调用错误"这个失败模式，只是被往上挪了一层。如果一个工具的 schema 不能完全约束其输入，无论这个服务器本身多可靠，这个工具都需要比那些 schema 完整的工具更密切的监督。

为什么这个问题一直在发生

这个协议的设计初衷是解决互操作性——一个工具建造一次，任何合规的 Agent 都可以使用——它做得很好。但互操作性和判断力是两个不同的问题。MCP 标准化了一个调用如何发出；对于"用这些参数做这个调用是否正确"它没有任何意见。这个判断必须来自别处——系统 prompt、skill，或者在最初几次调用时有人在旁边看着——而绿色的连接状态永远不会告诉你这个判断缺席了。

实际结论：把"MCP 服务器已连接"当作两步的第一步，而不是唯一的第一步。第二步——验证 Agent 实际上在良好地使用这个工具——不会出现在任何状态指示器里。你必须亲自去看。

Full write-up: https://agentkitworks.com/answers/what-is-mcp