Day08大模型 MCP 实战——让 AI 长出手来操作你的工具前言3 个工具3 套对接代码上周三晚上 9 点我接到朋友老陈的电话。他的 AI 客服项目要上线了但卡在一个地方客服助手需要能查订单、能发邮件、能读文件。三个能力听起来不复杂。我先接了邮件 API写了一套适配代码。然后接数据库查询又写一套。现在要接文件系统第三套。他在电话那头叹气而且我们下个月可能从 GPT-4o 换成 Claude到时候这三套全得重写。我说你这不是在接工具你是在织蜘蛛网。他的困境不是个例。这是 2024 年之前所有 AI 应用开发者的痛——N 个模型 × M 个工具 N×M 份适配代码。5 个模型接 8 个工具就是 40 份代码。每换一个模型全部重来。上一篇 Day07 讲了记忆系统让 AI记住你。但光有记忆不够——AI 还缺一样东西手。能去查数据库、能去发邮件、能去读文件的手。Anthropic 在 2024 年底开源了一个协议专门解决这个问题。它叫MCPModel Context Protocol——大模型的USB-C 接口。这篇文章干四件事讲透 MCP 是什么为什么它能终结集成地狱拆解 MCP 架构——Client、Server、Transport 各管什么给你一个可运行的 MCP Server demoPython直接跑MCP vs Function Calling——什么时候该用哪个读完你会发现MCP 之于 AI 工具集成就像 HTTP 之于 Web——不是某个公司的产品而是整个行业的协议。PART 01MCP 是什么——大模型的USB-C 接口先看一个让人头皮发麻的数学题。假设你有 5 个模型GPT-4o、Claude、Gemini、通义千问、DeepSeek要接 8 个工具邮件、数据库、文件系统、GitHub、Slack、日历、搜索引擎、内部 API。没有 MCP 之前你需要写多少份适配代码5 × 8 40 份。每份都要处理模型 A 的 function calling 格式和模型 B 不一样工具 X 的参数结构和工具 Y 不一样。40 份代码40 个维护点。MCP 的核心思想简单到一句话在模型和工具之间放一个标准协议层。模型只需要实现 MCP Client工具只需要实现 MCP Server。协议层负责翻译——模型说我要查订单协议层翻译成对应工具能理解的格式。这样 5 × 8 40 份代码变成了 5 8 13 份。模型侧 5 份 Client工具侧 8 份 Server互不干扰。换个模型Client 不变Server 不用改。换个工具Server 不变Client 不用改。MCP 三大能力MCP 不只是调用函数。它定义了三类能力覆盖 AI 与外部世界交互的几乎所有场景Resources资源——让 AI 读取数据比如文件内容、数据库记录、API 返回值。Resources 是只读的AI 可以看但不能改。用 URI 寻址像file:///users/desktop/notes.txt这样的路径。Tools工具——让 AI 执行操作比如发邮件、写文件、创建 GitHub Issue。Tools 有副作用执行后会改变外部状态。每个 Tool 定义自己的参数 schemaJSON SchemaAI 根据 schema 决定怎么调用。Prompts提示模板——预定义交互模式把常用的 prompt 模式封装成模板复用。比如代码审查模板、数据分析模板带参数一键调用。三类能力各司其职Resources 管看Tools 管做Prompts 管怎么问。一个类比帮你记住Function Calling 像打电话——每次都要手动拨号写适配代码换号码了就得重拨。MCP 像USB-C——插上就能用不用管两边是什么设备。充电、传数据、接显示器一个接口全搞定。PART 02MCP 架构拆解——Client、Server、TransportMCP 的架构不复杂但有几个角色容易搞混。我拆开讲。四个角色Host宿主应用运行 LLM 的应用程序。Claude Desktop、Cursor、Windsurf或者你自己写的 Agent都是 Host。Host 决定什么时候用 MCP。Client客户端Host 内部的 MCP 连接器。每个 Client1:1 对应一个 Server。如果你同时连了文件系统 Server、GitHub Server、数据库 ServerHost 里就有 3 个 Client各管各的。Server服务端暴露工具和资源的独立进程。每个 Server 聚焦一个能力域——文件系统 Server 管文件操作GitHub Server 管 repo 操作互不干涉。Transport传输层Client 和 Server 之间的通信管道。两种方式stdio标准输入输出本地进程通信。适合本地工具启动快、零配置。Streamable HTTP / SSE基于 HTTP 的远程通信。适合云端服务支持跨网络。本地开发用 stdio生产部署用 HTTP。切换 Transport 不改业务代码只改启动配置。三大原语怎么通信MCP 用JSON-RPC 2.0协议通信。所有消息都是 JSON格式统一。拿 Tools 举例通信流程是这样的// 1. Client 问 Server你有哪些工具 {method: tools/list, params: {}} // 2. Server 回答我有两个工具 {tools: [ {name: list_directory, description: 列出目录内容, inputSchema: {type: object, properties: {path: {type: string}}}}, {name: read_file, description: 读取文件内容, inputSchema: {type: object, properties: {path: {type: string}}}} ]} // 3. Client代表 LLM说调用 list_directory参数 path/Users/desktop {method: tools/call, params: {name: list_directory, arguments: {path: /Users/desktop}}} // 4. Server 执行后返回结果 {content: [{type: text, text: notes.txt\nreport.pdf\nphoto.jpg}]}Resources 和 Prompts 的通信模式类似只是方法名不同resources/list、resources/read、prompts/list、prompts/get。核心设计理念Server 不关心是哪个模型在调用它模型也不关心 Server 内部怎么实现。协议层做了完全的解耦。PART 03动手实现一个 MCP Server完整可运行代码理论讲完了上手写代码。我们用官方mcpPython SDK 实现一个文件系统工具 Server——让 AI 能列出目录、读文件。安装依赖pip install mcp完整代码 Day08 MCP Server Demo —— 文件系统工具 让 AI 能列出目录内容、读取文件 依赖pip install mcp 运行python server.py import os from mcp.server.fastmcp import FastMCP # 创建 MCP Server 实例 mcp FastMCP(filesystem-tools) # 注册 Tools可执行操作 mcp.tool() def list_directory(path: str) - str: 列出指定目录下的文件和文件夹 Args: path: 目录路径如 /Users/desktop try: entries os.listdir(path) # 区分文件和文件夹 result [] for entry in entries: full_path os.path.join(path, entry) if os.path.isdir(full_path): result.append(f\U0001F4C1 {entry}/) else: size os.path.getsize(full_path) result.append(f\U0001F4C4 {entry} ({size} bytes)) return \n.join(result) if result else 目录为空 except FileNotFoundError: return f错误目录不存在 {path} except PermissionError: return f错误无权限访问 {path} mcp.tool() def read_file(path: str) - str: 读取指定文本文件的内容 Args: path: 文件路径如 /Users/desktop/notes.txt try: with open(path, r, encodingutf-8) as f: content f.read() # 限制返回长度避免超长文件撑爆上下文 if len(content) 10000: content content[:10000] \n\n... (文件过长已截断) return content except FileNotFoundError: return f错误文件不存在 {path} except UnicodeDecodeError: return f错误无法解码文件可能是二进制文件{path} # 注册 Resource只读数据 mcp.resource(file://{path}) def read_file_resource(path: str) - str: 通过 URI 访问文件内容如 file:///Users/desktop/notes.txt return read_file(path) # 启动 Server if __name__ __main__: # stdio 模式启动适合本地工具 mcp.run(transportstdio)代码不到 60 行但功能完整两个 Tool列目录、读文件 一个 ResourceURI 访问文件。几个关键点解释一下FastMCP是什么它是官方 SDK 提供的高层 API用装饰器注册 Tool 和 Resource自动处理 JSON-RPC 通信细节。不用手写 JSON-RPC 消息装饰器搞定。inputSchema去哪了FastMCP自动从函数签名和类型注解生成。path: str自动变成{type: string}AI 看到 schema 就知道该怎么调用。为什么限制返回长度文件内容直接塞进 LLM 上下文超长文件会撑爆 token 限制。10K 字符是个安全阈值。配置 Claude Desktop 连接写好 Server 后让 Claude Desktop 连上它。编辑配置文件// macOS: ~/Library/Application Support/Claude/claude_desktop_config.json { mcpServers: { filesystem-tools: { command: python, args: [/path/to/your/server.py] } } }重启 Claude Desktop左下角会出现一个工具图标表示 MCP Server 已连接。测试效果在 Claude Desktop 里输入列出我桌面上的文件Claude 会自动识别意图调用list_directory工具拿到结果后用自然语言总结您的桌面上有以下文件 - Screenshots/ - notes.txt (1,204 bytes) - report.pdf (2,856,432 bytes) - photo.jpg (3,201,564 bytes)整个过程你不需要写任何 prompt 来教模型用工具——MCP 协议自动完成了工具发现、参数填充、结果回传。这就是 MCP 的威力一次开发任何支持 MCP 的 Host 都能用你的工具。今天 Claude Desktop 能用明天 Cursor 能用后天你自己写的 Agent 也能用。PART 04MCP vs Function Calling——什么时候用哪个到这里你可能会问我已经在用 Function Calling 了为什么要换 MCP先说结论不是替代关系是不同层级的方案。核心区别维度Function CallingMCP是什么模型原生能力应用层标准协议开发成本低写个函数 JSON Schema中实现一个 Server复用性差每模型 API 格式不同好一次开发处处可用生态各模型各自为政开放协议社区共建跨模型不支持GPT 和 Claude 格式不同原生支持协议统一适合场景单模型、少量工具多模型、多工具、需复用判断框架问自己三个问题1. 你用几个模型只用一个模型 → Function Calling 够了。你的代码和这个模型绑定了但短期内没有切换需求。多个模型或未来可能切换→ MCP。协议层隔离了模型差异换模型不改工具代码。2. 你有几个工具1~3 个工具 → Function Calling。直接写函数简单直接。5 个以上工具 → MCP。工具多了统一管理比散落各处强。MCP Server 可以按域分组文件系统一组、数据库一组、通信一组。3. 工具需要跨项目复用吗不需要 → Function Calling。每个项目自己管自己的工具。需要 → MCP。一个 Server 写好多个项目复用。团队 A 的 GitHub Server团队 B 直接拿来用。现状与生态截至 2026 年中MCP 生态已经相当成熟Claude Desktop / Cursor / Windsurf原生支持 MCP开箱即用官方 Server文件系统、GitHub、PostgreSQL、Google Drive、Slack 等数十个社区 Server涵盖 Notion、Linear、Jira、Figma 等主流工具OpenAI尚未官方支持 MCP但社区已有适配层如mcp-openai-adapter趋势很明确MCP 正在成为 AI 工具集成的标准协议。就像 HTTP 统一了 Web 通信一样MCP 正在统一 AI 与工具的通信。结尾AI 的HTTP 时刻回头看这篇文章的核心MCP 是什么模型和工具之间的标准协议层把 N×M 适配问题变成 NM架构四角色Host 管调度、Client 管连接、Server 管能力、Transport 管通信三大原语Resources 管看、Tools 管做、Prompts 管怎么问选型框架单模型少量工具用 Function Calling多模型多工具用 MCPDay07 讲记忆时我说记忆是 AI 从工具变伙伴的分水岭。MCP 解决的是另一个问题——让 AI 从只会说话变成能做事。一个只能生成文字的 AI再聪明也只是个百科全书。一个能调用工具的 AI才是真正的助手——能帮你查数据、发邮件、管文件、操作系统。老陈后来把三个工具用 MCP Server 重构了。现在他换模型只需要改一行配置工具代码一行不用动。电话那头的叹气声变成了早知道有这东西我那三周白熬了。MCP 之于 AI 工具集成就像 HTTP 之于 Web——不是某个公司的产品而是整个行业的协议。当协议统一的那一刻生态就开始爆发。这就是 MCP 正在做的事。互动时间你的 AI 应用里工具调用用的 Function Calling 还是 MCP遇到过集成地狱吗欢迎评论区聊聊。下一篇 Day09 预告大模型前置之数据清洗——数据是 AI 的粮食垃圾进则垃圾出。关注小刘檀木不错过每一篇。— END —小刘檀木 · 帮普通人把 AI 学进简历
Day08大模型 MCP 实战——让 AI 长出手来操作你的工具前言3 个工具3 套对接代码上周三晚上 9 点我接到朋友老陈的电话。他的 AI 客服项目要上线了但卡在一个地方客服助手需要能查订单、能发邮件、能读文件。三个能力听起来不复杂。我先接了邮件 API写了一套适配代码。然后接数据库查询又写一套。现在要接文件系统第三套。他在电话那头叹气而且我们下个月可能从 GPT-4o 换成 Claude到时候这三套全得重写。我说你这不是在接工具你是在织蜘蛛网。他的困境不是个例。这是 2024 年之前所有 AI 应用开发者的痛——N 个模型 × M 个工具 N×M 份适配代码。5 个模型接 8 个工具就是 40 份代码。每换一个模型全部重来。上一篇 Day07 讲了记忆系统让 AI记住你。但光有记忆不够——AI 还缺一样东西手。能去查数据库、能去发邮件、能去读文件的手。Anthropic 在 2024 年底开源了一个协议专门解决这个问题。它叫MCPModel Context Protocol——大模型的USB-C 接口。这篇文章干四件事讲透 MCP 是什么为什么它能终结集成地狱拆解 MCP 架构——Client、Server、Transport 各管什么给你一个可运行的 MCP Server demoPython直接跑MCP vs Function Calling——什么时候该用哪个读完你会发现MCP 之于 AI 工具集成就像 HTTP 之于 Web——不是某个公司的产品而是整个行业的协议。PART 01MCP 是什么——大模型的USB-C 接口先看一个让人头皮发麻的数学题。假设你有 5 个模型GPT-4o、Claude、Gemini、通义千问、DeepSeek要接 8 个工具邮件、数据库、文件系统、GitHub、Slack、日历、搜索引擎、内部 API。没有 MCP 之前你需要写多少份适配代码5 × 8 40 份。每份都要处理模型 A 的 function calling 格式和模型 B 不一样工具 X 的参数结构和工具 Y 不一样。40 份代码40 个维护点。MCP 的核心思想简单到一句话在模型和工具之间放一个标准协议层。模型只需要实现 MCP Client工具只需要实现 MCP Server。协议层负责翻译——模型说我要查订单协议层翻译成对应工具能理解的格式。这样 5 × 8 40 份代码变成了 5 8 13 份。模型侧 5 份 Client工具侧 8 份 Server互不干扰。换个模型Client 不变Server 不用改。换个工具Server 不变Client 不用改。MCP 三大能力MCP 不只是调用函数。它定义了三类能力覆盖 AI 与外部世界交互的几乎所有场景Resources资源——让 AI 读取数据比如文件内容、数据库记录、API 返回值。Resources 是只读的AI 可以看但不能改。用 URI 寻址像file:///users/desktop/notes.txt这样的路径。Tools工具——让 AI 执行操作比如发邮件、写文件、创建 GitHub Issue。Tools 有副作用执行后会改变外部状态。每个 Tool 定义自己的参数 schemaJSON SchemaAI 根据 schema 决定怎么调用。Prompts提示模板——预定义交互模式把常用的 prompt 模式封装成模板复用。比如代码审查模板、数据分析模板带参数一键调用。三类能力各司其职Resources 管看Tools 管做Prompts 管怎么问。一个类比帮你记住Function Calling 像打电话——每次都要手动拨号写适配代码换号码了就得重拨。MCP 像USB-C——插上就能用不用管两边是什么设备。充电、传数据、接显示器一个接口全搞定。PART 02MCP 架构拆解——Client、Server、TransportMCP 的架构不复杂但有几个角色容易搞混。我拆开讲。四个角色Host宿主应用运行 LLM 的应用程序。Claude Desktop、Cursor、Windsurf或者你自己写的 Agent都是 Host。Host 决定什么时候用 MCP。Client客户端Host 内部的 MCP 连接器。每个 Client1:1 对应一个 Server。如果你同时连了文件系统 Server、GitHub Server、数据库 ServerHost 里就有 3 个 Client各管各的。Server服务端暴露工具和资源的独立进程。每个 Server 聚焦一个能力域——文件系统 Server 管文件操作GitHub Server 管 repo 操作互不干涉。Transport传输层Client 和 Server 之间的通信管道。两种方式stdio标准输入输出本地进程通信。适合本地工具启动快、零配置。Streamable HTTP / SSE基于 HTTP 的远程通信。适合云端服务支持跨网络。本地开发用 stdio生产部署用 HTTP。切换 Transport 不改业务代码只改启动配置。三大原语怎么通信MCP 用JSON-RPC 2.0协议通信。所有消息都是 JSON格式统一。拿 Tools 举例通信流程是这样的// 1. Client 问 Server你有哪些工具 {method: tools/list, params: {}} // 2. Server 回答我有两个工具 {tools: [ {name: list_directory, description: 列出目录内容, inputSchema: {type: object, properties: {path: {type: string}}}}, {name: read_file, description: 读取文件内容, inputSchema: {type: object, properties: {path: {type: string}}}} ]} // 3. Client代表 LLM说调用 list_directory参数 path/Users/desktop {method: tools/call, params: {name: list_directory, arguments: {path: /Users/desktop}}} // 4. Server 执行后返回结果 {content: [{type: text, text: notes.txt\nreport.pdf\nphoto.jpg}]}Resources 和 Prompts 的通信模式类似只是方法名不同resources/list、resources/read、prompts/list、prompts/get。核心设计理念Server 不关心是哪个模型在调用它模型也不关心 Server 内部怎么实现。协议层做了完全的解耦。PART 03动手实现一个 MCP Server完整可运行代码理论讲完了上手写代码。我们用官方mcpPython SDK 实现一个文件系统工具 Server——让 AI 能列出目录、读文件。安装依赖pip install mcp完整代码 Day08 MCP Server Demo —— 文件系统工具 让 AI 能列出目录内容、读取文件 依赖pip install mcp 运行python server.py import os from mcp.server.fastmcp import FastMCP # 创建 MCP Server 实例 mcp FastMCP(filesystem-tools) # 注册 Tools可执行操作 mcp.tool() def list_directory(path: str) - str: 列出指定目录下的文件和文件夹 Args: path: 目录路径如 /Users/desktop try: entries os.listdir(path) # 区分文件和文件夹 result [] for entry in entries: full_path os.path.join(path, entry) if os.path.isdir(full_path): result.append(f\U0001F4C1 {entry}/) else: size os.path.getsize(full_path) result.append(f\U0001F4C4 {entry} ({size} bytes)) return \n.join(result) if result else 目录为空 except FileNotFoundError: return f错误目录不存在 {path} except PermissionError: return f错误无权限访问 {path} mcp.tool() def read_file(path: str) - str: 读取指定文本文件的内容 Args: path: 文件路径如 /Users/desktop/notes.txt try: with open(path, r, encodingutf-8) as f: content f.read() # 限制返回长度避免超长文件撑爆上下文 if len(content) 10000: content content[:10000] \n\n... (文件过长已截断) return content except FileNotFoundError: return f错误文件不存在 {path} except UnicodeDecodeError: return f错误无法解码文件可能是二进制文件{path} # 注册 Resource只读数据 mcp.resource(file://{path}) def read_file_resource(path: str) - str: 通过 URI 访问文件内容如 file:///Users/desktop/notes.txt return read_file(path) # 启动 Server if __name__ __main__: # stdio 模式启动适合本地工具 mcp.run(transportstdio)代码不到 60 行但功能完整两个 Tool列目录、读文件 一个 ResourceURI 访问文件。几个关键点解释一下FastMCP是什么它是官方 SDK 提供的高层 API用装饰器注册 Tool 和 Resource自动处理 JSON-RPC 通信细节。不用手写 JSON-RPC 消息装饰器搞定。inputSchema去哪了FastMCP自动从函数签名和类型注解生成。path: str自动变成{type: string}AI 看到 schema 就知道该怎么调用。为什么限制返回长度文件内容直接塞进 LLM 上下文超长文件会撑爆 token 限制。10K 字符是个安全阈值。配置 Claude Desktop 连接写好 Server 后让 Claude Desktop 连上它。编辑配置文件// macOS: ~/Library/Application Support/Claude/claude_desktop_config.json { mcpServers: { filesystem-tools: { command: python, args: [/path/to/your/server.py] } } }重启 Claude Desktop左下角会出现一个工具图标表示 MCP Server 已连接。测试效果在 Claude Desktop 里输入列出我桌面上的文件Claude 会自动识别意图调用list_directory工具拿到结果后用自然语言总结您的桌面上有以下文件 - Screenshots/ - notes.txt (1,204 bytes) - report.pdf (2,856,432 bytes) - photo.jpg (3,201,564 bytes)整个过程你不需要写任何 prompt 来教模型用工具——MCP 协议自动完成了工具发现、参数填充、结果回传。这就是 MCP 的威力一次开发任何支持 MCP 的 Host 都能用你的工具。今天 Claude Desktop 能用明天 Cursor 能用后天你自己写的 Agent 也能用。PART 04MCP vs Function Calling——什么时候用哪个到这里你可能会问我已经在用 Function Calling 了为什么要换 MCP先说结论不是替代关系是不同层级的方案。核心区别维度Function CallingMCP是什么模型原生能力应用层标准协议开发成本低写个函数 JSON Schema中实现一个 Server复用性差每模型 API 格式不同好一次开发处处可用生态各模型各自为政开放协议社区共建跨模型不支持GPT 和 Claude 格式不同原生支持协议统一适合场景单模型、少量工具多模型、多工具、需复用判断框架问自己三个问题1. 你用几个模型只用一个模型 → Function Calling 够了。你的代码和这个模型绑定了但短期内没有切换需求。多个模型或未来可能切换→ MCP。协议层隔离了模型差异换模型不改工具代码。2. 你有几个工具1~3 个工具 → Function Calling。直接写函数简单直接。5 个以上工具 → MCP。工具多了统一管理比散落各处强。MCP Server 可以按域分组文件系统一组、数据库一组、通信一组。3. 工具需要跨项目复用吗不需要 → Function Calling。每个项目自己管自己的工具。需要 → MCP。一个 Server 写好多个项目复用。团队 A 的 GitHub Server团队 B 直接拿来用。现状与生态截至 2026 年中MCP 生态已经相当成熟Claude Desktop / Cursor / Windsurf原生支持 MCP开箱即用官方 Server文件系统、GitHub、PostgreSQL、Google Drive、Slack 等数十个社区 Server涵盖 Notion、Linear、Jira、Figma 等主流工具OpenAI尚未官方支持 MCP但社区已有适配层如mcp-openai-adapter趋势很明确MCP 正在成为 AI 工具集成的标准协议。就像 HTTP 统一了 Web 通信一样MCP 正在统一 AI 与工具的通信。结尾AI 的HTTP 时刻回头看这篇文章的核心MCP 是什么模型和工具之间的标准协议层把 N×M 适配问题变成 NM架构四角色Host 管调度、Client 管连接、Server 管能力、Transport 管通信三大原语Resources 管看、Tools 管做、Prompts 管怎么问选型框架单模型少量工具用 Function Calling多模型多工具用 MCPDay07 讲记忆时我说记忆是 AI 从工具变伙伴的分水岭。MCP 解决的是另一个问题——让 AI 从只会说话变成能做事。一个只能生成文字的 AI再聪明也只是个百科全书。一个能调用工具的 AI才是真正的助手——能帮你查数据、发邮件、管文件、操作系统。老陈后来把三个工具用 MCP Server 重构了。现在他换模型只需要改一行配置工具代码一行不用动。电话那头的叹气声变成了早知道有这东西我那三周白熬了。MCP 之于 AI 工具集成就像 HTTP 之于 Web——不是某个公司的产品而是整个行业的协议。当协议统一的那一刻生态就开始爆发。这就是 MCP 正在做的事。互动时间你的 AI 应用里工具调用用的 Function Calling 还是 MCP遇到过集成地狱吗欢迎评论区聊聊。下一篇 Day09 预告大模型前置之数据清洗——数据是 AI 的粮食垃圾进则垃圾出。关注小刘檀木不错过每一篇。— END —小刘檀木 · 帮普通人把 AI 学进简历
