MCP 是什么？用一个类比彻底讲清楚模型上下文协议

AI 不知道今天的天气，根本原因在哪里#

大语言模型本质上是一个函数：输入一段文本，输出一段文本。训练数据在某个时间点截止，之后发生的事情它一概不知。

这个设计本身没有问题，问题在于：如果我想让 AI 能查天气、能读数据库、能调用外部 API，该怎么做？

MCP 出现之前，每家 AI 应用自己解决这个问题：OpenAI 搞了 Function Calling，Anthropic 有 Tool Use，各家实现方式不同，数据格式不统一。你给 Claude 写了一个读取 GitHub 仓库的工具，换到 GPT-4 就得重写一遍。工具开发者被迫为每个 AI 平台各写一套对接代码。

类比一下：这就像每家电器厂商都设计自己的充电接口——苹果用 Lightning，三星用 USB-C，充电器带一个不够，出门要带三个。MCP 要做的，是定义一套 USB-C 标准，让所有 AI 应用和所有工具服务器都说同一种语言。

用 curl 看看 MCP 协议的真实长相——它底层是 JSON-RPC 2.0，结构非常干净：

1
# 向 MCP Server 查询它支持哪些工具
2
curl -s -X POST https://your-mcp-server.com/mcp \
3
  -H "Content-Type: application/json" \
4
  -d '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}'
5
# 返回示例：
6
# {"jsonrpc":"2.0","result":{"tools":[{"name":"get_weather","description":"获取城市天气",...}]},"id":1}

MCP 解决了什么——从”每次定制”到”一次接入”#

MCP 全称 Model Context Protocol，由 Anthropic 在 2024 年 11 月开源。核心思路是：定义一套统一协议，工具开发者只需要实现一次 MCP Server，所有支持 MCP 的 AI 客户端都能直接用。

类比更准确的版本：MCP 不只是 USB-C 接口（物理形状），它还规定了”插上去之后发生什么”——设备怎么自我介绍、怎么声明支持哪些操作、怎么传输数据、怎么报错。

实际效果：你写一个能查天气的 MCP Server，Claude Desktop 能用，Cursor 也能用，以后任何支持 MCP 的客户端都能用，不需要改一行 Server 代码。

MCP 协议基于 JSON-RPC 2.0，有三种核心原语：

MCP Server 声明自己支持的工具，格式如下：

1
{
2
  "jsonrpc": "2.0",
3
  "result": {
4
    "tools": [
5
      {
6
        "name": "get_weather",
7
        "description": "获取指定城市的实时天气",
8
        "inputSchema": {
9
          "type": "object",
10
          "properties": {
11
            "city": { "type": "string", "description": "城市名，如北京" }
12
          },
13
          "required": ["city"]
14
        }
15
      }
16
    ]
17
  },
18
  "id": 1
19
}

这份工具清单由 Client 在连接时拉取，注入到大模型的上下文里，模型才知道自己”有哪些手可以用”。

三层架构：Host / Client / Server 各自干什么#

MCP 定义了三个角色，理清这三层，协议就懂了一半。

Host：用户直接交互的应用程序。Claude Desktop、Cursor、Zed 都是 Host。Host 负责发起连接、管理会话、把 AI 的工具调用意图转发给 Client 执行。

Client：Host 内部的组件，专门负责和 MCP Server 通信。一个 Host 可以同时维持多个 Client 连接，对应多个不同的 Server。

Server：暴露工具、资源、提示词的轻量服务。可以是本地进程（通过 stdio 通信），也可以是远程 HTTP 服务（通过 Streamable HTTP）。

1
Host（Claude Desktop）
2
  ├── Client A ──── MCP Server: 天气查询
3
  ├── Client B ──── MCP Server: GitHub 操作
4
  └── Client C ──── MCP Server: 本地文件系统

Host 和 Client 的关系是 1——一个 Host 启动多个 Client，每个 Client 对接一个 Server。Server 之间完全隔离，Server A 不知道 Server B 的存在。

查看 Claude Desktop 当前加载的 MCP Server 配置（macOS）：

1
# 配置文件里的每一个 entry 对应一个 MCP Server
2
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

一次工具调用的完整流程（含 JSON-RPC 报文）#

你问 Claude “北京今天天气怎么样”，到 Claude 给出答案，中间发生了什么？按顺序走一遍。

① 你发出问题，Host 把问题送给大模型

大模型收到对话上下文，外加一份”可用工具清单”（由 Client 从 MCP Server 获取并注入到 system prompt 里）。

② 大模型决定要调用工具

模型输出不是直接回答，而是一个工具调用意图：

1
{
2
  "type": "tool_use",
3
  "name": "get_weather",
4
  "input": { "city": "北京" }
5
}

③ Host 把调用请求转给 Client，Client 发送给 MCP Server

1
{
2
  "jsonrpc": "2.0",
3
  "method": "tools/call",
4
  "params": {
5
    "name": "get_weather",
6
    "arguments": { "city": "北京" }
7
  },
8
  "id": 2
9
}

④ MCP Server 执行工具，返回结果

1
{
2
  "jsonrpc": "2.0",
3
  "result": {
4
    "content": [
5
      {
6
        "type": "text",
7
        "text": "北京今日天气：晴，气温 12°C–22°C，东南风 3 级"
8
      }
9
    ]
10
  },
11
  "id": 2
12
}

⑤ Host 把工具结果注入对话上下文，再次送给大模型

模型读取天气数据，生成最终回复：“北京今天晴天，气温 12 到 22 度，东南风 3 级，适合出门。”

整个流程，用户看到的只有问题和答案，中间的 JSON-RPC 往返在后台完成。关键点：模型本身没有”联网”，工具的实际执行在 MCP Server 里，模型只负责决策要不要调用、调哪个、传什么参数。

MCP vs Function Calling：为什么需要一个专门的协议#

Function Calling 和 MCP 解决的问题有重叠，但层次不同。

Function Calling 是 AI 模型层面的能力：模型在输出中声明”我要调用这个函数，参数是这些”。具体怎么调、谁来执行、结果怎么传回来，Function Calling 不管。每个 AI 平台的格式都不一样，工具开发者需要为 OpenAI、Anthropic、Gemini 各写一套。

MCP 是客户端-服务端通信协议，定义的是”工具服务器如何被发现、如何被调用、结果如何返回”的完整标准。

两者不是竞争关系，是不同层次的配合：

1
用户输入
2
    ↓
3
大模型（用 Function Calling / Tool Use 表达工具调用意图）
4
    ↓
5
MCP Client（把意图转成 MCP 协议请求）
6
    ↓
7
MCP Server（执行工具，返回结果）
8
    ↓
9
大模型（把结果整合进回复）
10
    ↓
11
用户看到答案

MCP 是 Function Calling 的”执行层标准化”——解决的是工具生态碎片化的问题，不是替代模型的推理能力。

验证一下你的 MCP Server 是否正确响应 initialize 握手（所有客户端接入前都会先发这个）：

1
# 替换 URL 和 token 为实际值
2
curl -s -X POST https://your-mcp-server.com/mcp \
3
  -H "Content-Type: application/json" \
4
  -H "Authorization: Bearer your-token" \
5
  -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}},"id":1}' \
6
  | python3 -m json.tool
7
# 看到 serverInfo 字段说明 Server 正常运行

常见问题#