Skip to main content
你问 Claude “今天北京的天气怎么样”，它说不知道。你问 Cursor “帮我查一下这个 GitHub Issue 的状态”，它也做不到。不是因为模型笨，而是它被关在一个没有窗户的房间里——只能处理你塞进来的文字，无法主动伸手去外部世界拿数据。MCP（Model Context Protocol，模型上下文协议）要解决的就是这个问题：给 AI 装上一套标准化的”手”。

​
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，结构非常干净： 
# 向 MCP Server 查询它支持哪些工具
curl -s -X POST https://your-mcp-server.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}'
# 返回示例：
# {"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，有三种核心原语：
原语作用调用方向
Tools可执行的函数（查天气、写文件、调 API）客户端 → Server
Resources可读取的数据（文档、数据库记录、文件内容）客户端 → Server
Prompts预定义的提示词模板客户端 → Server
MCP Server 声明自己支持的工具，格式如下： 
{
  "jsonrpc": "2.0",
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "获取指定城市的实时天气",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string", "description": "城市名，如北京" }
          },
          "required": ["city"]
        }
      }
    ]
  },
  "id": 1
}
这份工具清单由 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）。 
Host（Claude Desktop）
  ├── Client A ──── MCP Server: 天气查询
  ├── Client B ──── MCP Server: GitHub 操作
  └── Client C ──── MCP Server: 本地文件系统
Host 和 Client 的关系是 1:N——一个 Host 启动多个 Client，每个 Client 对接一个 Server。Server 之间完全隔离，Server A 不知道 Server B 的存在。 查看 Claude Desktop 当前加载的 MCP Server 配置（macOS）： 
# 配置文件里的每一个 entry 对应一个 MCP Server
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

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

你问 Claude “北京今天天气怎么样”，到 Claude 给出答案，中间发生了什么？按顺序走一遍。 ① 你发出问题，Host 把问题送给大模型 大模型收到对话上下文，外加一份”可用工具清单”（由 Client 从 MCP Server 获取并注入到 system prompt 里）。 ② 大模型决定要调用工具 模型输出不是直接回答，而是一个工具调用意图： 
{
  "type": "tool_use",
  "name": "get_weather",
  "input": { "city": "北京" }
}
③ Host 把调用请求转给 Client，Client 发送给 MCP Server 
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "北京" }
  },
  "id": 2
}
④ MCP Server 执行工具，返回结果 
{
  "jsonrpc": "2.0",
  "result": {
    "content": [
      {
        "type": "text",
        "text": "北京今日天气：晴，气温 12°C–22°C，东南风 3 级"
      }
    ]
  },
  "id": 2
}
⑤ 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 是客户端-服务端通信协议，定义的是”工具服务器如何被发现、如何被调用、结果如何返回”的完整标准。
维度Function CallingMCP
层次模型输出格式客户端-服务端协议
标准化范围单家平台内部跨平台通用
解决的问题模型怎么表达意图意图怎么被执行
工具开发者负担每个平台各写一套写一次，全平台通用
两者不是竞争关系，是不同层次的配合： 
用户输入
    ↓
大模型（用 Function Calling / Tool Use 表达工具调用意图）
    ↓
MCP Client（把意图转成 MCP 协议请求）
    ↓
MCP Server（执行工具，返回结果）
    ↓
大模型（把结果整合进回复）
    ↓
用户看到答案
MCP 是 Function Calling 的”执行层标准化”——解决的是工具生态碎片化的问题，不是替代模型的推理能力。 验证一下你的 MCP Server 是否正确响应 initialize 握手（所有客户端接入前都会先发这个）： 
# 替换 URL 和 token 为实际值
curl -s -X POST https://your-mcp-server.com/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-token" \
  -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}},"id":1}' \
  | python3 -m json.tool
# 看到 serverInfo 字段说明 Server 正常运行

​
常见问题

Anthropic 于 2024 年 11 月发布并开源了 MCP。协议规范和 SDK 代码托管在 MCP 官方仓库，目前已有 OpenAI、Google DeepMind 等厂商跟进支持，逐渐成为 AI 工具调用的事实标准。
不是。MCP 是开放协议，任何 AI 应用都可以实现 MCP Client。目前已支持 MCP 的客户端包括 Claude Desktop、Cursor、Zed、Continue、Cline 等。MCP Server 写好之后，对所有这些客户端通用，不需要改代码。
本地和远程都可以。本地 MCP Server 通过 stdio（标准输入输出）与 Client 通信，不需要网络；远程 MCP Server 通过 Streamable HTTP 暴露 HTTPS 端点，可以部署在 VPS 上。两种方式的 MCP 协议层完全一致，只有传输层不同。
JSON-RPC 2.0。所有 MCP 请求和响应都是标准的 JSON-RPC 报文，method 字段对应操作类型（tools/list、tools/call、resources/read 等），params 和 result 字段传递业务数据。
理解了 MCP 的架构和调用流程，下一步是看它在实际工作流里能解决哪些具体问题。MCP 能做什么？10 个真实场景让 Claude / Cursor 变成超级助手里列了 10 个真实场景，每个都有配置代码，可以直接拿来用。 本文最后更新于 2026-03，MCP SDK 版本：1.10.2。MCP 协议迭代较快，建议每 3 个月检查 SDK 版本和客户端配置格式变更。