跳到主要内容

MCP vs Tool Calling

学到 Tool Use / Function Calling 和 MCP 之后，一个很容易混淆的问题就是：

MCP 和 Tool Calling 到底是什么关系，它们在解决同一个问题吗？

结论并不复杂：

它们有关，但不在同一层。

  • Tool Calling 主要回答：模型怎么调用能力
  • MCP 主要回答：能力怎么被标准化提供给模型系统

这篇文档的目标，就是把这两个概念一次分清。

1. Tool Calling 在解决什么问题​

Tool Calling 更接近模型运行时的问题。

它主要关心：

  • 当前这轮是否需要调用工具
  • 应该调用哪个工具
  • 参数应该长什么样
  • 工具结果怎样回到模型上下文里

典型流程是：

  1. 用户提出请求
  2. 模型判断需要工具
  3. 模型生成结构化参数
  4. 系统执行工具
  5. 结果回注给模型
  6. 模型给出下一步或最终答案

这个过程通常是：

一次模型驱动的工具决策循环

2. MCP 在解决什么问题​

MCP 更接近系统接入层的问题。

它主要关心：

  • 外部能力怎么被发现
  • 外部能力怎么被暴露
  • resources / prompts / tools 怎么统一纳入协议
  • 不同客户端怎么复用同一套能力

典型问题包括：

  • 一个 Figma 能力怎样被 IDE、聊天客户端和 Agent 平台共同使用
  • 一个知识服务怎样既能提供资源，又能提供工具
  • 工具与资源的权限、连接与协商怎样统一管理

MCP 更接近：

一套标准化接入协议

3. 一个最简单的类比​

可以用下面这个类比：

  • Tool Calling 像“模型会不会按下按钮”
  • MCP 像“按钮面板和电路接口是不是统一标准”

前者关注调用行为，后者关注接入规范。

4. 为什么它们经常被混在一起​

因为在真实系统里，这两层往往是连着出现的。

例如：

  • 模型通过 tool calling 决定要调用某个工具
  • 这个工具本身可能来自一个 MCP server

于是从外面看，像是在做“一次工具调用”；但从系统内部看，其实跨了两层：

  • 上层：模型决策与参数生成
  • 下层：能力发现、协议协商、实际接入

5. 两者最核心的区别​

5.1 关注点不同​

Tool Calling 关心：

  • 决策
  • 参数
  • 调用
  • 回注

MCP 关心：

  • 能力暴露
  • 协议连接
  • 资源 / 提示 / 工具的统一表示
  • 多客户端复用

5.2 抽象层不同​

Tool Calling 是模型行为层。

MCP 是系统能力接入层。

5.3 复用方式不同​

Tool Calling 经常写在单个应用里。

MCP 更适合把能力抽成共享接入点，让多个应用一起使用。

5.4 能力边界不同​

Tool Calling 主要面向可执行动作。

MCP 不只包含 tools，还包含：

  • resources
  • prompts

它讨论的不只是“执行”，也包括“上下文供给”和“提示模板供给”。

6. 什么场景只需要 Tool Calling​

下面这些场景，通常只做 tool calling 就够了：

  • 一个最小 demo
  • 一个单应用里的内部函数调用
  • 少量固定工具
  • 本地代码里直接注册函数

例如：

  • 查天气
  • 调一个内部 API
  • 做一个单机版助手

这时重点是把调用行为跑顺，不一定需要额外引入协议层。

7. 什么场景更适合引入 MCP​

下面这些场景，MCP 的价值会明显上升：

7.1 工具不止来自一个应用内部​

如果能力来源已经包括：

  • 设计工具
  • 日历
  • 文件系统
  • 数据服务
  • 代码仓库

而且希望统一管理，就更适合 MCP。

7.2 同一组能力要被多个客户端复用​

例如同一个能力希望被：

  • 桌面助手
  • IDE
  • 聊天界面
  • 自动化 Agent 平台

共同使用。

7.3 资源、提示、工具都需要统一暴露​

如果除了动作以外，还希望把：

  • 文档资源
  • 提示模板
  • 可执行工具

放进统一协议里，那么 MCP 的优势会更明显。

7.4 权限、日志和接入边界需要收敛​

系统一旦进入团队协作或企业环境，往往就会关心：

  • 哪些工具开放给谁
  • 哪些资源可以读
  • 哪些能力需要审计

这时协议层和接入治理就不再是可选项。

8. MCP 会不会替代 Tool Calling​

不会。

因为 MCP 并不负责替模型做调用决策。

真正决定“现在该不该调某个能力”的，仍然是上层 Agent 或模型运行逻辑。

更准确的关系是：

  • Tool Calling 决定是否调用
  • MCP 决定能力怎样被提供

9. Tool Calling 会不会让 MCP 失去意义​

也不会。

因为即便本地工具调用已经很好用，系统一旦变成：

  • 多工具
  • 多客户端
  • 多数据源
  • 多团队

能力接入层很快就会成为独立问题。

这时 MCP 解决的是：

如何避免每个 Agent、每个框架、每个客户端都各接一遍。

10. 在这个模块里应该怎么安排学习顺序​

更稳的顺序是：

  1. Tool Use / Function Calling
  2. MCP 入门与实践
  3. 本文
  4. A2A 入门与使用场景

原因是：

  • 先把调用循环学明白
  • 再看接入协议层
  • 最后再理解 Agent 与 Agent 的互联协议

11. 和 A2A 的区别​

这一点也很值得顺手分清。

  • Tool Calling：模型调用工具
  • MCP：系统暴露工具 / 资源 / 提示
  • A2A：Agent 和 Agent 之间协作

所以它们分别对应：

  • 行为层
  • 接入层
  • 互联层

12. 小结​

如果只保留一个判断：

Tool Calling 解决“怎么调”，MCP 解决“从哪里接、怎么统一接”。

对于最小 demo，先学 tool calling 往往更直接。

对于跨应用、跨客户端、跨团队的 Agent 系统，MCP 会越来越重要。