大模型是如何使用MCP工具的？-从MCP协议核心架构到传输协议（一万七千字通俗详解版）

大模型是如何使用MCP工具的？-从MCP协议核心架构到传输协议（一万七千字通俗详解版）

---

一、MCP的核心架构是什么样？

1.1 架构通俗解读

MCP（Message Communication Protocol）协议的架构，本质是上个C/S架构，在这个基础上Anthropic公司引入主机（Host） 这个概念，来负责规划调度任务。MCP协议架构就像一个"分工明确的团队"，每个人各司其职，协作完成一项大任务。它采用了主机（Host）- 客户端（Client）- 服务器（Server） 三层结构。我们可以把它想象成一个"指挥官-中间人-工人"的团队：

主机（Host）——“指挥官”

• 是什么？ 主机就是整个系统的大脑，一般是接入大模型的客户端，比如你用的 Claude 桌面客户端、Cursor 编辑器等。

• 主要职责：

  1. 创建和管理多个客户端实例，调度资源。
  2. 控制客户端连接权限和生命周期，执行安全政策和同意要求。
  3. 处理用户授权决策，协调AI/大模型集成和采样。
  4. 管理跨客户端的上下文聚合，保证数据安全和隐私。
  5. 作为整个系统的"大脑"，负责复杂的编排和调度。

• 举例： 你在 Claude 里输入"帮我查下天气"，主机就会决定需要哪个工具（比如天气查询），然后让客户端去找服务器要数据。

客户端（Client）——“中间人”

• 是什么？ 客户端是主机派出去的"中间人"，一般为主机内的一个业务进程，用于与服务器通信，每个客户端只和一个服务器打交道。

• 主要职责：

  1. 为每个服务器建立一个有状态的会话，保证1:1安全隔离。
  2. 处理协议协商和能力交换，路由协议消息双向传输。
  3. 管理订阅和通知，维护服务器之间的安全边界。
  4. 作为主机和服务器之间的桥梁，确保消息准确传递。
  5. 只与一个服务器通信，保证安全和隔离。

• 举例： 主机有两个任务：查天气、规划路线。它会派出两个客户端，一个去找天气服务器，一个去找地图服务器。

服务器（Server）——“工人”

• 是什么？ 服务器是实际干活的"工人"，一般在主机外运行的，用于提供特定资源和能力的外部程序。可以是本地的，也可以是远程的。
• 主要职责：
  1. 独立于主机运行，专注于实现特定且明确的能力（如查天气、查地图等）。
  2. 通过 MCP 协议提供资源、工具和提示词。
  3. 独立运作，承担明确责任，必须遵守安全限制。
  4. 可以是本地进程，也可以是远程服务。
  5. 只接收必要的上下文信息，不读取完整对话历史。
• 举例： 天气服务器只管查天气，地图服务器只管查地图，互不干扰。

架构图示意

[主机 Host]
   ├─ [客户端 Client 1] ── [服务器 Server 1]
   ├─ [客户端 Client 2] ── [服务器 Server 2]
   └─ ...

• 主机可以有很多客户端，每个客户端只和一个服务器通信。
• 服务器可以是本地的，也可以是远程的。

MCP 架构的最大优点是：分工明确、灵活组合、安全可靠、易于扩展。
你可以像拼积木一样，随时加减不同的"工人"（服务器），而且每个"工人"都只做自己最擅长的事，主机负责整体调度和安全。

1.2 主机-客户端-服务器的协作流程

那么这个架构是怎么样是怎么运作的呢？

拿我常用的编程工具Cursor举例

假如你用 Cursor 这个 AI 助手，想让它根据数据库查询的信息修改前端代码：

1. 主机（Cursor）读取MCP服务配置时，发现有"mysql数据库查询"和"获取浏览器信息"。

{
   
  "mcpServers": {
   
    "mysql": {
   
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@f4ww4z/mcp-mysql-server",
        "--config",
        "\"{\\\"mysqlHost\\\":\\\"localhost\\\",\\\"mysqlUser\\\":\\\"root\\\",\\\"mysqlDatabase\\\":\\\"database\\\",\\\"mysqlPassword\\\":\\\"1\\\"}\""
      ]
    },
    "browser-tools-mcp": {
   
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@agentdeskai/browser-tools-mcp@latest"
        
      ]
    }
  }
}

2. 主机在启动时或用户点击启用时，主机启动两个业务进程，分别派出两个客户端，和这两个服务器建立连接。
   

