MCP 协议详解：让 AI 工具调用像 USB 一样即插即用

想象一下：你让 AI 助手帮你查一下明天北京的天气，顺便把会议记录存到 Notion 里，再看看 GitHub 上有没有新的 PR 要处理。AI 很聪明，它知道该怎么做——但问题是，它不知道怎么连接到这些工具。

每个工具都有自己的 API 格式，每个 AI 应用都要单独写一套对接代码。10 个工具就要写 10 套集成，换一个 AI 平台又要重写一遍。这就像早年手机充电器的混乱年代：诺基亚、三星、摩托罗拉，每家一个接口，出门得带一堆线。

MCP（Model Context Protocol，模型上下文协议）就是来解决这个问题的。它由 Anthropic 在 2024 年 11 月发布，目标很简单：给 AI 应用和外部工具之间定一个统一的"接口标准"，就像 USB-C 统一了充电接口一样。

本文将从核心概念、架构原理、通信机制、与 Function Calling 的对比，以及动手实战五个角度，带你彻底搞懂 MCP。

一、MCP 是什么：AI 世界的 USB-C 接口

一句话定义：MCP 是一个开源协议，用来标准化 AI 应用与外部系统之间的连接方式。

在 MCP 出现之前，如果你想让 Claude 能够读取本地文件、查询数据库、调用搜索引擎，你需要为每个工具单独编写集成代码。不同的 AI 平台（OpenAI、Anthropic、Google）各有各的工具调用格式，工具提供方也得为每个平台做适配。

这种 M x N 的集成模式（M 个 AI 应用 x N 个工具）效率极低。MCP 把它变成了 M + N：AI 应用只要支持 MCP 协议，就能连接任何 MCP Server；工具只要暴露为 MCP Server，就能被任何支持 MCP 的 AI 应用使用。

MCP 将 M x N 的集成模式简化为 M + N

一句话理解

MCP 就是 AI 应用的「万能充电线」——不管什么工具，插上就能用，不用再为每个设备买一根专用线。

截至 2026 年 3 月，MCP 已经捐赠给了 Linux 基金会下的 Agentic AI Foundation（AAIF），由 Anthropic、OpenAI、Block 等公司联合治理。MCP Registry 上已有超过 10,000 个公开的 MCP Server，覆盖文件系统、数据库、Slack、GitHub、Sentry 等主流工具。

二、核心架构：Host、Client、Server

MCP 的架构很清晰，就三个角色：Host、Client、Server。用一个生活中的类比就能理解。

想象你去一家餐厅吃饭：

你（Host）：就是 AI 应用本身，比如 Claude Desktop、VS Code、Cursor。你是发起需求的人。
服务员（Client）：Host 内部为每个工具创建一个专属 Client，负责和对应的厨房沟通。你点了三道菜，就有三个服务员分别对接三个后厨。
厨房（Server）：就是具体的工具或数据源。一个做文件操作，一个做数据库查询，一个连接 GitHub。

MCP Host-Client-Server 架构：每个 Client 与 Server 保持 1:1 专属连接

关键设计：每个 Client 和 Server 是 1:1 的关系。Host 连接了 5 个 MCP Server，就会创建 5 个 Client 实例。这种设计让每个连接独立管理，互不干扰。

本地 vs 远程

MCP Server 可以跑在本地（比如文件系统 Server，用 stdio 通信），也可以跑在远程（比如 Sentry 的 MCP Server，用 HTTP 通信）。「Server」这个词指的是提供服务的程序，不是指物理位置。

举个具体例子：当你在 VS Code 中使用 Copilot，并配置了 Sentry MCP Server 和本地文件系统 Server，VS Code 作为 Host 会创建两个 Client——一个连接 Sentry（远程），一个连接文件系统（本地）。

三、三大基本能力：Tools、Resources、Prompts

MCP Server 能提供三种类型的能力，官方叫 Primitives（基本原语）。你可以把一个 MCP Server 想象成一把瑞士军刀——它不只有一种用途，而是组合了多种功能。

