MCP工具调用链路
定义
MCP工具调用链路，是指一次 MCP 工具使用从“用户提问”到“宿主协调调用”再到“模型整理结果”的完整执行过程。
在本文语境里，它不是泛指任何工具调用框架，而是特指 Cline、大模型与本地运行的 MCP server 之间的协作顺序。原文强调，MCP 的关键不在于模型自己直接执行本地程序，也不在于模型必须具备 Function Call 能力，而在于宿主把工具说明注入提示词，再由宿主代为完成真实调用。
本文档中的语境
原文通过抓取请求日志，专门验证了模型到底是如何“知道”有哪些 MCP 工具可用、调用时应传什么参数、以及一次调用实际上由谁执行。
作者使用 Cloudflare AI Gateway 观察请求后发现，MCP 相关信息并不是神秘地存在于模型内部，而是被宿主放进了系统提示词。系统提示词中明确写出了：
- MCP 允许系统与本地运行的 MCP server 通信。
- 可以通过特定方式执行 MCP 协议中的工具调用或资源访问。
- 当前可用的具体工具名称。
- 每个工具的参数格式与使用方法。
因此，本文谈“调用链路”，核心是在解释：模型看到的是一份包含工具说明的提示词；真正跑起来的是用户电脑上的程序；最终回复仍然由模型负责生成。
四阶段执行流程
第一阶段：宿主把用户问题和 MCP 工具说明一起发给模型
第一步不是只把用户问题发给模型。原文明确指出，Cline 会把“用户提问”与“MCP 详细使用方法”一起传递给大模型，而且这些 MCP 信息是附加在系统提示词层的。
这一步包含的关键信息至少有两类：
- 用户当前的问题，例如“现在的时间是什么”。
- 可用 MCP 工具的详细说明，例如有哪些工具、工具名是什么、参数怎么传、返回什么。
在原文的时间示例里，系统提示词中写明了与时间相关的工具，至少包括：
- 获取当前时间的工具。
- 进行时间转换的工具。
并且不仅有工具名，还有各自的传参格式。
这解释了一个常见误解：模型并不是自己“发现”了本地程序，也不是偷偷扫描本机环境后知道有哪些能力，而是宿主在提示词中把这些能力明确告诉了模型。
第二阶段：模型决定是否调用、调用哪个工具、参数如何组织
拿到系统提示词后，第二步由大模型做决策。原文把这一阶段概括为：大模型决定使用哪个 MCP 工具及传递参数的方式。
这里要特别区分“决策”与“执行”：
- 模型负责理解用户意图。
- 模型负责从提示词给出的候选工具中选择合适工具。
- 模型负责组织参数。
- 模型不直接执行本地 node.js 或 Python 程序。
也就是说，模型在这一阶段更像是生成一份“调用意图”或“调用方案”。它会判断用户问的是当前时间，因而应选择获取当前时间的工具；如果问题涉及时区转换，则可能改选时间转换工具，并按提示词约定组织参数。
原文还借此说明了 MCP与Function Call关系：只要模型能读懂提示词、能根据提示词输出正确的调用决策，它就可以参与 MCP 链路，并不要求模型原生支持 function call。
第三阶段：宿主按照模型决定去调用本地 MCP server
第三步才发生真实的工具执行，而且执行者不是模型，而是宿主。原文明确写道：Cline 根据大模型决定的调用方式调用 MCP server。
原文对 MCP server 的本质描述得很具体：它是运行在本地电脑上的程序，可以是 node.js 程序，也可以是 Python 程序。
这意味着工具真正落地执行时，调用的是用户环境中的本地服务，而不是模型在云端“自己动手”运行代码。
在前文实验里，作者安装的是一个与时间有关的 server，文中示例是 Python 编写的。安装过程包括：
- 先准备 Python 运行环境。
- 由 AI 协助安装该 MCP server。
- 创建文件夹。
- 通过 PIP 安装 Python 包。
- 创建并保存配置文件。
- 可以修改配置文件以添加本地时区。
- 完成配置后批准启用。
配置完成后，可以看到该 server 暴露出两个工具：
- 获取当前时间。
- 进行时间转换。
这些细节进一步说明，MCP server 不是抽象概念，而是实际运行在本机的服务进程；宿主负责与它通信并拿回结果。
第四阶段：宿主把返回值再交给模型，由模型生成用户可读答案
宿主从 MCP server 拿到结果后，流程并没有结束。原文强调，Cline 会把 MCP server 的返回结果，连同之前的上下文，再次传递给大模型；然后由大模型整理并呈现最终结果给用户。
因此，用户最后看到的自然语言答案通常不是工具原始输出的直接照搬，而是模型基于以下材料重新组织出的回复：
- 原始用户问题。
- 先前系统提示词中的工具说明。
- 工具实际返回值。
- 当前会话上下文。
这一步解释了为什么工具链路的最终输出往往更自然、更贴合问法：真正面向用户的回答仍由模型生成。
时间查询案例
原文给出的演示问题是“现在的时间是什么”。按照文中的链路，这个案例可拆成以下顺序：
- 用户提出时间查询问题。
- Cline 把问题和时间相关 MCP 工具的详细说明一起放入系统提示词发给模型。
- 模型判断应调用“获取当前时间”这一类工具，并组织所需参数。
- Cline 调用本地运行的 MCP server。
- MCP server 返回当前时间数据。
- Cline 再把该返回值交回模型。
- 模型整理成最终自然语言答复。
原文特别指出，最终给出的结果是当前时间，且时区为上海的结果。
也就是说，用户看到的“上海时区当前时间”并不是模型脱离外部环境凭空推断出来的，而是建立在 MCP 工具返回值基础上的二次整理结果。
关键机制
工具能力通过系统提示词注入
本文最关键的机制，是 MCP 工具说明被放在系统提示词中，而不是依赖模型私有接口或神秘内建能力。
原文日志显示，系统提示词里会直接写出：
- MCP 的用途，即允许与本地运行的 server 通信。
- 可调用的工具名称。
- 每个工具的参数格式。
- 如何触发相应调用。
这也是 MCP工具提示词注入机制 的核心：模型先“读到规则”，再据此做决策。
宿主负责协议落地与真实执行
第二个关键机制，是宿主承担了协议执行层角色。
在本文中，这个宿主就是 Cline。它至少承担三项职责：
- 把 MCP 说明注入系统提示词。
- 接收模型产出的调用决策。
- 调用本地 MCP server 并回传结果。
因此，MCP 更像“宿主 + 提示词 + 本地服务”的协作协议，而不是“模型直接拥有工具能力”。
模型负责理解与整合，而不是直接运行本地程序
第三个关键机制，是模型在整条链路中承担“语义决策器”和“结果整理器”双重角色：
- 调用前，它负责理解问题并选择工具。
- 调用后，它负责把返回值转成用户可读答案。
但在原文表述里，模型并不直接执行本地程序，这一点是理解 MCP 调用链路时最容易混淆的边界。
细节与边界
1. 这不是模型直接联网或直接执行代码
从时间案例看，真正被执行的是本地 MCP server。模型本身只是根据提示词做出调用决策，并在最后整合返回值。