本章导读上一章我们介绍了 Tool Calling工具调用。它让大语言模型第一次拥有了与现实世界交互的能力。例如查询天气搜索互联网执行 Python查询数据库控制浏览器。这些能力让 AI 从一个只会聊天的模型逐渐变成一个能够完成任务的 Agent。但是当社区中越来越多工具出现之后一个新的问题开始暴露出来。如果每个 AI 平台都要重新开发一套工具接口会发生什么这正是 MCPModel Context Protocol诞生的原因。11.1 Tool Calling 已经很好了为什么还需要 MCP我们还是以一个例子作为开始。假设你开发了一个天气查询工具。(其实也是大多数兄弟tool calling的开始…)它提供一个简单的接口查询天气城市现在你希望它能够被不同的大模型使用。例如ChatGPTClaudeGeminiMinMaxQwen理论上它们都可以调用这个天气接口。但是现实却不是这样。每个平台都有自己的工具调用格式。例如以下仅为示意,不代表最新的交互协议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 DesktopOpenClawCursorClaude CodeCodex这些 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其中提供了一个查询天气的 ToolQueryWeather(city)用户向 AI 提出问题武汉今天的天气怎么样整个系统会经历下面几个步骤。┌──────────────────────────────────────────┐│ 用户输入 ││ “武汉今天的天气怎么样” │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ LLM 分析用户意图 ││ 判断需要调用 QueryWeather Tool │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ MCP Client ││ 向 MCP Server 发送 tools/call 请求 │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ MCP Server ││ 执行 QueryWeather(“武汉”) │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ 返回结果 ││ 晴天30℃东南风三级 │└──────────────────┬───────────────────────┘│▼┌──────────────────────────────────────────┐│ LLM 根据工具结果组织自然语言 │└──────────────────┬───────────────────────┘│▼回复最终答案整个过程中大模型始终没有直接执行任何代码。它只完成了两件事情判断是否需要调用工具根据工具返回的数据生成最终回复。真正执行查询天气的是 MCP Server。因此可以说MCP 负责连接工具LLM 负责理解语言两者各司其职。