3. 你输入需求后，主机决定需要用到数据库查询和获取浏览器信息两个服务。

4. 在得到你的授权之后，客户端分别去找各自的服务器要数据。
   

5. 服务器返回结果，主机整合后给你一个完整的答案。
   

以上就是一次完整MCP服务调用。

---

二、MCP的生命周期是怎么样？

通过前面的介绍，我们已经知道MCP协议的本质是让主机、客户端和服务器像团队一样分工协作，安全高效地完成任务。主机负责调度，客户端负责沟通，服务器负责干活。
然后我们通过cursor运行mysql查询数据库工具的例子简要聊了聊这个架构的协作过程，接下来我们试着将这个过程按照MCP 协议的定义划分成生命周期的三个阶段。

2.1 MCP通信生命周期三阶段

在划分生命周期之前我们先来总结一下这个主机、客户端和服务器架构的协作流程：

1. 读取服务器配置文件：主机启动时，读取配置文件，发现所有可用服务器。
2. 启动本地服务器进程：主机根据配置（command + args + env）在本地电脑运行服务器，每个服务器启动一个本地进程，等待客户端连接。
3. 启动客户端进程：主机启动多个子进程作为客户端，分别连接到各自的服务器。客户端与服务器之间交换数据，保持通信连接。
4. 获取工具集合：主机维护多个客户端与服务器的1:1配对连接，连接建立后获取所有服务器提供的工具（Tool）集合。
5. 处理用户请求：主机接收到用户输入，向大模型发送请求，并将所有服务器的工具集合传递给大模型，由大模型进行意图识别和调度规划，决定调用哪些工具。
6. 并行执行多个工具调用：主机根据大模型返回的工具名称和参数，定位到对应的客户端和服务器组合，由客户端进程向服务器进程发送工具调用（CallTool）请求，得到服务器响应数据。
7. 生成回复：主机整合所有服务器返回的内容，拼接对话上下文，请求大模型做总结输出。
8. 程序退出流程：主机退出时，所有客户端子进程结束，与服务器的连接关闭，服务器进程也随之结束。

---

根据MCP 协议定义了严格的三阶段生命周期，确保客户端与服务器之间的高效、可靠交互。

• 初始化阶段：客户端与服务器进行协议版本协商和能力协商，读取服务器配置文件，启动本地服务器进程，启动客户端进程都属于这个阶段，再客户端与服务器初始化时会进行版本协商和能力协商。

• 操作阶段：客户端与服务器按照协议正常通信，交换消息，获取工具集合， 处理用户请求，并行执行多个工具调用，生成回复都处于这个阶段。

• 关闭阶段：客户端与服务器各自优雅的终止连接， 程序退出流程。

---

2.2 MCP生命周期的“三次握手”

MCP生命周期的三个阶段与TCP的"三次握手"非常相似：

1. 初始化阶段（像加微信好友打招呼）

• 目的：双方先确认能不能"聊得来"，能聊什么。
• 过程：
  1. 客户端（你）先发起请求，告诉服务器（对方）：“我是谁，我会说什么’语言’（协议版本），我能做什么（能力）。”
  2. 服务器收到后回复：“我也会说这些’语言’，我能做这些事。”
  3. 双方确认没问题后，客户端再发个通知：“我准备好了，可以开始聊天了！”
• 细节：
  • 如果双方"说的语言"不一样（版本不兼容），就不能继续聊，必须断开。
  • 能力协商：双方会告诉对方自己能做哪些事，比如能不能用工具、能不能访问文件等。

2. 操作阶段（正式开始聊天和合作）

• 目的：双方可以互相发消息、请求帮助，真正开始"合作"。
• 过程：
  1. 客户端可以问：“你有哪些工具？”
  2. 服务器答：“我有这些工具……”
  3. 客户端说：“帮我用某个工具查一下数据库。”
  4. 服务器执行后把结果发回来。
• 细节：
  • 可以做很多事，比如获取资源、用工具、获取提示词等。
  • 只有在初始化阶段协商好的能力，才能在这里用。
  • 支持批量请求、通知、响应等多种消息类型。

3. 关闭阶段（礼貌地说再见）

• 目的：双方优雅地结束本次交流，防止"突然掉线"带来问题。
• 过程：
  1. 客户端说：“我要下线了！”
  2. 服务器收到后，也会准备好关闭。
  3. 双方断开连接，结束本次交流。
