MCP 连上了，为什么任务还是没完成？

“MCP 已连接”通常意味着客户端和服务端建立了联系。如果工具列表里能看到“查询库存”，也只能说明有这个可调用能力。距离“查出缺货商品，再通知负责人”，还差参数、结果判断、收件人和发送权限。

连接层解决了什么

MCP 规范描述的是 host、client 和 server 的协作。宿主应用管理连接、用户授权和模型调用；服务端提供范围明确的工具、资源或提示内容。来源 1 这份分工让一个应用可以连接多个服务，但任务怎样串起来，仍要由应用安排。

本文引用 2025-06-18 版规范，讨论其中已经明确的职责划分，不把它称为本周刚发布的新功能。

工具清单不是工作流

工具可能叫 get_inventory，输入要求是仓库 ID 和 SKU 列表。用户只说“看看哪些商品快没货了”，应用还要知道查哪个仓库、低库存阈值是多少，以及是否包含预售订单。

这些缺失条件如果由模型自行猜测，接口也可能返回完全合法的结果。验证时除了检查调用成功，还应检查参数是否符合任务。工具 schema 能约束数据形状，不能替业务方决定“快没货”的含义。

返回成功以后，再查一次结果

MCP 工具协议把列举工具和调用工具分为不同消息；工具结果也有错误状态和不同内容形式。来源 2 因此，HTTP 连接正常、协议消息合法、业务操作成功，不能混成一个绿色状态灯。

对库存示例，可以先在测试仓库里放一组已知数量，确认查出来的 SKU 和数量一致。对于通知工具，还要验证消息是否到了预期收件人，而不是只看工具说“已发送”。

写入动作需要单独设计

查询库存通常可重复执行；发送两次同一条通知，却会产生两条消息。应用需要决定哪些动作允许自动重复、哪些要展示草稿，以及执行失败后如何核对是否已经生效。MCP 规范建议让用户能够了解并拒绝工具调用，但不会替每个业务系统实现这些规则。

选择 MCP 服务时，除了“能连上”，还应拿到输入示例、失败返回和权限说明。对读、写各做一条可核对的小任务，往往比一次接入十几个服务更容易定位问题。这里提供的是验收方法，未连接读者的库存或消息系统。