MCP （二）原理深度解析：一次工具调用到底发生了什么？

在上一篇中，我已经从认知层面讲清楚了 MCP 是什么，以及它为什么存在。

作为开发者，我必须搞清楚一件事：

一次 MCP 工具调用，在底层到底发生了什么？

这一篇，我只做一件事：

把 MCP 的运行机制拆开，让它变成一个我可以完全理解、甚至自己实现的系统。

---

一、先明确一个核心问题

我先把问题说得极致一点：

当 LLM 说"我要调用一个工具"，到底是谁在做这件事？

很多人会误以为：

• 是模型在直接调用工具 ❌
• 或者是某个框架帮我做了魔法 ❌

但真实情况是：

模型只负责"决策"，真正执行的是 MCP 体系

---

二、从整体流程看一遍（全局视角）

先不要急着看细节，我先用"流程"的方式把整个调用跑一遍：

1. MCP Server 启动，并注册工具
2. MCP Client 连接 Server，获取工具列表
3. LLM 在对话中决定要调用某个工具
4. Client 发起调用请求
5. Server 执行 Tool
6. 返回结果给 Client
7. Client 把结果交回 LLM

👉 关键点：

• LLM 不直接接触工具
• 所有调用都经过 Client / Server

---

三、第一步：Tool 是怎么被"注册"的？

如果没有这一步，后面所有流程都不成立。

本质问题

MCP Server 是怎么告诉外界："我有什么能力"？

答案是：

通过 Tool Schema（工具定义）

---

Tool 的本质结构

一个 Tool，最核心就是三部分：

• 名称（name）
• 描述（description）
• 参数定义（schema）

可以抽象成这样：

{
  "name": "get_weather",
  "description": "查询某个城市的天气",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    },
    "required": ["city"]
  }
}

---

这一层的关键理解

Tool 本质就是一个"可被模型理解的函数声明"

注意是"声明"，不是实现。

真正的执行逻辑，在 Server 内部。

---

四、第二步：Client 如何"发现能力"？

注册完工具之后，下一个问题是：

Client 怎么知道有哪些工具可以用？

答案是：

能力发现（Discovery）机制

---

流程是这样的：

1. Client 连接 MCP Server
2. 请求工具列表
3. Server 返回所有 Tool Schema

---

返回的本质是什么？

不是代码，而是：

一组"工具说明书"

也就是说，Client 拿到的是：

• 工具名字
• 工具用途
• 参数结构

---

关键点

LLM 从头到尾看到的，只是"工具描述"，而不是代码

这也是为什么：

• 描述写得好 → 模型更容易选对工具
• 描述模糊 → 调用容易出错

---

五、第三步：LLM 是怎么"决定调用工具"的？

这是整个 MCP 里最容易被误解的一步。

我一开始也以为：

• 是程序在写 if/else 判断调用哪个工具 ❌

但实际上是：

LLM 自己"推理"出要调用哪个工具

---

举个例子

我输入一句话：

帮我查一下北京今天的天气

此时，LLM 会看到：

• 当前对话内容
• 所有 Tool 的描述

然后它会做一件事：

"哪个工具最符合这个需求？"

---

本质机制

这一过程本质上还是：

语言理解 + 匹配

而不是：

• 硬编码规则
• 或固定流程

---

关键理解

MCP 不负责"选工具"，它只提供"可选工具"

真正做选择的，还是 LLM。

---

六、第四步：一次调用是如何执行的？

当 LLM 决定调用工具之后，就进入真正的执行阶段。

---

调用流程拆解

1. LLM 生成调用意图

类似：

{
  "tool": "get_weather",
  "arguments": {
    "city": "北京"
  }
}

---

2. Client 接管

Client 做两件事：

• 解析调用意图
• 转换为 MCP 请求

---

3. 发送请求给 Server

请求本质是：

• 工具名称
• 参数

---

4. Server 执行 Tool

这一层才是：

真正执行代码的地方

比如：

• 调用第三方 API
• 查询数据库
• 读取文件

---

5. 返回结果

Server 返回：

{
  "result": "北京今天晴，25度"
}

---

6. 回到 LLM

Client 把结果重新喂给 LLM：

工具返回结果：北京今天晴，25度

---

7. LLM 生成最终回答

比如：

北京今天是晴天，气温大约25度，适合出行。

---

七、这一整套机制的本质

把上面所有流程压缩成一句话：

LLM 负责"想做什么"，MCP 负责"怎么做"

再拆细一点：

• LLM：决策层
• MCP：执行调度层
• Tool：能力层

---

八、一个更底层的理解（关键）

如果我站在系统设计角度看，这其实是一个经典分层：

层级	作用
LLM	决策（What）
MCP	调度（How）
Tool	执行（Do）

---

为什么这很重要？

因为这意味着：

我可以随时替换 Tool，而不影响 LLM

甚至：

我可以增加无数工具，而不需要改模型逻辑

---

九、容易忽略的两个关键点

1. Tool 描述质量决定上限

如果我写成：

获取信息

模型基本不会用。

但如果我写成：

根据城市名称查询实时天气，包括温度、天气状况

模型调用成功率会大幅提升。

---

2. MCP 本身"不做智能"

很多人会误解：

• MCP 很聪明 ❌

但实际上：

MCP 是"无脑"的，它只是管道

所有"智能"都来自 LLM。

---

十、总结

我把这一篇压缩成三句话：

1. Tool 是能力的声明，不是能力本身
2. LLM 决定"用不用"，MCP 负责"怎么用"
3. 一次调用，本质是"描述 → 决策 → 执行 → 回传"

👉 一句话总结：

MCP 本质是一个"工具调度协议"，而不是 AI 能力本身

---

下一篇

👉 从 0 到 1 写一个可运行的 MCP Demo（包含 Server + Client）

到这里如果我还只是"理解"，那是没用的；

只有我能跑起来，才真正掌握。

---