Day 31 / 共 68 天 · 阶段 5 工具与 MCP

MCP 协议入门

昨天(Day 30)你学会了把一个函数写成"安全的工具"给模型调。可真实项目里工具动辄几十上百个,而且今天接数据库、明天接 GitHub、后天换个 App 又得重写一遍——太累。今天认识 MCP(Model Context Protocol,模型上下文协议):一套让 Agent"即插即用"外挂工具和数据的统一标准。学完你就懂业界为什么都在聊 MCP;明天(Day 32)我们把多个工具串成一条会失败会重试的"工具链"。

📍 你在阶段 5（工具与 MCP D29-32）的位置
D29 函数调用原理→ D30 写安全工具→ D31 MCP 入门→ D32 多步工具链
💡 用一个类比兜住今天（今天全程沿用「USB 万能接口」的世界观） 以前每种设备一根专用线:打印机一根、鼠标一根、手机又一根,插头还都不一样,乱成一团。USB 出现后——所有设备统一一种插口,插上即用。MCP 就是 AI 世界的 USB:模型这台"电脑"想外接数据库、文件、GitHub……不用为每一个单独写一套对接,只要对方"长了一个 MCP 插口",插上就能用。MCP Server = 一个个 USB 设备(它对外提供工具);MCP Client = 电脑上的 USB 控制器(Agent 通过它统一管理所有插上来的设备);stdio / SSE = 两种"数据线的走线方式"(同一台机器里走,还是隔着网络走)。
L01

工具太多的烦恼:每接一个都要重写

🤔 痛点Day 30 你为模型写了一个"查天气"工具。可产品要你再接:公司数据库、内部文档、GitHub、Slack……每个都得研究它的接口、手写一遍参数格式和错误处理。换个 Agent 框架(明天开始学),这些还得再重写一次。工具越多越崩溃。
💡 本质问题不在"工具多",而在每一对"Agent × 工具"都要单独对接——3 个 Agent × 5 个工具 = 15 套胶水代码。就像 USB 之前,每台电脑配每种设备都要一根专用线。解法是定一个统一标准,让工具方按标准提供、Agent 方按标准接入,谁也不用管对面具体是谁。
没有统一标准 vs 有 MCP ❌ 每一对都手写胶水 A1 A2 DB Git Doc ✅ 都插进 MCP 总线 A1 A2 MCP DB Git Doc
图注:左边 2×3=6 根专用线,加一个 Agent 或工具就成倍增加;右边所有人只对接一根"MCP 总线"。
L02

MCP 是什么:AI 世界的 USB 标准

🤔 痛点你可能听过 MCP 但觉得高深。其实它不神秘——一句话就能说清。
💡 本质MCP = 一份"怎么把工具和数据接给大模型"的公开约定。它规定了双方对话的格式:工具方怎么"报菜单"(我有哪些工具、每个要什么参数)、Agent 方怎么"点菜"(我要调这个、参数是这些)、结果怎么"上菜"(返回长啥样)。就像 USB 规定了插口形状和通电规则,谁做设备都照着来,于是天下设备一线通。
👶 它和 Day 29 的 Function Calling 什么关系?Function Calling 解决的是"模型怎么表达'我想调某个工具'"(模型那一端);MCP 解决的是"工具/数据怎么标准化地摆出来给 Agent 用"(工具那一端)。可以理解成:Function Calling 是"顾客会点菜",MCP 是"所有餐厅用同一套菜单格式和上菜流程"。两者配合,顾客换到任何一家店都能无缝点单。
📝 举个例子:一句大白话版定义 "我写了个 MCP Server 接了公司数据库" = 我把数据库包装成一个符合 MCP 标准的插头,任何支持 MCP 的 Agent(Claude 桌面端、你自己的 Agent、各种 IDE 插件)不用改代码,插上就能查这个库。写一次,处处能用——这就是 MCP 最大的价值。
L03

client / server:谁是电脑,谁是设备