Tools：让 AI 能「动手」

Tool 就是 AI 可以调用的函数。比如「发送一封邮件」、「查询数据库」、「创建一个 GitHub Issue」。AI 模型决定什么时候调用、传什么参数，MCP Server 负责执行并返回结果。

Resources：让 AI 能「看到」

Resource 是数据源，提供上下文信息给 AI。比如文件内容、数据库 Schema、API 文档。和 Tool 的区别是：Resource 是「读」，Tool 是「做」。

Prompts：让 AI 知道「怎么问」

Prompt 是预制的交互模板，帮助用户更好地使用 MCP Server。比如一个数据库 Server 可以提供一个 Prompt 模板，教 AI 如何用最优的方式查询数据。

Primitive	类比	谁控制调用	典型场景
Tools	瑞士军刀的各种工具	AI 模型决定	API 调用、文件操作、数据库写入
Resources	参考书和字典	应用程序决定	文件内容、数据库记录、配置信息
Prompts	考试的答题模板	用户选择	SQL 查询模板、代码审查提示词

每种 Primitive 都有统一的发现机制。Client 通过 tools/list、resources/list、prompts/list 请求来发现 Server 提供了哪些能力，然后按需调用。这种「先发现、再使用」的模式让整个系统非常灵活——Server 可以动态增减能力，Client 能实时感知变化。

一句话记住

Tools 让 AI 动手做事，Resources 让 AI 获取信息，Prompts 让 AI 知道最佳做法。一个好的 MCP Server 通常会组合使用这三种能力。

四、通信机制：JSON-RPC 与 Transport

MCP 的通信分为两层，就像寄快递：包裹里装什么（数据层）和怎么运过去（传输层）是两回事。

数据层：JSON-RPC 2.0

MCP 使用 JSON-RPC 2.0 作为消息格式。不管底层用什么传输方式，消息长得都一样。一个典型的工具调用请求长这样：

// Client 请求调用天气工具
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "Beijing",
      "units": "metric"
    }
  }
}

// Server 返回结果
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "北京当前天气：22°C，晴，东北风 3 级"
      }
    ]
  }
}

数据层还负责生命周期管理：连接建立时，Client 和 Server 会做一次「握手」，互相告知自己支持哪些能力（Capabilities Negotiation）。这样双方都知道对方能做什么、不能做什么，避免调用不存在的功能。

传输层：两种方式

传输方式	适用场景	特点
Stdio（标准输入输出）	本地 Server	零网络开销，进程间直接通信
Streamable HTTP	远程 Server	支持 SSE 流式传输，支持 OAuth 2.1 认证

换句话说，如果 MCP Server 跑在你的电脑上（比如文件系统），用 Stdio 最快；如果 Server 在云端（比如 Sentry），就走 HTTP。传输方式的切换对上层数据层完全透明，同样的 JSON-RPC 消息格式，换个「运输方式」就行。

2026 年 3 月更新

最新版本的 MCP 协议新增了 OAuth 2.1 认证、Streamable HTTP 传输、JSON-RPC 批处理和工具注解（Tool Annotations）等功能，进一步增强了企业级应用能力。

五、MCP vs Function Calling：到底该用哪个？

这是被问得最多的问题。很多人第一次听到 MCP 都会想：「这不就是 Function Calling 换了个名字吗？」

其实它们解决的是不同层次的问题。打个比方：Function Calling 是手机里「内置的计算器和闹钟」，MCP 是「App Store」。

维度	Function Calling	MCP
定义	LLM 生成结构化的函数调用指令	标准化的工具发现、连接和执行协议
作用域	单次 API 请求内	持久连接，跨请求复用
工具注册	每次请求都要传完整的工具定义	连接时一次发现，动态更新
厂商绑定	各家格式不同（OpenAI / Claude / Gemini）	统一标准，厂商无关
复用性	工具定义与应用代码耦合	MCP Server 独立部署，多应用共享

常见误区

