MCP协议详解：AI世界的USB接口

摘要： 一文讲透MCP协议的设计哲学、架构原理、消息格式和通信机制，帮助你理解AI如何调用外部工具。

---

为什么需要MCP

大模型本质上是个"文本处理器"------它很聪明，但什么都干不了。查数据库、调API、读文件、发邮件，这些事AI原生做不到。

在MCP之前，各家AI各搞一套：GPT-4用Function Calling，Claude用Tool Use，Gemini用Function Declarations。你写一个工具想给三个模型用，得写三遍，换一个模型就得重写一次。开发者苦不堪言。

MCP的解法很简单：定义一套统一的标准接口，写一次MCP Server，所有支持MCP的AI客户端都能调用。

---

设计哲学

MCP要解决的是"AI集成悖论"------如何让AI系统安全、丰富地访问外部资源，又不制造安全噩梦和集成复杂度。

传统API是为可预测的人类设计的工作流准备的。AI系统需要的东西完全不同：

• 动态资源发现

  ------ AI不知道需要什么，直到它需要的那一刻

• 丰富的上下文交换

  ------ 不只是数据，还有元数据、关系、能力声明

• 安全沙箱

  ------ AI不能被信任拥有直接系统访问权限

• 双向通信

  ------ AI需要提问，不只是消费数据 MCP的架构回应了这些需求：Host 作为安全中介，Client-Server 隔离通信，能力协商机制，传输无关设计。

---

核心架构：三个角色

• Host

  ：宿主程序，用户直接用的东西，比如 Claude Desktop、Cursor、VS Code Copilot。Host 作为安全中介，所有 AI-资源 交互都必须经过它。

• Client

  ：协议适配层，在 Host 内部，负责跟 Server 通信。每个资源类型有独立的、隔离的通信通道。

• Server

  ：你写的工具，暴露具体能力（查数据库、调API、读文件）。 一个 Host 可以同时连多个 Server，互不干扰。

---

三种能力原语

MCP Server 能提供三种东西：

Tools（工具）

AI 可以调用的函数，最常用。比如 get_weather、execute_query、send_email。每个 Tool 有名称、描述和参数 Schema，AI 靠描述判断何时调用。

Resources（资源）

AI 可以读取的数据源，类似文件或数据库记录。通过 URI 访问，比如 file:///home/user/doc.txt、db://users/1。

Prompts（提示模板）

预设的提示模板，像"存储过程"，确保 AI 每次用相同的语气和结构。比如一个"代码审查"模板，AI 每次审查代码都按同一套标准来。

---

通信方式

STDIO（标准输入输出）

Host 把 Server 当子进程启动，通过标准输入输出传递 JSON-RPC 消息。每行一个 JSON 对象。

适合本地进程，最简单，零网络配置。Claude Desktop 本地 Server 的首选方式。

Streamable HTTP

基于 HTTP 请求/响应的传输方式，取代了旧版 SSE（Server-Sent Events）。

适合部署到服务器上让多个客户端远程访问。2025年3月后的规范推荐使用 HTTP 替代 SSE。

传输层换掉，协议层的代码不需要改。SDK 已经帮你封装好了。

---

协议层：JSON-RPC 2.0

MCP 的所有消息必须遵循 JSON-RPC 2.0 规范。

三种消息类型

请求（Request） ------ 需要对方回复

{

  "jsonrpc": "2.0",

  "id": 1,

  "method": "tools/call",

  "params": {

    "name": "get_user_summary",

    "arguments": { "user_id": 1 }

  }

}

• ID 不能为 null，且在同一会话中不能重复使用

• method 是方法名，params 是参数 响应（Response） ------ 回复请求

// 成功

{

  "jsonrpc": "2.0",

  "id": 1,

  "result": {

    "content": [

      { "type": "text", "text": "用户: 张三，订单数: 2" }

    ]

  }

}


// 失败

{

  "jsonrpc": "2.0",

  "id": 1,

  "error": {

    "code": -32603,

    "message": "Internal error"

  }

}

• 必须携带与请求相同的 ID

• result

  和 error 二选一，不能同时出现 通知（Notification） ------ 单向消息，不期望回复

{

  "jsonrpc": "2.0",

  "method": "notifications/initialized"

}

• 不能包含 ID

标准错误码

|

错误码

|

含义

|

| --- | --- |

|

-32700

|

Parse Error（解析错误）

|

|

-32600

|

Invalid Request（无效请求）

|

|

-32601

|

Method Not Found（方法未找到）

|

|

-32602

|

Invalid Params（无效参数）

|

|

-32603

|

Internal Error（内部错误）

|

自定义错误码需在 -32000 以下。

---

连接生命周期

1. 初始化

1. Client 发送 initialize 请求，带上协议版本和自身能力声明

2. Server 回复自己的版本和能力

3. Client 发送 notifications/initialized 确认

4. 正常消息交换开始

2. 消息交换

支持两种模式：

• 请求-响应

  ：Client 或 Server 发送请求，对方回复

• 通知

  ：任一方发送单向消息

3. 终止

任一方调用 close()、传输层断开、或出错时结束。

---

核心方法一览

|

方法

|

方向

|

说明

|

| --- | --- | --- |

| initialize |

C → S

|

初始化连接，交换版本和能力

|

| notifications/initialized |

C → S

|

初始化确认

|

| tools/list |

C → S

|

获取 Server 提供的工具列表

|

| tools/call |

C → S

|

调用指定工具，传入参数

|

| resources/list |

C → S

|

获取资源列表

|

| resources/read |

C → S

|

读取指定资源

|

| prompts/list |

C → S

|

获取提示模板列表

|

| prompts/get |

C → S

|

获取指定提示模板

|

---

能力协商

初始化时，Client 和 Server 会交换各自的能力声明（capabilities）。比如：

• Server 声明自己支持 tools 和 resources

• Client 声明自己支持 sampling（让 Server 可以请求 AI 生成内容） 双方只使用对方声明支持的能力，避免调用不存在的方法。

---

为什么 MCP 正在变成标准

• OpenAI、Google、微软

  都已接入或正在接入 MCP

• Cursor、VS Code Copilot、JetBrains AI Assistant

  等主流 IDE 原生支持

• 一个 MCP Server 写好后，Claude、GPT-4、Gemini 都能用

• 不锁定在某一家，你的投入不会被浪费