W
AI-Wiki
CONCEPT

MCP与Function Call关系

定义

MCP与Function Call关系，在本文语境中指：二者都能让大模型驱动外部工具，但并非谁必须依赖谁才能成立。原文关注的不是抽象协议比较，而是一个很具体的问题：是否只有支持 function call 的模型才能使用 MCP。

文中给出的回答是否定性的：按作者的实验，MCP 与 function call 功能相似但相互独立，没有依赖关系。作者认为，MCP 能否被模型使用，关键不在模型是否原生实现 function call，而在于模型是否能理解宿主注入的提示词，以及宿主是否能在模型输出后代为执行 MCP 调用。

在本文档中的语境

这一定义来自一篇围绕 MCP协议底层原理、工具提示词注入和实验验证展开的文章。文章先追问两个问题：

  • AI 大模型如何知道有哪些 MCP 工具可用，以及参数该怎么传。
  • MCP 与 function call 到底是什么关系，是否只有支持 function call 的模型才能使用 MCP。

为回答这些问题，原文结合 Cline 的实际调用过程，以及通过 Cloudflare AI Gateway 观察到的请求日志，试图说明：MCP 的“可用性”很大程度上来自系统提示词注入和宿主编排，而不必然要求模型内建某种特定的 function call 能力。

原文给出的关键机制

1. MCP 工具知识来自系统提示词注入

原文先用时间相关的 MCP 工具做演示。作者在 Cline 中安装了一个 time 相关的 MCP server，其中可见两个工具：

  • 获取当前时间
  • 进行时间转换

当用户新开对话询问“现在的时间是什么”时，AI 会显示可能要调用对应的 MCP 工具。作者随后在 Cloudflare AI Gateway 的日志中重点查看系统提示词，发现其中已经明确写入了 MCP 相关说明，包括：

  • MCP 允许系统与本地运行的 MCP server 通信；
  • 可以通过特定方式执行 MCP 协议或获取资源；
  • 可使用哪些工具；
  • 每个工具对应的传参格式。

原文据此解释：模型之所以“知道” MCP server 和可用工具，不是凭空知道，而是因为这些知识已经被附加在系统提示词里。文中明确举例提到系统提示词写出了类似 “get current time” 和 “convert time” 这样的工具，以及它们的参数格式。

2. MCP 调用并不等于模型自己直接执行程序

原文把调用过程拆成了一个宿主编排链路，核心步骤如下：

  1. Cline 把用户提问和 MCP 的详细使用方法，一并传给大模型，其中 MCP 说明被附加在系统提示词中。
  2. 大模型根据提示词，决定要使用哪个 MCP 工具，以及参数如何组织。
  3. Cline 按照模型给出的调用意图，去调用 MCP server。原文特别说明，MCP server 本质上是本地运行的 Node.js 或 Python 程序。
  4. Cline 拿到 MCP server 的返回结果，再连同已有上下文一起交给大模型，由模型整理并输出最终答案。

在时间示例中，最终返回的是当前时间，并给出了上海时区的结果。

这套描述强调了一点：真正执行 MCP 工具的是宿主侧和 MCP server，不是模型本体“直接拥有了”某个硬编码的工具执行能力。模型承担的角色更像是：依据提示词理解有哪些工具可选，并输出调用决策。

与 Function Call 的关系：原文的实验论据

原文提出的问题

原文明确提出要探究：是否只有支持 function call 的模型才能使用 MCP。

实验对象与设置

为验证这一点，作者选用了文中称为“不支持 function call”的 DeepSeek Re 作为例子。原文还提到，在 GitHub 上可以看到开发者希望 DeepSeek Re 支持相关能力的诉求。

实验方式是：在 DeepSeek 的 API 平台创建 API Key，并把相关信息填写到 Cline 中，然后测试 DeepSeek Re 是否能够使用 MCP。

实验结果

原文给出的结果是：DeepSeek Re 在 Cline 中仍然调用了 MCP 工具，并成功给出正确答案。

也就是说，在作者的实验环境里，一个被文中界定为“不支持 function call”的模型，仍然完成了 MCP 工具调用链路。这个结果正是原文论证“MCP 不依赖 function call”的直接依据。

原文结论

基于上述实验和调用链说明，原文得出的结论可以概括为三点：

  • MCP 与 function call 在效果上相似，都会让模型驱动外部工具。
  • 二者相互独立，没有依赖关系。
  • 模型能否使用 MCP，关键在于能否理解提示词中注入的 MCP 相关知识，而不是是否原生支持 function call。

原文的核心论证句式是：由于 MCP 相关知识附加在系统提示词里，模型只要能读懂提示词就能使用 MCP，与是否具备 function call 功能无关。

协议层意义

除“是否依赖 function call”外，原文还给 MCP 一个更偏协议层的定位：它最大的优点，是把此前各家大模型各不统一的工具调用或代码调用标准，整合为一个统一的标准协议。

按这篇文章的说法，MCP 的价值不只是“又一种工具调用方法”，而是把原本分散、各家格式不一的接入方式统一起来，让不同模型更容易通过同一套协议接入外部能力。

这也与前文的提示词注入逻辑形成呼应：如果宿主可以把统一的 MCP 工具描述传给模型，而模型只需理解这些描述，那么从文章视角看，MCP 就具备了跨模型的兼容潜力。

细节与边界

1. 原文论证依赖单篇实验，不宜无限外推

虽然原文使用了 DeepSeek Re 的实验来支持“与 function call 无关”的判断，但这里的证据基础仍然是单篇文章中的个案实验。更稳妥的理解应是：

  • 这篇文章证明了至少存在一种情形：即使模型被认为不支持 function call，也仍可在 Cline 的宿主编排下使用 MCP。
  • 这篇文章支持“MCP 不必然依赖 function call”这一判断。
  • 但不应把它直接扩张成对所有模型、所有客户端、所有 MCP server、所有实现方式都无例外成立的绝对技术定律。

2. “能理解提示词”是原文中的前提

原文反复强调“只要大模型能懂提示词就能使用 MCP”。因此，这个论证自身包含一个前提：模型至少要具备足够的指令理解能力，能从系统提示词中识别出：

  • 有哪些工具可用；
  • 每个工具适用于什么场景；
  • 参数该如何构造；
  • 何时需要发起调用。

如果模型连这些提示词都无法稳定理解，那么文中的推理链条也就不成立。

3. 实际执行依赖宿主和本地程序

原文还明确指出 MCP server 本质上是本地运行的 Node.js 或 Python 程序。这意味着，MCP 的可用性不仅取决于模型理解提示词，也取决于宿主侧是否完成了：

  • MCP server 安装；
  • 运行环境准备；
  • 调用转发；
  • 结果回传。

因此，原文所说的“模型可以使用 MCP”，更准确地说是“模型在宿主系统中可以通过 MCP 被编排去使用工具”。

与相关概念的区别

与 Function Call 的区别

Function Call 通常强调模型按某种预定义结构输出工具调用意图；而在本文语境中，MCP 更强调一整套统一协议和宿主执行链路。原文认为两者在“让模型调用工具”这一点上功能相似，但实现依赖关系并不相同。

与纯模型能力的区别

本文并不把 MCP 解释成模型内部新增了一种原生能力。相反，原文更倾向于把它解释为：