用 MCP 给 AI Agent 接工具：把「工具」变成即插即用的标准件
AI先给结论：MCP 干的事很简单——把「你的工具」包装成一个标准服务，任何支持 MCP 的客户端（Agent、IDE、桌面应用）都能即插即用，不用每接一个 Agent 就重写一遍对接代码。如果你只有一两个 Agent、工具也少，直接 function calling 就够了；一旦工具要被多个 Agent / 多个客户端反复用，MCP 的价值就出来了。
一、为什么需要 MCP：痛点在前
在没有标准协议之前，给 Agent 加一个「查订单」工具，流程是这样的：
- 在 Agent A 里写一套「查订单」的适配（定义参数、写执行逻辑、处理返回）；
- 换到 Agent B，再写一套一模一样的适配；
- 哪天接口字段变了，A 和 B 都得改。
工具越多、Agent 越多，重复代码和版本分裂就越严重。MCP 的思路是：工具只写一遍，做成标准服务，谁要用谁连。这跟「数据库驱动 / USB 接口」是同一个哲学——规定好插槽形状，设备插上就能用。
二、MCP 的三个角色
| 角色 | 是什么 | 举例 |
|---|---|---|
| Host（宿主） | 用户直接用的应用，内部会拉起 Client 去连 Server | 支持 MCP 的桌面客户端、IDE 插件、你自己的 Agent 程序 |
| Client（客户端） | Host 内部负责和某个 Server 通信的连接器 | Host 里「连 demo-tools 这个服务」的那段逻辑 |
| Server（服务端） | 真正提供工具 / 数据的进程，被 Host 拉起 | 你写的「查订单」「读知识库」服务 |
一句话记：Host 想用工具 → 通过 Client → 连上 Server。Server 暴露的不是「一段代码」，而是「一组标准描述的工具」，Host 拿到描述后交给模型自己决定调不调。
三、一个最小 MCP Server（Python）
用社区封装好的 fastmcp，十几行就能把一个函数暴露成工具：
from fastmcp import FastMCP
mcp = FastMCP("demo-tools") # 给服务起个名字
@mcp.tool()
def query_order(order_id: str) -> str:
# 真实场景这里查你的业务库 / 调订单接口
return f"订单 {order_id}：已发货，预计明天送达"
if __name__ == "__main__":
mcp.run() # 默认 stdio 模式，由 Host 拉起并通信
就这么简单：一个函数 + 一个装饰器，它就能被任意 MCP 客户端发现并调用。工具的描述（名字、参数、用途）由函数签名和文档串自动生成，模型看到的就是一份标准工具清单。
四、在客户端里接上这个 Server
主流 MCP 客户端用一份配置声明「要连哪些 Server」，大致长这样（字段名称按你用的客户端而定）：
{
"mcpServers": {
"demo-tools": {
"command": "python",
"args": ["/path/to/server.py"]
}
}
}
配好后，客户端启动时会拉起这个 Server，把 query_order 塞进模型的工具清单。模型决定调它，客户端就通过标准协议执行并把结果回灌——你的 Agent 主循环一行都不用改，只多了一行配置。
五、MCP vs 直接 function calling，怎么选
| 维度 | 直接 function calling | MCP |
|---|---|---|
| 适用规模 | 单 Agent、少量工具 | 多 Agent / 多客户端共用工具 |
| 接入成本 | 最低，写函数即可 | 多一层 Server 封装 |
| 复用性 | 工具绑死在当前 Agent | 一次写好，处处连接 |
| 选它当 | 刚起步、工具还少时 | 工具要跨项目 / 跨产品复用时 |
本博客 D14 的「最小 Agent 骨架」用的是直接 function calling，那是因为示例里只有一个 Agent、一两个工具。当你开始想把「查订单」「读知识库」这类能力同时喂给 OpenClaw 工作流（见 D4）和别的产品时，再上 MCP 不迟。别为了用协议而用协议。
六、常见坑
| 坑 | 原因 | 规避 |
|---|---|---|
| 工具返回太大 | 一次查回整张表喂给模型 | Server 层先裁剪，只回关键字段 |
| 参数描述太省 | 模型选错工具 / 填错参 | 函数文档串写清「何时用、参数是啥」 |
| 本地路径写死 | 换机器就拉不起 Server | 路径走配置 / 环境变量，别硬编码 |
| 过早上 MCP | 工具就一两个却先搭框架 | 先 function calling 跑通，复用需求出现再升级 |
七、FAQ
Q：MCP 和 RAG 是什么关系？ RAG（检索增强，见 D7）完全可以做成 MCP 的一个 Server：「读知识库」暴露成工具，任何 Agent 连上就能查私有文档，二者是配合关系。
Q：不会 Python 能写 MCP Server 吗？ 能。官方和社区有 TypeScript / Go 等多语言 SDK，思路都一样：装饰一个函数、声明输入输出，剩下的通信交给协议。
Q：OpenClaw 这类工具现在就一定要接 MCP 吗？ 不一定。先看你的工具是不是真要被多个地方复用；如果只是给当前工作流（D4）加个能力，直接在它里面写插件往往更直接。
小结
MCP 的价值一句话：工具写一遍，处处能连。它把「函数调用」升级成「标准服务」，解决了多 Agent 重复适配的老问题。但别神话它——工具少、Agent 单一时，直接 function calling（D14）更轻。等到你出现「同一个能力要喂给好几个产品」的需求，再把它封装成 MCP Server，那时候它的省心事才真正兑现。协议细节、客户端配置字段与 SDK 版本以你所用平台当天官方文档为准。