接上 MCP 后，模型就自动会用所有业务系统了吗？

接上MCP后，模型就自动会用所有业务系统了吗？

把“连上了”拆成一条可检查的路线

仍然查询红笔库存。现在库存不在本地文件，而在公司的库存服务里。宿主应用连接一个MCP服务端，服务端暴露 read_inventory，再向库存HTTP API查询。模型看到工具说明后选择这个能力，调用结果最终回到对话。这里至少有四个角色：模型、宿主中的客户端、MCP服务端、实际业务系统。

“连接成功”只证明其中某条通信路径建立了。它不保证服务端已经提供正确工具，不保证凭据能访问目标仓库，不保证模型会选对参数，也不保证库存系统此时在线。若把这一切压成一个绿色连接图标，失败时就不知道该修哪一层。

本课使用只读查询，不涉及给系统新增权限或实际发送业务请求。重点是沿着一次调用定位职责。MCP是模型上下文协议，它为AI应用发现和调用能力提供共同接口；模型通常不是直接握着网络连接去发送协议消息，而是由宿主执行这些工作。

先发现能力：宿主通过协议取得工具名称、说明与参数Schema，把允许暴露的部分提供给模型。再选择动作：模型根据任务请求查红笔。宿主校验请求并发出工具调用。服务端把它转换成业务API需要的路径和参数，使用属于该业务边界的授权执行查询。最后结果沿原路回填，并与原调用正确配对。

假设MCP服务允许工具调用，但上游库存API凭据已过期。前半段可以完全正常，最后仍会返回授权错误。此时重新写提示词没有直接作用，应该检查上游凭据与权限。相反，如果业务API正常、工具也已发现，但模型把商品写成蓝笔，那是任务解释或参数选择的问题，不能归罪于网络。

观察过程 · 改变条件

先预测结果，再逐步展开；最后只改变一个条件，找出最早发生分歧的位置。

教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。

这一轮的输入

宿主已发现read_inventory，服务端有目标仓库只读权限。

发现

工具清单包含名称、用途和item参数。

1 / 3

先预测，再核对结果与原因

模型收到库存事实。

协议连接、工具暴露、业务授权和数据读取都在这次路径上成立。

如果工具列表里没有查询库存，模型不可能仅因为“MCP已连接”就自动获得这项能力。服务端还需要真正实现或转接工具。即使工具存在，它的描述也要说清适用仓库、返回单位和错误状态，否则选择工具时仍可能产生歧义。

再改一个条件：服务端列出 delete_inventory，而当前任务只需要读取。发现能力不等于授权使用所有能力。宿主应根据任务和权限范围决定哪些工具可见、哪些调用需要额外检查；业务执行端仍要拒绝越权操作。把敏感凭据直接写进模型可见的工具说明，也不是协议要求，反而扩大了泄露面。

协议统一了接口的一部分，却没有统一所有业务语义。“库存”在不同系统可能指现货、可售量、扣除预占后的数量，数据更新频率也可能不同。接通两个库存服务后，不能只凭同名字段把结果相加。需要核对仓库、时间和数量口径，解释合并的前提。

最小验收应沿同一任务走通三条路线：正常查询能返回正确商品和仓库；无权限时明确失败且不泄露数据；缺工具或参数错误时能说明哪一步未满足。只测连接和列工具，尚未验证端到端任务。

能列出工具却查不到库存，先看什么？

先看调用是否真正到达服务端以及上游返回什么。列工具成功只验证发现路径，业务认证、商品参数、目标仓库和库存服务可用性仍可能失败。

REST API必须包成MCP才能给Agent用吗？

不必须。宿主可以直接实现HTTP工具或通过其他适配器调用。MCP的价值是标准化发现与调用能力的接口，不是替代所有已有API。

MCP工具返回库存0和返回403错误有何差别？

前者在口径可信时是一个数量事实；后者说明没有获得授权数据。把403当作0会让模型把未知错误地解释为缺货。

连接能力之后，还要决定调用顺序。下一课用一张依赖关系图回答：什么时候可以并行，什么时候必须等前一步结果。