MCP工具提示词注入机制
定义
MCP工具提示词注入机制，是指宿主程序把已连接的 MCP server 能力整理成大模型可读的系统提示词内容，包括协议说明、可用工具列表、每个工具的描述、参数格式，以及真正的调用入口名称，然后与用户问题一起发送给模型。
关键主体分工是：让模型“知道有哪些 MCP 工具可用”的，不是 MCP server 自己直接教育模型，而是像 Cline 这样的宿主先收集并组织这些说明，再注入系统提示词。
因此，模型对 MCP 工具的认识，首先来自提示词上下文，而不是来自模型厂商在模型内部预置了每个工具的定义。
本文档中的语境
原文讨论的核心问题是：AI 大模型究竟如何知道某个 MCP server 里有哪些工具、这些工具叫什么、参数怎么传。为此，作者搭建了一个实验链路：通过 Cloudflare AI Gateway 代理模型请求，并抓取与 AI 交互的请求日志，再结合 Cline 中安装的 time 类 MCP server，观察系统提示词里到底出现了什么。
实验中，宿主侧先接入了一个与时间相关的 MCP server。该 server 安装完成后，界面中可见两个工具：一个用于获取当前时间，另一个用于进行时间转换。随后用户在新对话中询问“现在的时间是什么”，模型表现出它“知道”可以调用对应的 MCP 工具。原文接着通过网关日志证明，这种“知道”并不是神秘的内建能力，而是提示词中早已写明了相关规则与工具说明。
直接证据：日志中能看到什么
原文最重要的证据来自 Cloudflare AI Gateway 抓到的请求日志，尤其是系统提示词部分。文中指出，日志里可以直接看到与 MCP 相关的说明文字，大意包括：
- MCP server 模型上下文协议允许系统与本地运行的 MCP server 之间通信。
- 这种通信会为系统带来额外的工具与资源扩展能力。
- 可以使用
use_mcp_tool来执行 MCP 工具调用。 - 可以使用
access mcp resource来访问 MCP 资源。 - 系统提示词中还明确列出了可用工具，例如获取当前时间、时间转换，以及各自的传参格式。
这组证据说明，模型收到请求时，并不是面对一个完全未知的“外部工具箱”；相反，宿主已经把 MCP 协议说明、工具名、工具描述、参数要求和调用入口都写进了系统提示词。模型随后只是根据这些说明做选择和参数构造。
关键机制拆解
1. 宿主负责整理工具说明
在原文实验里，承担这个角色的是 Cline。它先知道当前接入了哪些 MCP server，以及这些 server 暴露了哪些工具和资源。然后它把这些信息整理为模型可读的说明文本，附加到系统提示词中。
这一步非常关键，因为它解释了“工具知识从哪里来”。知识来源不是模型本身，也不是 MCP server 直接修改模型，而是宿主在请求组装阶段完成了桥接。
2. 模型通过阅读提示词获知可调用能力
系统提示词中既有协议层面的解释，也有具体工具清单与参数格式。模型看到这些内容后，就能像阅读一份接口说明一样，判断当前问题是否适合调用某个 MCP 工具。
原文的时间查询示例中，用户问“现在的时间是什么”，模型之所以会倾向于调用获取当前时间的 MCP 工具，就是因为系统提示词已经提前告知了该工具的存在、用途和传参方式。
3. 实际执行入口由宿主暴露给模型
原文明确出现了两个调用入口名称：
use_mcp_tool：用于执行 MCP 工具。access mcp resource：用于访问 MCP 资源。
这意味着，模型并不是直接与本地 MCP server 建立底层连接，而是通过宿主在提示词中公布的“入口”表达自己的调用意图；随后由宿主把这种意图转换成真实的 MCP 调用。
4. 宿主再把结果回送给模型整理答案
原文后半部分把调用过程总结为四步：
- Cline 把用户提问以及 MCP 的详细使用方法，一并传给大模型，其中 MCP 说明附加在系统提示词里。
- 大模型决定要使用哪个 MCP 工具，以及参数该如何传递。
- Cline 按照模型决定的调用方式去调用 MCP server；原文强调，MCP server 本质上是运行在本地的 Node.js 或 Python 程序。
- Cline 拿到 MCP server 返回结果，再连同前文上下文一起交给大模型，由模型整理出最终回答。
在时间查询例子里，这一链路最终返回了当前时间，并给出了上海时区的结果。
为什么这会带来广泛兼容性
这种机制的重要含义是：MCP 的“可用性”很大程度上建立在提示词理解能力上。只要模型能够理解自然语言或结构化说明，并按照说明选择工具、构造参数、表达调用意图，它就有机会接入 MCP 工作流。
原文据此得出一个重要判断：MCP 的通用性很强，兼容面可以非常广，不必要求每个模型厂商都事先把每个 MCP 工具定义硬编码进模型。
换句话说，MCP 之所以能跨不同模型工作，不是因为所有模型都原生内置了相同的工具协议，而是因为宿主把协议和工具说明翻译成了模型普遍能读懂的提示词内容。
这也正面回答了文章开头的问题：AI 如何知晓 MCP server 及相关工具？答案并不是“模型天生知道”，也不是“每个工具都由模型提供方预装”，而是在具体运行时由宿主把相关知识注入了系统提示词。
与 Function Call 的关系：为什么不是强依赖
原文进一步用一个不支持 function call 的模型做实验，论证 MCP 与 function call 没有必然依赖关系。文中举的是 DeepSeek Re，并提到开发者社区对其支持相关能力有所诉求；但作者实际测试发现，即使该模型不支持 function call，只要把 MCP 相关知识写进系统提示词，它仍然能够在推理过程中调用 MCP 工具并给出正确答案。
这说明：
- MCP 与 function call 在“让模型驱动外部工具”这一目标上相似。
- 但二者是相互独立的，不是前者必须依赖后者。
- 从原文实验视角看，MCP 至少可以通过提示词注入这一路径成立。
因此，MCP工具提示词注入机制，也可以看作是 MCP与Function Call关系 这一主题中的关键解释：MCP 不必等同于厂商原生 function calling API，它可以先由宿主在提示词层完成一层协议适配。
细节与边界
1. 这是从提示词视角解释底层原理
原文的重点，是通过抓包日志说明“模型为什么知道工具存在”。所以这里讨论的是一种提示词层面的底层解释：宿主把说明写进系统提示词，模型据此学会调用。
这并不等于所有 MCP 实现、所有客户端、所有模型服务商在内部细节上都完全相同。不同宿主可能有不同的提示模板、调用格式、结果回填方式，甚至会叠加其他机制。
2. 应以文中实验场景为主理解
本文应主要基于原文实验场景理解：
- 宿主是 Cline。
- 观测手段是 Cloudflare AI Gateway 请求日志。
- 示例能力来自一个 time 类 MCP server。
- 被明确看到的入口名是
use_mcp_tool与access mcp resource。
因此，这一词条不是在宣称“所有 MCP 系统提示词一定逐字如此”，而是在总结原文实验中已被观察到、并足以解释机制成立的关键事实。