1. MCP 的范围 #

1.1 包含的内容 #

1.2 不包含的内容 #

• MCP 只负责「上下文交换」的协议——即 AI 怎么从外部系统拿数据、调工具
• 不规定 AI 应用内部如何用 LLM、如何管理上下文

2. 核心角色：谁在和谁通信？ #

2.1 三个关键角色 #

2.2 通俗理解 #

• 主机 = 总指挥（AI 应用）
• 客户端 = 派去和每个服务器对接的「代表」
• 服务器 = 提供具体能力的一方（数据、工具等）

2.3 连接示意 #

要点：一个主机可以连多个服务器；每个服务器对应一个客户端；本地服务器通常只服务一个客户端，远程服务器可服务多个。

3. 两层架构：数据层 + 传输层 #

MCP 由两层组成，可以理解为：

• 数据层（内层）：约定「说什么」——消息格式、请求/响应类型
• 传输层（外层）：约定「怎么传」——连接方式、认证方式

3.1 数据层 #

3.2 传输层 #

4. 核心概念：原语 #

原语 是 MCP 里最重要的概念，指的是「客户端和服务器可以互相提供的内容类型」。

4.1 服务器提供的原语（AI 可用的） #

4.2 客户端提供的原语（服务器可请求的） #

4.3 通用原语 #

• 任务（实验性）：支持长时间运行、延迟返回结果的操作

4.4 原语怎么用？ #

每种原语都有对应的「发现」和「获取」方法，例如：

• tools/list → 列出工具
• tools/call → 调用工具
• resources/list → 列出资源
• resources/read → 读取资源

5. 通知：实时更新 #

服务器可以在不等待请求的情况下，主动通知客户端「有变化了」。

例如：工具列表变了，服务器发 notifications/tools/list_changed，客户端收到后去刷新 tools/list。

好处：客户端不用轮询，就能保持信息最新。

6. 完整示例：从连接到工具调用 #

下面用一个简化流程，演示 MCP 客户端和服务器如何交互。

6.1 步骤 1：初始化（握手） #

客户端发 initialize 请求，双方协商协议版本和能力。

客户端请求示例：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "elicitation": {} },
    "clientInfo": { "name": "example-client", "version": "1.0.0" }
  }
}

服务器响应会包含自己的 capabilities 和 serverInfo。协商成功后，客户端发 notifications/initialized 表示就绪。

关键点：capabilities 用来声明各自支持什么（工具、资源、提示、通知等），避免调用不支持的功能。

6.2 步骤 2：发现工具 #

客户端发 tools/list，服务器返回可用工具列表。

请求：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

响应中包含每个工具的 name、title、description、inputSchema 等，例如计算器、天气查询等。

6.3 步骤 3：调用工具 #

客户端用 tools/call 执行具体工具。

请求示例（查天气）：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

响应中 content 数组里是工具返回的结果（如文本、图片等）。

6.4 步骤 4：收到通知后刷新 #

当服务器工具列表变化时，会发通知：

{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

客户端收到后，可再次发 tools/list 获取最新列表。

7. 在 AI 应用里是怎么跑的？ #

8. 本章小结 #