MCP：为什么 AI 世界需要统一的工具协议？

2026/7/19 4:16:41

本章导读
上一章，我们介绍了 Tool Calling（工具调用）。

它让大语言模型第一次拥有了与现实世界交互的能力。

例如：

查询天气；
搜索互联网；
执行 Python；
查询数据库；
控制浏览器。
这些能力让 AI 从一个"只会聊天"的模型，逐渐变成一个能够完成任务的 Agent。

但是，当社区中越来越多工具出现之后，一个新的问题开始暴露出来。

如果每个 AI 平台都要重新开发一套工具接口，会发生什么？

这正是 MCP（Model Context Protocol）诞生的原因。

11.1 Tool Calling 已经很好了，为什么还需要 MCP？
我们还是以一个例子作为开始。

假设你开发了一个天气查询工具。(其实也是大多数兄弟tool calling的开始…)

它提供一个简单的接口：

查询天气（城市）

现在，你希望它能够被不同的大模型使用。
例如：

ChatGPT
Claude
Gemini
MinMax
Qwen
理论上，它们都可以调用这个天气接口。

但是现实却不是这样。

每个平台都有自己的工具调用格式。

例如（以下仅为示意,不代表最新的交互协议）：

ChatGPT
↓

Function Calling
↓

你的天气工具

Claude
↓

Tool Use
↓

你的天气工具

Gemini
↓

Function Declaration
↓

你的天气工具
虽然最终调用的是同一个天气 API，但每个平台都有自己的接口规范、参数格式和通信方式。
于是，一个非常尴尬的问题出现了。

如果你想同时支持五个平台，就需要分别适配五套接口。

这就像我们前些年的手机充电器一样：

安卓一种接口；
苹果一种接口；
Micro USB 一种接口；
Type-C 又是一种接口。
明明都是充电，却没有统一标准。

11.2 Tool Calling 的局限在哪里？
上一章我们提到：

Tool Calling 的本质是：模型告诉程序：“我需要调用这个工具。”

例如：

{
“tool”: “weather”,
“city”: “北京”
}
程序收到之后会按下面的流程进行操作

调用天气 API
↓

获得天气数据
↓

再交给 LLM
整个流程没有任何问题。
但是问题在于 Tool Calling 更像是模型厂商提供的一种能力，而不是一种统一标准。

例如：

OpenAI：有自己的 Function Calling。

Anthropic：有自己的 Tool Use。

Google：有自己的 Function Declaration。

不同平台之间：

Tool 定义不同；
参数格式不同；
返回格式不同；
通信方式不同。
这意味着：

工具开发者需要不断重复开发适配层。

11.3 MCP 想解决什么问题？
MCP 并没有发明一种新的工具,它只是定义了一套协议。

它真正解决的是：如何让工具只开发一次，就能够被所有支持 MCP 的 AI 使用。

可以把 MCP 理解成：AI 与工具之间的一种通用语言。

注意，这里的"语言"并不是自然语言，而是一套约定好的通信协议。

只要：

Agent 能按照 MCP调用；
工具也能按照 MCP实现；
那么它们就可以互相通信，而不需要关心对方是谁。

11.4 MCP 是 AI 世界的 USB?
还是举个例子.

假设你买了一把无线鼠标。

以前不同品牌都有自己的接收器。

后来USB 成为了统一标准。

于是无论罗技、雷蛇、戴尔、都可以直接插在你的电脑上。

电脑并不需要知道,这是哪家公司生产的鼠标。

因为 USB 已经规定好了通信方式。

不过，这里有一点需要特别强调。

网上很多文章都会说：

MCP 是 AI 世界的 USB。

这个比喻虽然便于理解，但并不完全准确。

USB 是一种硬件接口标准，解决的是设备之间的物理连接问题。

而 MCP 是一种应用层通信协议，解决的是 AI 与工具之间如何交换能力、请求和结果的问题。

因此，更准确的类比应该是：MCP 其实更像 HTTP协议或者数据库连接协议，而不是 USB 接口。

11.5 MCP 架构长什么样？
我们来看一张简化后的架构图。

AI Agent │ ▼ MCP Client（客户端） │ MCP 通信协议 │ ▼ MCP Server（服务端） ┌────────┼────────┐ ▼ ▼ ▼ 浏览器 数据库 Git

这里第一次出现了两个新的角色, MCP Client和MCP Server.

最早,我们很容易混淆它们。

但是,其实它们的职责其实非常明确。

11.6 MCP Client 是什么？
Client其实就是：主动发起请求的一方。

它通常是LLM或者Agent,比如

Claude Desktop；

OpenClaw；

Cursor；

Claude Code；

Codex；

这些 AI 应用，都可以充当 MCP Client。

它们负责：

连接 MCP Server；
获取工具列表；
调用工具；
获取返回结果。
可以理解为Client 等于使用工具的人。

11.7 MCP Server 是什么？
Server 则相反。

它负责提供能力。

比如,一个 Git MCP Server。

它可以提供：

查看 Commit；
创建 Branch；
提交代码。
一个数据库 MCP Server。

它可以提供：

查询数据；
修改数据；
执行 SQL。
一个浏览器 MCP Server。

它可以提供：

打开网页；
点击按钮；
获取页面内容。
所以Server则是提供工具能力的一方。

一个 Server 可以提供多个 Tool，而一个 Client 也可以同时连接多个 Server。

11.8 MCP 的一次完整调用流程
简单了解了 MCP 的整体架构之后，我们再来看一次真实的调用过程。

很多人第一次接触 MCP 时，会有一种误解：

是不是 Claude 或 ChatGPT 直接调用了我的 C# 方法？

实际上并不是。

整个调用过程始终遵循"模型负责决策，程序负责执行"的原则。

下面以一个天气查询工具为例，看看一次完整的 MCP 调用过程。

假设我们开发了一个 MCP Server，其中提供了一个查询天气的 Tool：

QueryWeather(city)

用户向 AI 提出问题：

武汉今天的天气怎么样？

整个系统会经历下面几个步骤。

┌──────────────────────────────────────────┐
│ 用户输入 │
│ “武汉今天的天气怎么样？” │
└──────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ LLM 分析用户意图 │
│ 判断需要调用 QueryWeather Tool │
└──────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ MCP Client │
│ 向 MCP Server 发送 tools/call 请求 │
└──────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ MCP Server │
│ 执行 QueryWeather(“武汉”) │
└──────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ 返回结果 │
│ 晴天，30℃，东南风三级 │
└──────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ LLM 根据工具结果组织自然语言 │
└──────────────────┬───────────────────────┘
│
▼
回复最终答案