🤔 痛点一上来两个词就绕:MCP Client、MCP Server,到底谁调谁?
💡 本质照搬 USB 世界就懂:MCP Server = USB 设备(打印机、U 盘),它对外提供能力(工具、数据、提示模板),自己不主动;MCP Client = 电脑里的 USB 控制器,它由 Agent 使用,负责发现设备、连接、下达调用。永远是 Client 主动去调 Server,就像电脑主动去读 U 盘,U 盘不会反过来指挥电脑。
角色USB 类比它负责谁来写
MCP ServerUSB 设备把"查天气 / 读文件 / 查库"等能力,按标准摆出来工具/数据提供方(常有现成的)
MCP ClientUSB 控制器连接 Server、拿到工具清单、替 Agent 发起调用、收结果Agent 框架/宿主(常内置)
👶 好消息:大部分你都不用自己写成熟的 Agent 宿主(如 Claude 桌面端、各类 IDE)自带 Client;数据库、文件系统、GitHub 等也大多有官方或社区做好的 Server。你通常做的只是在配置文件里填一行"我要连哪个 Server",而不是从零造轮子。真要自己写 Server 时,官方 SDK 也很短(下面 L06 会看一眼)。
L04

stdio / SSE:两种"走线方式"

🤔 痛点Client 和 Server 之间靠什么传消息?你会在配置里看到 stdio、sse(或 http)这些词,不懂就慌。
💡 本质这只是"数据线怎么走"的两种方式,概念上不难:
• stdio(标准输入输出):Server 就是本机上的一个小程序,Client 直接把它当子进程启动,通过"管道"喂消息、收回复。像 USB 直插——同一台机器、快、常用于本地工具。
• SSE / HTTP:Server 是一个网络服务(可能在别的机器/云上),Client 通过网址连过去。像走网线连远端设备——跨机器、适合团队共享的远程服务。
stdio(本机直插) vs SSE/HTTP(网线连远端) Client(Agent) 本机 Server stdio:管道,同机 Client 远端 Server SSE/HTTP:网络
图注:入门只需记住"本机小工具用 stdio,远程共享服务用 SSE/HTTP"。选哪个由 Server 支持哪种决定,配置里对上就行。
L05

能连什么:工具、资源、提示模板

🤔 痛点MCP 光能"调函数"吗?还是能干更多?
💡 本质一个 MCP Server 可以对外提供三类东西,记成"设备能给你三种服务":
• Tools(工具)=能动手做事的按钮(查天气、发消息、写文件)——这是最常用的,就是 Day 29-30 那种可调用函数。
• Resources(资源)=能读的数据(某个文件内容、一条数据库记录),供模型当上下文。
• Prompts(提示模板)=预设好的提问模板,一键套用常见任务的写法。
📝 举个例子:一个"文件系统 MCP Server" 它可能同时提供:
· Tool write_file(path, content)——让 Agent 写文件(动手);
· Resource file:///项目/README.md——把某文件内容喂给模型读(读数据);
· Prompt「代码审查」——预置一段"请按以下清单审查这段代码……"的模板(套模板)。
Agent 插上它,读写文件、审代码一气呵成。入门阶段你 90% 场景只会用到 Tools,另两类先混脸熟。
L06

一次调用全过程 + 极简 Server 一瞥

🤔 痛点知道了角色和名词,那"用户问一句"到"工具跑完返回",中间到底怎么流转的?
💡 本质五步接力,顺着 USB 类比走一遍就通:①插上设备时先报菜单(Client 连 Server,问"你有哪些工具");②用户提问,Agent 里的模型决定要调哪个工具(这就是 Function Calling);③Client 按 MCP 标准把调用发给 Server;④Server 真正执行,返回结果;⑤模型拿到结果,组织成人话回给用户。
一次 MCP 工具调用的接力 用户提问 模型决定调哪个 Client 转发 Server执行 回人话 (插上时 Client 已先问过 Server「你有哪些工具」)
图注:你会发现第②步正是 Day 29 学的 Function Calling——MCP 只是把③④两步标准化了。

用官方 Python SDK 写个"只有一个工具"的极简 Server,短到不可思议(伪简化版,展示形态):

