专栏MCP 协议实战| 第 1 篇 / 共 15 篇先说一个让我抓狂的经历。去年我在一家公司做 AI 助手要对接的工具有MySQL 数据库、公司内部 Wiki、GitHub 仓库、Jira 工单、还有十几个内部 API。每对接一个工具我就要写一套 Function Calling 描述然后为 OpenAI、Claude、Gemini 各自维护一份格式——因为三家的 JSON 格式各不相同。对接五个工具我维护了十五份配置。哪天某个 API 改了参数我得同步改三个地方。那种感觉就像用不同厂商的充电线给同一台设备充电每次出门都要带一堆转接头。MCP 就是那根 USB-C 线。一、问题的根源AI 工具集成的接口地狱在理解 MCP 之前先搞清楚它要解决什么问题。1.1 传统方式Function Calling 的三大痛点假设你要让 AI 查询一个数据库传统的 Function Calling 是这么做的// OpenAI 格式{functions:[{name:query_database,description:执行 SQL 查询,parameters:{type:object,properties:{sql:{type:string}}}}]}// Anthropic Claude 格式tools 字段结构不同{tools:[{name:query_database,description:执行 SQL 查询,input_schema:{type:object,properties:{sql:{type:string}}}}]}就这么一个工具OpenAI 用functionsClaude 用toolsinput_schema。接入五个工具支持三个模型你要维护 15 份配置。痛点一格式不统一——每家 LLM 的 Function Calling 格式各自为政工具定义无法复用。痛点二工具发现困难——没有标准方式让 AI 动态发现有哪些工具可用全靠开发者手动维护一份列表。痛点三只支持调用不支持读取——Function Calling 只有调用函数这一种模式无法优雅地表达读取一个文件或订阅一个数据流。1.2 更深的问题工具和模型的强耦合传统方式里工具定义和你用的 LLM 是强绑定的。换个模型所有工具配置得重写。这意味着你没法把同一套工具同时接给 Claude 和 GPT 用你开发的工具没法分享给别人直接用因为别人可能用不同的模型工具生态无法形成——每个人都在重复造轮子二、MCP 是什么**MCPModel Context Protocol**是 Anthropic 于 2024 年 11 月发布的开放协议定义了 LLM 与外部工具之间交互的标准格式。一句话理解MCP AI 工具的 USB-C 接口标准┌─────────────────────┐ │ MCP Server工具 │ │ ┌───────────────┐ │ │ │ 数据库 Server │ │ │ │ 文件系统 Server│ │ │ │ GitHub Server │ │ │ └───────────────┘ │ └──────────┬──────────┘ │ MCP 协议JSON-RPC 2.0 ┌──────────┴──────────┐ │ MCP ClientAI │ │ ┌───────────────┐ │ │ │ Claude Desktop│ │ │ │ 你的 AI 应用 │ │ │ │ Cursor / Cline│ │ │ └───────────────┘ │ └─────────────────────┘工具Server只需实现一次所有支持 MCP 的 AI 客户端都能用。2.1 协议的底层JSON-RPC 2.0MCP 的传输层基于JSON-RPC 2.0这是一个成熟的远程调用协议。你不需要深入了解它的细节但理解它有助于调试// 客户端请求列出可用工具{jsonrpc:2.0,id:1,method:tools/list,params:{}}// Server 响应{jsonrpc:2.0,id:1,result:{tools:[{name:query_database,description:执行 SQL 查询并返回结果,inputSchema:{type:object,properties:{sql:{type:string,description:SQL 语句}},required:[sql]}}]}}关键点工具的inputSchema使用标准 JSON Schema这是业界通用格式不是 MCP 专有的。这意味着工具描述可以直接被各种验证工具、文档生成器处理。2.2 三大核心原语MCP 定义了三种核心概念原语类比控制方适用场景Tools工具函数调用AI 自主决定执行操作写文件、发邮件、调 APIResources资源只读数据源宿主应用提供数据读文件、查配置、获取上下文Prompts提示词快捷指令用户触发预定义工作流代码审查模板、报告模板后面的文章会深入每一个原语这里先建立整体印象。三、MCP 的通信模式3.1 两种传输方式stdio标准输入输出Client 启动 Server 进程通过 stdin/stdout 通信适合本地工具Claude Desktop 就用这种方式优点简单无需网络缺点只能本地使用Claude Desktop ──stdin── Python Server 进程 Claude Desktop ──stdout── Python Server 进程SSEServer-Sent EventsServer 是一个 HTTP 服务Client 通过 HTTP 连接适合远程部署团队共享工具优点可远程访问、可多用户共享缺点需要网络和部署AI Client ──HTTP POST── MCP ServerHTTP 服务 AI Client ──SSE Stream── MCP ServerHTTP 服务3.2 完整的生命周期一次完整的 MCP 会话经历这几个阶段1. 初始化Initialization Client → initialize → Server Server → 返回能力声明支持哪些原语 2. 能力发现Capability Discovery Client → tools/list → Server获取工具列表 Client → resources/list → Server获取资源列表 3. 工具调用Tool Invocation Client → tools/call → Server Server → 返回执行结果 4. 会话结束 Client 关闭连接或进程这个握手机制意味着AI 是动态发现工具的而不是硬编码。你新增一个工具重启 ServerAI 立刻就能用上不需要改任何 AI 侧的代码。四、为什么是现在MCP 生态的爆发4.1 平台支持现状2025年MCP 发布仅半年多支持的工具和平台已经覆盖了主流 AI 开发场景类型代表产品AI 客户端Claude Desktop、Cursor、Cline、Continue、ZedAI 平台Dify、Flowise、n8n、Langchain官方 ServerFilesystem、GitHub、PostgreSQL、Brave Search、Slack社区 Server超过 3000 个开源项目GitHub topics: mcp-server值得注意的是OpenAI 的 ChatGPT 和 Responses API 也在 2025 年宣布支持 MCP。这意味着 MCP 正在成为 AI 工具集成的事实标准不再只是 Anthropic 的私有协议。4.2 为什么生态增长这么快三个原因1. 开发成本极低。用 Python SDK10 行代码就能写出一个可用的 MCP Server。你现有的函数加两行装饰器就变成 AI 可调用的工具。2. 工具可复用。你写的数据库 MCP Server同事用 Cursor你用 Claude Desktop都能直接用。工具开发一次全团队受益。3. 时机刚好。2024-2025 年是 AI Agent 从实验走向实用的关键期。企业开始认真考虑如何让 AI 对接现有系统MCP 正好提供了一个低成本的答案。4.3 一个有意思的信号GitHub 上有一个项目叫Awesome MCP Servers2024年底只有几十个项目到 2025 年中已经超过 3000 个。这个速度和当年 npm 生态的早期爆发非常相似。如果这个趋势持续MCP 工具开发可能成为未来几年最值钱的工程技能之一。五、MCP 能解决什么真实问题理论说完了来看三个真实场景。场景一让 AI 成为真正的数据分析师之前的做法导出 CSV上传给 ChatGPT等它分析。每次数据更新都要重新导出。AI 只能分析历史快照看不到实时数据。接入 MCP 后用户我们昨天的用户注册量比上周同期如何 Claude[调用 query_database] SQL: SELECT DATE(created_at), COUNT(*) FROM users WHERE created_at DATE_SUB(NOW(), INTERVAL 14 DAY) GROUP BY DATE(created_at) 分析结果昨天注册 1,247 人上周同期 983 人增长 26.9%。 主要增长来源是华东地区41%建议关注该地区的渠道效果。AI 直接连库查的是实时数据不需要任何人工导出。场景二AI 辅助代码开发之前的做法把代码贴进对话框AI 看完给建议你手动修改再贴进去确认。来回复制粘贴。接入 Filesystem MCP 后用户帮我把 src/ 目录下所有的 TODO 注释整理成一个清单 Claude[调用 search_files 搜索 TODO] [调用 read_file 读取相关文件] 找到 23 个 TODO按优先级整理如下 【高优先级】 - src/auth.py:156 - 登录态过期逻辑未处理 - src/payment.py:89 - 退款接口未实现 ...场景三企业知识库问答接入 MCP 前RAG 系统每次都要检索全量文档而且 AI 看不到数据库里的实时数据。接入 MCP 后把文档检索、数据库查询、API 调用全部封装成 MCP ServerAI 按需组合调用一次对话完成跨系统的信息综合。六、MCP 的局限性不能盲目吹任何技术都有适用边界MCP 也不例外。当前的主要局限高延迟场景慎用。每次工具调用都是一次网络往返stdio 模式是进程间通信如果一个任务需要调用几十次工具延迟会很明显。安全边界需要自己维护。MCP 协议本身不包含鉴权机制安全控制全靠你在 Server 里实现。配置不当的 MCP Server 相当于给 AI 开了一个无限权限的操作入口。第 8 篇专门讲这个状态管理比较原始。MCP Server 本身是无状态的每次调用独立多步骤的有状态工作流需要在上层 Agent 框架里实现。调试体验还不完善。相比成熟的 REST APIMCP 的调试工具链还比较初级出了问题主要靠看日志。了解局限性才能在合适的场景用合适的工具。七、这个专栏讲什么接下来 14 篇我们按难度递进基础篇第2-3篇 ├── 搭建第一个 MCP Server5分钟跑起来 └── Tools/Resources/Prompts 三大原语深度解析 实战篇第4-9篇 ├── 数据库工具端MySQL/PostgreSQL ├── 文件系统工具端 ├── API 网关工具端把任意 REST API 接入 AI ├── 流式处理与实时推送 ├── 生产安全最佳实践 └── 从零实现 MCP Client 进阶篇第10-12篇 ├── MCP RAG 知识库增强 ├── MCP Agent 多工具自主循环 └── 知名开源项目源码分析 工程篇第13-15篇 ├── 企业级部署容器化、监控、高可用 ├── MCP 生态全景与未来路线图 └── 结语从工具开发者到 AI 生态建设者每篇的结构都一样核心概念 → 完整可运行代码 → 生产踩坑 → 小结。所有代码都经过测试直接 copy 能跑。八、在开始之前有一个认知上的准备工作要做。MCP 不是什么神秘的黑科技它就是一套 JSON 格式约定。理解了这一点你学习时就不会被协议两个字吓到。你现有的任何 Python 函数加上几行 MCP 的装饰器就能变成 AI 可调用的工具。这个门槛真的不高。下一篇我们直接写代码。5 分钟把第一个 MCP Server 跑起来接入 Claude Desktop。附录开始之前的资源MCP 官方文档https://modelcontextprotocol.io/官方 SDKPythonhttps://github.com/modelcontextprotocol/python-sdk官方 SDKTypeScripthttps://github.com/modelcontextprotocol/typescript-sdkAwesome MCP Servershttps://github.com/punkpeye/awesome-mcp-serversClaude Desktop 下载https://claude.ai/download专栏订阅持续更新建议收藏本系列第一篇方便导航。
MCP 是什么？为什么所有 AI 工具都在接入它
专栏MCP 协议实战| 第 1 篇 / 共 15 篇先说一个让我抓狂的经历。去年我在一家公司做 AI 助手要对接的工具有MySQL 数据库、公司内部 Wiki、GitHub 仓库、Jira 工单、还有十几个内部 API。每对接一个工具我就要写一套 Function Calling 描述然后为 OpenAI、Claude、Gemini 各自维护一份格式——因为三家的 JSON 格式各不相同。对接五个工具我维护了十五份配置。哪天某个 API 改了参数我得同步改三个地方。那种感觉就像用不同厂商的充电线给同一台设备充电每次出门都要带一堆转接头。MCP 就是那根 USB-C 线。一、问题的根源AI 工具集成的接口地狱在理解 MCP 之前先搞清楚它要解决什么问题。1.1 传统方式Function Calling 的三大痛点假设你要让 AI 查询一个数据库传统的 Function Calling 是这么做的// OpenAI 格式{functions:[{name:query_database,description:执行 SQL 查询,parameters:{type:object,properties:{sql:{type:string}}}}]}// Anthropic Claude 格式tools 字段结构不同{tools:[{name:query_database,description:执行 SQL 查询,input_schema:{type:object,properties:{sql:{type:string}}}}]}就这么一个工具OpenAI 用functionsClaude 用toolsinput_schema。接入五个工具支持三个模型你要维护 15 份配置。痛点一格式不统一——每家 LLM 的 Function Calling 格式各自为政工具定义无法复用。痛点二工具发现困难——没有标准方式让 AI 动态发现有哪些工具可用全靠开发者手动维护一份列表。痛点三只支持调用不支持读取——Function Calling 只有调用函数这一种模式无法优雅地表达读取一个文件或订阅一个数据流。1.2 更深的问题工具和模型的强耦合传统方式里工具定义和你用的 LLM 是强绑定的。换个模型所有工具配置得重写。这意味着你没法把同一套工具同时接给 Claude 和 GPT 用你开发的工具没法分享给别人直接用因为别人可能用不同的模型工具生态无法形成——每个人都在重复造轮子二、MCP 是什么**MCPModel Context Protocol**是 Anthropic 于 2024 年 11 月发布的开放协议定义了 LLM 与外部工具之间交互的标准格式。一句话理解MCP AI 工具的 USB-C 接口标准┌─────────────────────┐ │ MCP Server工具 │ │ ┌───────────────┐ │ │ │ 数据库 Server │ │ │ │ 文件系统 Server│ │ │ │ GitHub Server │ │ │ └───────────────┘ │ └──────────┬──────────┘ │ MCP 协议JSON-RPC 2.0 ┌──────────┴──────────┐ │ MCP ClientAI │ │ ┌───────────────┐ │ │ │ Claude Desktop│ │ │ │ 你的 AI 应用 │ │ │ │ Cursor / Cline│ │ │ └───────────────┘ │ └─────────────────────┘工具Server只需实现一次所有支持 MCP 的 AI 客户端都能用。2.1 协议的底层JSON-RPC 2.0MCP 的传输层基于JSON-RPC 2.0这是一个成熟的远程调用协议。你不需要深入了解它的细节但理解它有助于调试// 客户端请求列出可用工具{jsonrpc:2.0,id:1,method:tools/list,params:{}}// Server 响应{jsonrpc:2.0,id:1,result:{tools:[{name:query_database,description:执行 SQL 查询并返回结果,inputSchema:{type:object,properties:{sql:{type:string,description:SQL 语句}},required:[sql]}}]}}关键点工具的inputSchema使用标准 JSON Schema这是业界通用格式不是 MCP 专有的。这意味着工具描述可以直接被各种验证工具、文档生成器处理。2.2 三大核心原语MCP 定义了三种核心概念原语类比控制方适用场景Tools工具函数调用AI 自主决定执行操作写文件、发邮件、调 APIResources资源只读数据源宿主应用提供数据读文件、查配置、获取上下文Prompts提示词快捷指令用户触发预定义工作流代码审查模板、报告模板后面的文章会深入每一个原语这里先建立整体印象。三、MCP 的通信模式3.1 两种传输方式stdio标准输入输出Client 启动 Server 进程通过 stdin/stdout 通信适合本地工具Claude Desktop 就用这种方式优点简单无需网络缺点只能本地使用Claude Desktop ──stdin── Python Server 进程 Claude Desktop ──stdout── Python Server 进程SSEServer-Sent EventsServer 是一个 HTTP 服务Client 通过 HTTP 连接适合远程部署团队共享工具优点可远程访问、可多用户共享缺点需要网络和部署AI Client ──HTTP POST── MCP ServerHTTP 服务 AI Client ──SSE Stream── MCP ServerHTTP 服务3.2 完整的生命周期一次完整的 MCP 会话经历这几个阶段1. 初始化Initialization Client → initialize → Server Server → 返回能力声明支持哪些原语 2. 能力发现Capability Discovery Client → tools/list → Server获取工具列表 Client → resources/list → Server获取资源列表 3. 工具调用Tool Invocation Client → tools/call → Server Server → 返回执行结果 4. 会话结束 Client 关闭连接或进程这个握手机制意味着AI 是动态发现工具的而不是硬编码。你新增一个工具重启 ServerAI 立刻就能用上不需要改任何 AI 侧的代码。四、为什么是现在MCP 生态的爆发4.1 平台支持现状2025年MCP 发布仅半年多支持的工具和平台已经覆盖了主流 AI 开发场景类型代表产品AI 客户端Claude Desktop、Cursor、Cline、Continue、ZedAI 平台Dify、Flowise、n8n、Langchain官方 ServerFilesystem、GitHub、PostgreSQL、Brave Search、Slack社区 Server超过 3000 个开源项目GitHub topics: mcp-server值得注意的是OpenAI 的 ChatGPT 和 Responses API 也在 2025 年宣布支持 MCP。这意味着 MCP 正在成为 AI 工具集成的事实标准不再只是 Anthropic 的私有协议。4.2 为什么生态增长这么快三个原因1. 开发成本极低。用 Python SDK10 行代码就能写出一个可用的 MCP Server。你现有的函数加两行装饰器就变成 AI 可调用的工具。2. 工具可复用。你写的数据库 MCP Server同事用 Cursor你用 Claude Desktop都能直接用。工具开发一次全团队受益。3. 时机刚好。2024-2025 年是 AI Agent 从实验走向实用的关键期。企业开始认真考虑如何让 AI 对接现有系统MCP 正好提供了一个低成本的答案。4.3 一个有意思的信号GitHub 上有一个项目叫Awesome MCP Servers2024年底只有几十个项目到 2025 年中已经超过 3000 个。这个速度和当年 npm 生态的早期爆发非常相似。如果这个趋势持续MCP 工具开发可能成为未来几年最值钱的工程技能之一。五、MCP 能解决什么真实问题理论说完了来看三个真实场景。场景一让 AI 成为真正的数据分析师之前的做法导出 CSV上传给 ChatGPT等它分析。每次数据更新都要重新导出。AI 只能分析历史快照看不到实时数据。接入 MCP 后用户我们昨天的用户注册量比上周同期如何 Claude[调用 query_database] SQL: SELECT DATE(created_at), COUNT(*) FROM users WHERE created_at DATE_SUB(NOW(), INTERVAL 14 DAY) GROUP BY DATE(created_at) 分析结果昨天注册 1,247 人上周同期 983 人增长 26.9%。 主要增长来源是华东地区41%建议关注该地区的渠道效果。AI 直接连库查的是实时数据不需要任何人工导出。场景二AI 辅助代码开发之前的做法把代码贴进对话框AI 看完给建议你手动修改再贴进去确认。来回复制粘贴。接入 Filesystem MCP 后用户帮我把 src/ 目录下所有的 TODO 注释整理成一个清单 Claude[调用 search_files 搜索 TODO] [调用 read_file 读取相关文件] 找到 23 个 TODO按优先级整理如下 【高优先级】 - src/auth.py:156 - 登录态过期逻辑未处理 - src/payment.py:89 - 退款接口未实现 ...场景三企业知识库问答接入 MCP 前RAG 系统每次都要检索全量文档而且 AI 看不到数据库里的实时数据。接入 MCP 后把文档检索、数据库查询、API 调用全部封装成 MCP ServerAI 按需组合调用一次对话完成跨系统的信息综合。六、MCP 的局限性不能盲目吹任何技术都有适用边界MCP 也不例外。当前的主要局限高延迟场景慎用。每次工具调用都是一次网络往返stdio 模式是进程间通信如果一个任务需要调用几十次工具延迟会很明显。安全边界需要自己维护。MCP 协议本身不包含鉴权机制安全控制全靠你在 Server 里实现。配置不当的 MCP Server 相当于给 AI 开了一个无限权限的操作入口。第 8 篇专门讲这个状态管理比较原始。MCP Server 本身是无状态的每次调用独立多步骤的有状态工作流需要在上层 Agent 框架里实现。调试体验还不完善。相比成熟的 REST APIMCP 的调试工具链还比较初级出了问题主要靠看日志。了解局限性才能在合适的场景用合适的工具。七、这个专栏讲什么接下来 14 篇我们按难度递进基础篇第2-3篇 ├── 搭建第一个 MCP Server5分钟跑起来 └── Tools/Resources/Prompts 三大原语深度解析 实战篇第4-9篇 ├── 数据库工具端MySQL/PostgreSQL ├── 文件系统工具端 ├── API 网关工具端把任意 REST API 接入 AI ├── 流式处理与实时推送 ├── 生产安全最佳实践 └── 从零实现 MCP Client 进阶篇第10-12篇 ├── MCP RAG 知识库增强 ├── MCP Agent 多工具自主循环 └── 知名开源项目源码分析 工程篇第13-15篇 ├── 企业级部署容器化、监控、高可用 ├── MCP 生态全景与未来路线图 └── 结语从工具开发者到 AI 生态建设者每篇的结构都一样核心概念 → 完整可运行代码 → 生产踩坑 → 小结。所有代码都经过测试直接 copy 能跑。八、在开始之前有一个认知上的准备工作要做。MCP 不是什么神秘的黑科技它就是一套 JSON 格式约定。理解了这一点你学习时就不会被协议两个字吓到。你现有的任何 Python 函数加上几行 MCP 的装饰器就能变成 AI 可调用的工具。这个门槛真的不高。下一篇我们直接写代码。5 分钟把第一个 MCP Server 跑起来接入 Claude Desktop。附录开始之前的资源MCP 官方文档https://modelcontextprotocol.io/官方 SDKPythonhttps://github.com/modelcontextprotocol/python-sdk官方 SDKTypeScripthttps://github.com/modelcontextprotocol/typescript-sdkAwesome MCP Servershttps://github.com/punkpeye/awesome-mcp-serversClaude Desktop 下载https://claude.ai/download专栏订阅持续更新建议收藏本系列第一篇方便导航。