• 细节：
  • 如果一方突然掉线，另一方会自动关闭连接，保证不会出错。
  • stdio传输方式下，客户端会关闭输入流；HTTP方式下，直接断开HTTP连接。

---

2.3 小结

MCP协议的生命周期就像聊天工具加好友、聊天、再说再见的流程，每一步都很有礼貌，先打招呼、再聊天、最后说再见。这样做的好处是：

• 保证双方能听懂对方说的话（版本协商）
• 能力互相了解（能力协商）
• 聊天内容有序、安全

---

三、各个架构之间是怎么通信的？

在MCP协议的实际应用中，主机（Host）、客户端（Client）、服务器（Server）之间的消息传递，依赖于灵活可选的"传输协议"。这些协议就像不同类型的"快递员"，决定了消息如何在各个角色之间安全、快速地流转。

3.1 通信的基础：JSON-RPC

MCP协议所有消息都采用JSON-RPC格式，保证结构统一、易于解析。无论用哪种传输协议，消息内容都是JSON文本，编码为UTF-8。

3.2 主要传输协议类型

1. stdio（standard input & output，标准输入/输出）

• 原理：
• 消息以标准消息JSON-RPC格式为准。
• 消息通过stdin/stdout管道传递，发送端发送消息到通信管道stdout，接收端通过标准输入 stdin 读取发送端发送的消息。
• 以换行符：\n 作为读取完成标识。
• 消息流转：
  • 主机→客户端：本地进程通信（如发起初始化请求）。
  • 客户端→服务器：客户端以子进程的形式启动服务器，服务器启动时会创建通信管道。客户端可以往服务器的 stdin 写入消息，服务器从自身的 stdin 读取消息（如发起工具调用、资源请求等）。
  • 服务器→客户端→主机：服务端往自身的 stdout 写入消息，客户端从服务器的 stdout 读取消息。响应消息原路返回。
• 适用场景：主要用于本地数据访问、安全性要求高、不需要网络。
• 举例：你在本地用AI助手总结微信消息，所有数据都在本地，主机、客户端、服务器全用stdio通信。
• 优点：
  • 无外部依赖，实现简单。
  • 无网络传输，通信速度快。
  • 本地通信，安全性高。
• 局限性：
  • 只能用于本地进程间通信，无法直接支持远程访问。
  • 单进程通信，无法并行处理多个客户端请求，扩展性有限。
  • 进程通信的资源开销大，很难在本地同时运行大量服务。
  • 如果要访问远程资源，需要额外开发API服务和中转，流程复杂。

2. SSE（Server-Sent Events，已逐步废弃）

• 原理：基于HTTP协议，客户端与服务器建立SSE连接（GET /sse），再用POST /messages发送消息。
• 消息流转：
  • 系统管理员在远程服务器（也可以是本地电脑）输入命令，启动服务器，监听服务器端口，对外暴露 HTTP 接口。
  • SSE同步响应和推送事件信息是双通道的。客户端需先跟一个服务器端点建立 SSE 连接，再给另一个端点发消息。
  • 客户端通过POST发送JSON-RPC消息，服务器可以先确认SSE响应，如已收到状态码HTTP 202，在服务器处理完成事件后再通过通过SSE推送事件消息给客户端。
  • SSE 连接时，服务器会定时发送一条心跳检测消息，如果多次无响应，可以认作对方已断开连接，此时可以主动关闭 SSE 连接，避免资源泄露。
  • 客户端通过HTTP GET建立SSE连接，服务器分配sessionId，以做到客户端和服务器的一对一连接，防止多个会话数据串。
• 适用场景：本地和远程分离、需要流式推送、但对连接稳定性要求不高。
• 举例：你在本地用客户端，远程云服务器上有MCP服务，双方通过SSE连接实时推送消息。
• 优点：
  • 支持远程资源访问，客户端可直接访问远程服务。
  • 基于HTTP协议，兼容性好，易于与Web基础设施集成。
  • 服务器可作为独立进程运行，支持多个客户端连接。
  • 实现简单，不需要协议升级。
• 局限性：
  • 连接不稳定，容易断开，影响需要持久连接的场景。
  • 扩展性差，不适合云原生和大规模部署。
  • 浏览器和网络环境对SSE连接数有限制，易受代理、防火墙影响。
  • 双通道响应机制复杂，开发和维护难度大。
  • 长连接资源消耗大，需大量会话管理和心跳检测。
  • 已被Streamable HTTP逐步替代。

3. Streamable HTTP（（协议版本 2025-03-26 开始支持，推荐）

<