# pip install mcp   （官方 Python SDK，包名 mcp）
from mcp.server.fastmcp import FastMCP    # 造一个 MCP Server 的快捷工具

mcp = FastMCP("天气小助手")               # 给这个 Server 起个名

@mcp.tool()                               # 这行"贴标签"：把下面函数登记成一个 MCP 工具
def get_weather(city: str) -> str:        # 参数/返回都写类型，SDK 自动生成"菜单"给模型看
    """查询某城市天气。city 传中文城市名。"""  # 这段说明也会给模型看，务必写清
    # 真实项目这里会去调气象 API；演示先写死
    return f"{city}：晴，26℃"

if __name__ == "__main__":
    mcp.run()                             # 以 stdio 方式跑起来，等 Client 来连
注意:@mcp.tool() 这一行(叫"装饰器",Day05 的类之后又一个新语法,先照抄)就是把普通函数"登记成 MCP 工具"的关键;函数上的类型标注和三引号说明会被自动变成给模型看的"菜单",所以要写清楚——这正好呼应 Day 30 的"好的工具描述"。

👶 小白:那我今天必须自己搭一个 Server 才算学会吗?

👨‍🏫 老师:不必!入门阶段,你先学会"用现成的"就极有价值:在支持 MCP 的宿主(比如 Claude 桌面端)的配置文件里,填一行连上一个官方的文件系统或数据库 Server,试着让它帮你读文件——这一步就打通了 MCP 的任督二脉。自己写 Server 是进阶,等你真有个内部系统要接时再动手,那时上面这十行就是模板。会用 > 会造,老规矩。

🔗 想看真实产品怎么加载 MCP?去《Claude Code 源码精讲》→
Claude Code 就是一个内置 MCP Client 的实战 Agent——它启动时怎么发现并连上你配置的 Server、怎么把工具菜单塞进模型上下文,源码里看得一清二楚。学完回来继续 Day 32。
L07

今日小结 + 动手 10 分钟

🧠 今天你应该能回答

  • MCP 一句话是什么?它像现实里的什么(USB)?解决了什么痛点?
  • MCP Client 和 Server 谁主动调谁?各自像 USB 世界里的什么?
  • stdio 和 SSE/HTTP 的区别?本机小工具通常用哪个?
  • 一个 MCP Server 能提供哪三类东西?最常用的是哪类?
  • MCP 和 Day 29 的 Function Calling 是什么分工关系?

✋ 动手 10 分钟:画出你身边系统的"MCP 接线图"

今天不写代码也能学到位——练"用 MCP 视角看世界"。找张纸或用下面模板,想象你要给一个"办公助理 Agent"接 3 个能力,给每个想清楚它该是什么:

# 照这个表把你的场景填一遍（用记事本即可）
# 能力          | 该做成 Server 提供的哪类 | stdio 还是 SSE | 为什么
# 读本地周报    | Resource + Tool          | stdio          | 文件在我本机
# 查公司考勤库  | Tool                     | SSE/HTTP       | 库在公司服务器，团队共享
# 发企业微信    | Tool                     | SSE/HTTP       | 调远程 API

进阶(有兴趣再做):装官方 SDK,把 L06 那十行 get_weather 存成 server.py 跑起来,体会"贴个 @mcp.tool() 就成了工具"的感觉:

python -m venv .venv && source .venv/bin/activate  # 老规矩，先建车间（Day05）
pip install mcp                                     # 装官方 SDK
python server.py                                    # 跑起来（它会等 Client 来连，Ctrl+C 退出）
明日预告 · Day 32:有了一个个工具,真实任务往往一个工具不够用——查完库还要发邮件,发失败还得重试。明天学 多步工具链与失败处理:怎么让 Agent 连续调好几个工具、把前一步结果喂给下一步,以及关键的"工程素养"——中途失败怎么重试/降级、怎么设循环上限防止无限打转。这是从"能调一个工具"到"能干成一件事"的分水岭。
← Day 30 · 写安全工具 Day 32 · 多步工具链与失败处理 →