专栏：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 用 functions，Claude 用 tools+input_schema。接入五个工具，支持三个模型，你要维护 15 份配置。

痛点一：格式不统一——每家 LLM 的 Function Calling 格式各自为政，工具定义无法复用。

痛点二：工具发现困难——没有标准方式让 AI 动态发现有哪些工具可用，全靠开发者手动维护一份列表。

痛点三：只支持"调用"，不支持"读取"——Function Calling 只有"调用函数"这一种模式，无法优雅地表达"读取一个文件"或"订阅一个数据流"。

1.2 更深的问题：工具和模型的强耦合

传统方式里，工具定义和你用的 LLM 是强绑定的。换个模型，所有工具配置得重写。这意味着：

  • 你没法把同一套工具同时接给 Claude 和 GPT 用
  • 你开发的工具没法分享给别人直接用，因为别人可能用不同的模型
  • 工具生态无法形成——每个人都在重复造轮子

二、MCP 是什么

**MCP（Model Context Protocol）**是 Anthropic 于 2024 年 11 月发布的开放协议，定义了 LLM 与外部工具之间交互的标准格式。

一句话理解：MCP = AI 工具的 USB-C 接口标准

                  ┌─────────────────────┐
                  │    MCP Server（工具） │
                  │  ┌───────────────┐  │
                  │  │  数据库 Server │  │
                  │  │  文件系统 Server│  │  
                  │  │  GitHub Server │  │
                  │  └───────────────┘  │
                  └──────────┬──────────┘
                             │  MCP 协议（JSON-RPC 2.0）
                  ┌──────────┴──────────┐
                  │    MCP Client（AI）  │
                  │  ┌───────────────┐  │
                  │  │ Claude Desktop│  │
                  │  │ 你的 AI 应用  │  │
                  │  │ Cursor / Cline│  │
                  │  └───────────────┘  │
                  └─────────────────────┘

工具（Server）只需实现一次，所有支持 MCP 的 AI 客户端都能用。

2.1 协议的底层：JSON-RPC 2.0

MCP 的传输层基于 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 自主决定 执行操作：写文件、发邮件、调 API
Resources（资源） 只读数据源 宿主应用 提供数据：读文件、查配置、获取上下文
Prompts（提示词） 快捷指令 用户触发 预定义工作流：代码审查模板、报告模板

后面的文章会深入每一个原语，这里先建立整体印象。

三、MCP 的通信模式

3.1 两种传输方式

stdio（标准输入输出）：

  • Client 启动 Server 进程，通过 stdin/stdout 通信
  • 适合本地工具，Claude Desktop 就用这种方式
  • 优点：简单，无需网络；缺点：只能本地使用
Claude Desktop ──stdin──> Python Server 进程
Claude Desktop <──stdout── Python Server 进程

SSE（Server-Sent Events）：

  • Server 是一个 HTTP 服务，Client 通过 HTTP 连接
  • 适合远程部署，团队共享工具
  • 优点：可远程访问、可多用户共享；缺点：需要网络和部署
AI Client ──HTTP POST──> MCP Server（HTTP 服务）
AI Client <──SSE Stream── MCP Server（HTTP 服务）

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 是动态发现工具的，而不是硬编码。你新增一个工具，重启 Server，AI 立刻就能用上，不需要改任何 AI 侧的代码。

四、为什么是现在？MCP 生态的爆发

4.1 平台支持现状（2025年）

MCP 发布仅半年多，支持的工具和平台已经覆盖了主流 AI 开发场景：

类型 代表产品
AI 客户端 Claude Desktop、Cursor、Cline、Continue、Zed
AI 平台 Dify、Flowise、n8n、Langchain
官方 Server Filesystem、GitHub、PostgreSQL、Brave Search、Slack
社区 Server 超过 3000 个开源项目（GitHub topics: mcp-server）

值得注意的是：OpenAI 的 ChatGPT 和 Responses API 也在 2025 年宣布支持 MCP。这意味着 MCP 正在成为 AI 工具集成的事实标准，不再只是 Anthropic 的私有协议。

4.2 为什么生态增长这么快？

三个原因：

1. 开发成本极低。用 Python SDK，10 行代码就能写出一个可用的 MCP Server。你现有的函数，加两行装饰器就变成 AI 可调用的工具。

2. 工具可复用。你写的数据库 MCP Server，同事用 Cursor，你用 Claude Desktop，都能直接用。工具开发一次，全团队受益。

3. 时机刚好。2024-2025 年是 AI Agent 从实验走向实用的关键期。企业开始认真考虑"如何让 AI 对接现有系统"，MCP 正好提供了一个低成本的答案。

4.3 一个有意思的信号

GitHub 上有一个项目叫 Awesome MCP Servers，2024年底只有几十个项目，到 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 Server，AI 按需组合调用，一次对话完成跨系统的信息综合。

六、MCP 的局限性（不能盲目吹）

任何技术都有适用边界，MCP 也不例外。

当前的主要局限：

  1. 高延迟场景慎用。每次工具调用都是一次网络往返（stdio 模式是进程间通信），如果一个任务需要调用几十次工具，延迟会很明显。

  2. 安全边界需要自己维护。MCP 协议本身不包含鉴权机制，安全控制全靠你在 Server 里实现。配置不当的 MCP Server 相当于给 AI 开了一个无限权限的操作入口。（第 8 篇专门讲这个）

  3. 状态管理比较原始。MCP Server 本身是无状态的（每次调用独立），多步骤的有状态工作流需要在上层 Agent 框架里实现。

  4. 调试体验还不完善。相比成熟的 REST API，MCP 的调试工具链还比较初级，出了问题主要靠看日志。

了解局限性，才能在合适的场景用合适的工具。

七、这个专栏讲什么

接下来 14 篇，我们按难度递进：

基础篇（第2-3篇）
├── 搭建第一个 MCP Server（5分钟跑起来）
└── 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/
  • 官方 SDK（Python）：https://github.com/modelcontextprotocol/python-sdk
  • 官方 SDK（TypeScript）：https://github.com/modelcontextprotocol/typescript-sdk
  • Awesome MCP Servers：https://github.com/punkpeye/awesome-mcp-servers
  • Claude Desktop 下载：https://claude.ai/download

专栏订阅：持续更新，建议收藏本系列第一篇，方便导航。

# 人工智能
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

基于深度学习YOLOv12的鱼病害检测系统（YOLOv12+YOLO数据集+UI界面+登录注册界面+Python项目源码+模型）

avatar AtomGit开源社区
cover

OpenClaw exec-approvals 命令执行审批机制深度解析与实践

avatar AtomGit开源社区
cover

基于YOLOv11深度学习的鱼病害检测系统（YOLOv11+YOLO数据集+UI界面+登录注册界面+Python项目源码+模型）

avatar AtomGit开源社区