夜雨聆风上一篇我们讲了 Function Calling：让大模型学会了"看清单点兵"——知道该用哪个工具、传什么参数。（AI 是怎么“调用工具”的？用“脑和手”一个类比讲明白）但有个问题一直没回答：那份"工具清单"从哪来？谁负责把工具接进来？
一、一句话定义
MCP（Model Context Protocol，模型上下文协议），就是给 AI 应用集成外部工具定的一套标准协议——让"工具"和"应用"之间，像 USB-C 一样即插即用。
二、用 USB-C 理解 MCP
还记得以前出门带一堆线吗？手机用 Micro-USB，相机用 Mini-USB，耳机用 3.5mm，笔记本用专用电源口。每种设备一种接口，换设备就得换线。
USB-C 出来后，一根线走天下——手机、平板、耳机、显示器，同一个口都能接。不是设备变了，是接口标准统一了。
MCP 之于 AI 应用，就是 USB-C 之于电子设备。以前每个 AI 应用接每个工具都得单独"焊线"（写集成代码）；有了 MCP，工具提供者做一个 MCP Server，应用接一个 MCP Client，两边一插就能用。
三、MCP 之前：一个 N×M 的噩梦
要理解 MCP 解决了什么，得先看没有它的时候有多乱。从两个角度来说。
从 AI 应用开发者的角度：你想让应用支持三个工具——查天气、发邮件、查数据库。每个工具背后是完全不同的技术：天气是 REST API，邮件是另一个 API，数据库是 SQL 连接。你得为每个工具单独写代码：读文档、构造请求、处理认证、解析返回、处理异常、写重试逻辑。
3 个工具，3 套代码。10 个工具？10 套。每加一个工具，就得从头开发一遍。
从工具描述的角度：不同的大模型，对工具描述的格式要求不一样。同一个"查天气"工具：
给OpenAI的模型用，得写成 tools[].function 格式，参数用 JSON Schema 给Anthropic的Claude用，得写成 tools[].input_schema 格式 给Google Gemini用，得写成 functionDeclarations，类型名还得大写（STRING、OBJECT）
换一个模型，工具描述就得重写一遍。
把两边乘起来：M 个 AI 应用 × N 个工具 = M×N 套集成代码。这就是著名的"N×M 问题"。每加一个工具，所有应用都得重新集成；每多一个 AI 平台，所有工具都得重新适配。
更麻烦的是，这些工具背后的形态五花八门：有的是 REST API（比如天气服务、GitHub），有的压根没有 API——本地文件系统、数据库、命令行工具。也就是说，连"让 AI 应用自动读现成的 API 文档"这条捷径都不存在，每个工具都得靠人来一个个接。
四、MCP 怎么解决的？
MCP 的世界里有两个新角色——MCP Server 和 MCP Client，加上 AI 应用本身，三方配合，把"工具提供"和"工具使用"彻底拆开：
① MCP Server（工具服务端）
工具提供者写一个 MCP Server 程序，把工具封装进去。Server 里包含两样东西：
工具描述：工具叫什么名字、需要什么输入参数、用来干什么——用 MCP 统一的格式写好 工具实现：实际执行工具的代码——构造请求、调用底层接口、处理返回结果、错误处理，全在里面
关键点：MCP Server 定义一次，所有兼容 MCP 的应用都能用。 Server 不需要关心下游用的是哪个模型。
② MCP Client（客户端）
AI 应用内部的一个组件，负责和 MCP Server 通信：
连接 Server 后，自动发现有哪些工具可用 收到调用指令后，转发给对应的 Server，拿回结果
③ AI 应用本身
比如 WorkBuddy、Claude Desktop、Cursor。它管理多个 MCP Client（每个 Client 对接一个 Server），还负责一个关键的翻译工作：
把 MCP Server 统一格式的工具描述，转换成自己所用的大模型需要的格式。
也就是说：MCP Server 用标准格式描述工具 → AI 应用读过来 → 转成 OpenAI 格式（或 Claude 格式、Gemini 格式）→ 喂给模型。Server 不需要知道调用方是哪个模型，模型也不需要知道工具背后是怎么实现的。
MCP Client 和 MCP Server 之间，用一套统一的"对话规则"通信，这套规则叫 JSON-RPC 2.0（一种很简单的约定：你发一段 JSON——你有哪些方法，参数是什么；我回一段 JSON——结果是什么）。至于消息走什么通道，有两种：
本地通道（stdio，标准输入输出）：MCP Server 是跑在你电脑上的一个程序，AI 应用直接启动它、和它通信——适合文件系统、数据库这类本地工具 网络通道（HTTP）：MCP Server 跑在远端服务器上，通过网络通信——适合 GitHub、腾讯会议这类云服务（MCP 规范里叫 Streamable HTTP，比普通 HTTP 多了"流式返回"能力：服务器可以边执行边把消息推回来，不用等全部算完）
这样，N×M 噩梦变成了 N+M：
工具提供者：写一个 MCP Server，所有应用都能用 AI 应用：接 MCP 协议，所有工具都能用
五、一个完整例子：用 WorkBuddy 订腾讯会议
光讲架构太抽象，我们把流程走一遍。假设你对 WorkBuddy 说："帮我订一个明天下午 3 点的腾讯会议，主题是项目周会。"
在背后，这一切是这样发生的：
1. 你输入问题，WorkBuddy（AI 应用）收到。
2. WorkBuddy 早已通过内部的 MCP Client，连上了腾讯会议的 MCP Server。 连接的时候，MCP Client 会向 Server 要一份工具清单，Server 回答："我有 create_meeting 这个工具，需要主题、时间、参会人这些参数。" WorkBuddy 把这份工具描述转换成大模型能理解的格式，和你的问题一起发给大模型。
3. 大模型判断：这个问题需要用 create_meeting 工具，从你的话里抽出参数（主题="项目周会"，时间="明天下午 3 点"），输出调用请求。
4. WorkBuddy 把调用请求交给 MCP Client，由它转发给腾讯会议的 MCP Server。
5. MCP Server 收到调用请求后，再去调用真正的腾讯会议服务 API：构造 API 请求、处理认证（比如用上配置文件里的 Token）、访问腾讯会议的云端接口。
6. 腾讯会议服务返回结果（会议号、入会链接）给 MCP Server。
7. MCP Server 把结果原路返回——先交给 MCP Client，再交给 WorkBuddy。
8. WorkBuddy 把结果拼回提示词，再发给大模型。
9. 大模型生成自然语言回复："已为您创建会议，会议号是 xxx，入会链接是 xxx。"
10. WorkBuddy 把答案显示给你。
注意看：大模型负责的是"决策"（该调什么工具、传什么参数），MCP 负责的是"执行"（怎么调、怎么处理结果）。AI 应用居中调度，把两边连起来。
六、具体怎么用？WorkBuddy 连接器实操
在 WorkBuddy 中，MCP 连接器已经内置了一批常用工具，你不需要自己写 MCP Server。
连接器的信息来自一份本地配置文件（mcp.json），大概长这样：
{"mcpServers": {"github": {"command": "npx","args": ["-y", "@modelcontextprotocol/server-github"],"env": { "GITHUB_TOKEN": "ghp_xxx" }},"filesystem": {"command": "npx","args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Desktop"]}}}
配置里写明了三件事：Server 程序在哪（command + args）、怎么启动、以及需要的认证信息（env 里的 Token、密钥）。认证信息存在本地配置文件里，不上传到云端——哪些工具用哪些凭据，用户自己掌控。
打开 WorkBuddy，左侧进入「专家·技能·连接器」，顶部切到「连接器」标签，再点右上角「自定义连接器」，就能看到 MCP 服务管理界面。这里会列出已安装的 MCP Server，以及每个 Server 提供的工具。
在 MCP 服务管理界面里，你可以直接搜索、启用或禁用某个 MCP Server。下图中的 wechat-official-account 就是微信公众号连接器，展开后能看到它提供的 15 个工具，比如认证、草稿、发布、素材上传等。
每个 Server 的配置都来自本地的 mcp.json 文件。以微信公众号连接器为例，配置里写明了启动命令、Server 脚本路径，以及公众号的认证信息（AppID、AppSecret）。这些信息只存在本地，不上传云端。
{"mcpServers": {"wechat-official-account": {"command": "/Users/***/.workbuddy/binaries/node/versions/22.22.2/bin/node","args": ["/Users/***/.workbuddy/binaries/node/versions/22.22.2/lib/node_modules/wechat-official-account-mcp/dist/src/cli.js","mcp","-a","wx********","-s","91*********"],"disabled": false}}}
配置好之后，在对话里直接使用即可。比如本文的写作过程中，我就用 WorkBuddy 的微信公众号连接器，把排版好的文章推送到公众号草稿箱——不需要写一行集成代码，认证、API 调用、结果处理全由连接器包办。
七、MCP 和 Function Calling 的关系
很多人把 MCP 和 Function Calling 搞混。其实它们解决的是完全不同层面的问题：
两者配合工作：MCP 负责把工具集成进来、提供工具清单 → AI 应用把清单转成模型格式 → 模型用 Function Calling 决定调哪个 → AI 应用通过 MCP Client 执行 → 结果返回给模型。
MCP 不替代 Function Calling，而是让 Function Calling 有了"源源不断的工具来源"。
八、MCP 解决了什么？
总结一下，MCP 带来的核心价值是工具集成这件事的标准化和可插拔：
1. 避免重复集成：每个 AI 应用不用为每个工具单独写集成代码——接一次 MCP 协议，所有 MCP Server 都能用。
2. 避免重复适配：工具提供者不用为不同 AI 应用分别提供工具描述——做一个 MCP Server，所有应用都能用。
3. 解耦维护：工具的描述或实现改了，MCP Server 更新即可，AI 应用不需要改代码、重新打包。
4. 灵活配置：用哪些工具、不用哪些，都可以在配置文件里自由搭配。
5. 安全认证：用户的身份信息（密码、Token）配置在本地配置文件里，不上传云端，用户自己掌控。
6. 工具多样：不限于 REST API，文件系统、数据库、命令行工具都能封装成 MCP Server。
九、一句话总结
MCP 是 AI 世界的 USB-C 接口——工具提供者做一个 Server，应用接一个 Client，即插即用。
上一篇 Function Calling 让模型学会了"写申请单"——决定该调什么工具、传什么参数。这一篇的 MCP，则解决了"工具从哪来、怎么接"的问题。Function Calling 是模型侧的决策能力，MCP 是应用侧的集成标准——一个管"想"，一个管"做"。
