AI-Wiki

文档概览

原文围绕三个核心问题展开：

大模型如何知道某个 MCP server 里有哪些工具、每个工具该怎么传参；
MCP与Function Call关系 到底是依赖、包含，还是彼此独立；
是否只有支持 function call 的模型才能使用 MCP。

文章采用的验证方法，不是只看产品界面，而是把大模型请求流量先经过 Cloudflare AI Gateway，再查看请求日志中的实际内容，尤其是系统提示词。实验客户端是 VS Code 中的 Cline，模型接入方式是 OpenAI compatible 的 base URL，后端模型流量经 OpenRouter 或兼容 OpenAI 的地址转发。

原文最终给出的判断是：MCP 的工具可用性信息主要通过系统提示词注入给模型；其调用过程由宿主负责串联；它与 function call 在效果上相似，但按文中实验与论述，二者是独立关系而非必然依赖关系。这个判断应理解为“基于文中实验与论述所得出的结论”，而不是对所有实现形态的无条件普遍定理。

关键事实

实验环境与配置方式

原文使用 Cloudflare AI Gateway 作为大模型 API 代理层，目的不是增强模型能力，而是为了抓取与 AI 交互的请求日志，便于观察 MCP 相关信息如何进入模型上下文。
配置路径是：先注册并进入 Cloudflare 的 AI Gateway，创建一个 gateway；然后在 API 平台里选择 OpenRouter；再到 VS Code 中安装 Cline。
在 Cline 中，模型提供方选择 OpenAI compatible，并把 Cloudflare 提供的链接填入 base URL。
API Key 则来自 OpenRouter，模型 ID 也在 Cline 中填写。原文举例可填写免费的 DeepSeek V3。
这意味着文中实验的关键观测点是“代理层日志里到底看到了什么”，而不是仅凭 Cline 前端显示来推断 MCP 的工作方式。

实验对象：time 类 MCP server

原文在 Cline 的 MCP 市场中搜索并安装一个与时间相关的 MCP server，以“time”为例。
文中明确指出，MCP server 的本质是运行在本机上的程序；这个实验里它是 Python 编写的本地程序。
因为它是本地程序，所以前提条件是电脑上先有 Python 运行环境。
安装时，AI 会自动协助完成 MCP server 的部署，文中描述的步骤包括：
创建文件夹；
使用 PIP 安装 Python 包；
创建并保存配置文件；
配置文件可修改以加入本地时区；
最后点击 approve 完成配置。
安装完成后，原文在该 server 中看到了两个工具：
“获取当前时间”；
“进行时间转换”。

第一组验证：模型如何知道 MCP 工具

原文新开一个对话，向 AI 询问“现在的时间是什么”。
Cline 界面显示模型可能要调用一个与当前时间相关的 MCP 工具。
随后作者到 Cloudflare AI Gateway 查看日志，并特别查看系统提示词内容。
日志中出现了关于 MCP 协议的说明，大意是：MCP server 的模型上下文协议允许系统与本地运行的 MCP server 通信，从而扩展额外工具与资源能力；并可通过特定方式执行 MCP 协议或访问 MCP 资源。
更关键的是，系统提示词里不只是抽象介绍了 MCP，还明确列出了当前可使用的工具名称，以及这些工具的参数格式。
原文举例指出，提示词里直接写出了类似“get current time”与“convert time”的工具及其传参格式。
文章据此得出的核心结论是：模型并不是凭空“知道”本地 MCP server 里有哪些工具，而是宿主把 MCP 协议说明、工具名、参数结构等信息注入到了系统提示词里，模型读到后才具备调用这些工具的能力。
进一步说，文中因此主张 MCP工具提示词注入机制 是其通用性的关键：只要模型能够理解提示词，它就有机会使用 MCP，而不必预设某种专有工具调用能力。

原文归纳的 MCP 调用流程

原文把 MCP 的调用过程整理为四步：