MCP 不是 Function Calling 的替代品——它们是互补的。Function Calling 是 LLM「决定调用什么」的能力，MCP 是「怎么找到工具、怎么连接、怎么执行」的标准。实际工作中，AI 应用通过 MCP 发现可用工具，LLM 通过 Function Calling 决定调用哪个。

什么时候用 Function Calling 就够了？你的应用只需要 2-3 个简单工具，而且不需要跨应用共享——比如一个内部小工具。

什么时候该用 MCP？你需要接入多个外部服务、想让工具能被多个 AI 应用复用、或者在构建生产级的 Agent 系统——MCP 的初始复杂度会在规模化时得到回报。

六、动手写一个 MCP Server

说了这么多概念，来点代码。下面用 Python 写一个最简单的 MCP Server，提供一个「打招呼」工具：

# hello_server.py
from mcp.server.fastmcp import FastMCP

# 创建 MCP Server 实例
mcp = FastMCP("hello-server")

# 用装饰器注册一个 Tool
@mcp.tool()
def greet(name: str) -> str:
    """向指定的人打招呼"""
    return f"你好，{name}！欢迎体验 MCP 协议。"

# 用装饰器注册一个 Resource
@mcp.resource("greeting://guide")
def greeting_guide() -> str:
    """提供打招呼的使用指南"""
    return "本 Server 提供 greet 工具，传入名字即可获得问候。"

# 启动 Server
if __name__ == "__main__":
    mcp.run()

就这么简单——@mcp.tool() 装饰器会自动将函数的参数类型和文档字符串转化为 MCP 的工具定义（包括 inputSchema）。运行这个脚本，它就是一个通过 Stdio 通信的本地 MCP Server。

要在 Claude Desktop 中使用，只需在配置文件中添加：

{
  "mcpServers": {
    "hello": {
      "command": "python",
      "args": ["hello_server.py"]
    }
  }
}

调试技巧

开发 MCP Server 时，可以用官方的 MCP Inspector 来测试——它是一个 GUI 工具，不需要接入 LLM 就能验证 Server 的 Tool、Resource、Prompt 是否正常工作。

七、总结与展望

回顾一下本文的核心要点：

MCP 是什么：AI 应用与外部工具的统一连接协议，把 M x N 的集成变成 M + N
三层架构：Host（AI 应用）创建 Client，Client 1:1 连接 Server，职责清晰
三大能力：Tools（执行操作）、Resources（提供数据）、Prompts（交互模板）
双层通信：JSON-RPC 数据层 + Stdio/HTTP 传输层，关注点分离
与 Function Calling 互补：MCP 负责「连接和发现」，Function Calling 负责「决策和调用」

我的看法：MCP 最大的价值不在于技术本身有多复杂——恰恰相反，它的设计很简洁。它的价值在于网络效应：当越来越多的工具提供 MCP Server、越来越多的 AI 应用支持 MCP Client，整个生态就会形成飞轮。2025 年底 MCP 捐赠给 Linux 基金会、OpenAI 等公司加入共建，这个信号很明确——MCP 正在从 Anthropic 的单家协议变成行业标准。

下一步建议：

试一试：用 pip install mcp 安装 Python SDK，花 10 分钟写一个 MCP Server，在 Claude Desktop 或 VS Code 中体验一下
逛一逛：去 modelcontextprotocol.io 看看官方文档和 Server 目录，找找有没有你日常用的工具已经有了 MCP Server

好的协议不是让你学新东西，而是让你不用再学那么多东西。MCP 正在做的，就是这件事。

MCP 协议详解：让 AI 工具调用像 USB 一样即插即用

一、MCP 是什么：AI 世界的 USB-C 接口

二、核心架构：Host、Client、Server

三、三大基本能力：Tools、Resources、Prompts

Tools：让 AI 能「动手」

Resources：让 AI 能「看到」

Prompts：让 AI 知道「怎么问」

四、通信机制：JSON-RPC 与 Transport

数据层：JSON-RPC 2.0

传输层：两种方式

五、MCP vs Function Calling：到底该用哪个？

六、动手写一个 MCP Server

七、总结与展望

参考资料