快速上手：Anthropic MCP 协议规范

本文整理了MCP的基本协议规范，包括协议架构、协议基本消息类型、协议生命周期管理、协议的传输层

1. 协议之架构

1.1 基本组件

1.2 基本消息类型

1.3 能力协商

2. 协议规范之基本消息类型

2.1 Requests（消息请求）

2.2 Responses（消息应答）

2.3 Notifications（通知）

2.4 举例：Client获取Server Tool列表

3. 协议规范之生命周期管理

3.1 Initialization（初始化）：

3.2 Operation（操作）

3.3 Shutdown（关闭）

4. 协议规范之传输层

5. 参考

整个规范，可以分几个大块来了解：协议架构、协议基本消息类型、协议生命周期管理、协议的传输层

1. 协议之架构

Model Context Protocol (MCP) 采用 client-host-server 架构，每个 host 可以运行多个client实例。

这种架构使用户能够在各个应用程序中集成人工智能能力，同时保持清晰的安全边界并隔离关注点。

MCP 基于 JSON-RPC 构建，提供了一种有状态的会话协议，专注于上下文交换和 clients 与servers之间的采样协调。

JSON-RPC 2.0 规范: ​​​https://www.jsonrpc.org/specification​​

1.1 基本组件

Host

Host进程充当容器和协调者（比如Cline，cursor等）：

• 创建和管理多个客户端实例
• 控制客户端连接权限和生命周期
• 协调 AI/LLM 集成和采样
• 管理Clients之间的上下文聚合

Clients

每个客户端由Host创建，并保持一个独立的 server 连接（比如由Cline代码内嵌的SDK Client）：

• 和每个 server 建立一个有状态的会话
• 处理协议协商和能力交换
• 双向路由协议消息
• 管理订阅和通知
• 维护 servers 之间的安全边界

host 应用程序创建并管理多个 clients，每个 client 与特定 server 之间具有一对一的关系。

Servers

server 提供专业的上下文和能力：

• 通过 MCP 原语暴露resources、tools 和prompts
• 通过client 提供的接口请求sampling
• 可以是本地进程或远程服务

1.2 基本消息类型

MCP 定义了基于 JSON-RPC 2.0 的三种核心消息类型：

• Requests: 双向消息，带有方法和参数，期望有响应
• Responses: 匹配特定请求 ID 的成功结果或错误
• Notifications: 无需回复的单向消息

1.3 能力协商

Model Context Protocol 使用了一种基于能力（capability-based）的协商机制，在初始化阶段，clients和servers会明确声明它们支持的功能，而这些能力决定了在会话期间可以使用哪些协议特性和原语（primitives）

2. 协议规范之基本消息类型

所有在 MCP clients 和 servers 之间的消息必须遵循 JSON-RPC 2.0 规范。该协议定义了三种基本类型的消息：

2.1 Requests（消息请求）

​​Requests​​可以从Client端或者Server端发起

格式要求：

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
1.
2.
3.
4.
5.
6.
7.
8.

• 请求必须包含一个字符串或整数类型的 ID。
• ID 不能为​​null​​ 。
• 请求 ID 在同一会话中不得被请求者之前使用过。

2.1.1 Requests的关键业务类型：

2.2 Responses（消息应答）

​​Responses​​是对requests的回复。

格式要求：

{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

• Responses 必须包含与其对应 request 相同的 ID。
• 必须设置​​result​​ 或​​error​​ 之一。不得同时出现。
• 错误代码必须是整数。

2.3 Notifications（通知）

​​Notifications​​是从client 发送到server 或反向发送的。不需要回复。

格式要求：

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}
1.
2.
3.
4.
5.
6.
7.

通知不得包含 ID。

2.4 举例：Client获取Server Tool列表

要查询可用的工具，Client发送一个 ​​tools/list​​ 请求

Request（请求）

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}
1.
2.
3.
4.
5.
6.
7.
8.

Response（响应）

{
  "jsonrpc": "2.0",
"id": 1,
"result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

3. 协议规范之生命周期管理

MCP定义了client-server连接的严格生命周期，确保了能力协商和状态管理。

1. Initialization（初始化）: 能力协商和协议版本一致
2. Operation（操作）: 正常的协议通信
3. Shutdown（关闭）: 连接的优雅关闭

3.1 Initialization（初始化）：

初始化阶段必须是 client 和 server 之间的第一次交互。在此阶段，client 和 server确定协议版本兼容性、交换和协商各自的能力、分享实施细节。

由client 发送一个包含 ​​initialize​​ 请求来启动此阶段，包含：

• 支持的协议版本
• Client 能力
• Client 信息

{
  "jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

server 必须响应其自身的能力和信息：

{
  "jsonrpc": "2.0",
"id": 1,
"result": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "version": "1.0.0"
    }
  }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.

成功初始化后，client 必须发送一个 ​​initialized​​ 通知以表明它已准备好开始正常操作：

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}
1.
2.
3.
4.

3.1.1 版本协商

在 ​​initialize​​ 请求中，client 必须发送其支持的协议版本。这应该是client 支持的最新版本。

如果server支持请求的协议版本，则必须以相同的版本进行响应。否则，server必须以其支持的其他协议版本进行响应。这应该是server支持的最新版本。

如果client 不支持server响应中的版本，则应该断开连接。

3.1.2 能力协商

client 和server 在会话期间将提供哪些可选的协议功能。

关键能力包括：

3.2 Operation（操作）

在操作阶段，client 和 server 根据协商的能力交换消息。

遵守协商的协议版本

仅使用成功协商的能力

3.3 Shutdown（关闭）

在关闭阶段，连接被优雅地终止。

client 发送断开连接通知

server 关闭连接

清理相关资源

4. 协议规范之传输层

MCP 目前定义了两种标准的 client-server通信传输机制：stdio（标准输入输出）和基于 SSE 的 HTTP。客户端应尽可能支持 stdio。

此外，客户端和服务器也可以以可插拔的方式实现自定义传输机制。

5. 参考

​​https://spec.modelcontextprotocol.io/specification/2024-11-05/​​

本文转载自​​AI取经路​​，作者：AI取经路