Cline 把用户提问以及 MCP 的详细使用方法一起发给大模型，其中 MCP 工具说明被附加在系统提示词中。
大模型基于这些说明，决定应该使用哪个 MCP 工具，以及参数应如何填写。
Cline 按照模型给出的工具选择与参数，去调用本地运行的 MCP server。文中强调，这个 server 本质上是本地 Node.js 或 Python 程序。
Cline 拿到 MCP server 返回的结果后，再连同之前上下文一起交给大模型，由模型整理生成最终回复。

原文用“查询当前时间”作为示例，最终返回的是当前时间结果，并且时区是上海。这说明最终用户看到的自然语言答复并不是 MCP server 直接输出给用户的，而是先由宿主执行工具，再由模型综合工具结果生成最终表述。

第二组验证：MCP 是否依赖 function call

为验证 MCP 与 function call 的关系，原文选用了 DeepSeek Re 作为测试对象。
文中明确声称该模型“不支持 function call”或“不支持 function code”，并提到在 GitHub 上能看到开发者希望 DeepSeek Re 支持相关能力的诉求。
随后作者把 DeepSeek 的 API Key 等信息填入 Cline，测试 DeepSeek Re 是否仍能使用 MCP。
原文报告的结果是：DeepSeek Re 在推理过程中依然调用了 MCP 工具，并成功给出了正确答案。
基于这个实验，文章提出：模型只要能理解系统提示词中的 MCP 工具说明，就能够通过宿主完成 MCP 调用；因此，按文中实验现象看，MCP 不依赖 function call。

重要细节

为什么 Cloudflare AI Gateway 是关键观测点

原文的论证之所以成立，关键不只是“调用成功”，而是作者看到了请求日志中的系统提示词。换言之，第一组实验并非停留在界面猜测，而是直接把“模型获得工具信息的来源”定位到提示词注入。这个细节很重要，因为它把“模型知道工具”从一种神秘能力，降解为一种宿主提供上下文的工程机制。

MCP server 的本地性边界

原文反复强调 MCP server 是本地程序，实验里是 Python 程序，另一个位置又概括为也可能是本地 Node.js 程序。这意味着在文中语境下，真正执行工具逻辑的不是远端大模型，而是宿主机器上的可执行程序。模型负责“选择”工具和参数，宿主负责“执行”调用。

配置文件与时区设置不是装饰细节

安装 time 类 MCP server 时，原文特别提到可以修改配置文件增加本地时区，随后又在示例结果里强调最终得到的是“上海时区”的时间。这说明该实验并不只是演示工具被调用，而是展示工具输出会受本地配置影响，模型最后给出的答案也因此带有具体时区上下文。

原文对 MCP 通用性的判断边界

文章用较强措辞表示，MCP 几乎可以兼容市面上几乎所有大模型，因为只要模型能看懂提示词就能使用 MCP；又认为 MCP 最大的优点，是把各家原本不统一的工具调用方式整合成统一标准。

这里在整理时需要保留边界：

这是原文基于所展示实验和论述给出的判断；
文中展示的是在 Cline、Cloudflare AI Gateway、time 类 MCP server、OpenRouter/DeepSeek 等组合下观察到的现象；
因此适合写成“原文主张”或“按文中实验支持”，而不应不加限定地扩展为对所有模型、所有宿主、所有实现方案都已被充分证明的结论。

结论整理

基于原文内容，可以将其核心观点压缩为以下几条：

第一，模型对 MCP 工具的认知来源于宿主注入的系统提示词，而不是模型天然知道本地工具清单。
第二，MCP 的典型链路是宿主把问题与工具说明发给模型，模型做工具选择，宿主执行本地工具，再把结果返回给模型生成最终答复，这正是 MCP工具调用链路 的核心。
第三，按文中第二组实验，MCP 的使用不以 function call 为必要前提；即便是原文声称不支持 function call 的 DeepSeek Re，也能在该架构中完成 MCP 调用。
第四，原文据此把 MCP与Function Call关系 概括为“能力相似，但相互独立”；同时强调 MCP 的价值在于把原先不统一的工具调用方式标准化。

AI领域原始文档：MCP协议底层原理、Function Call关系与实验验证摘要