基于我们之前探讨的“MCP本质是结构化信息传递”以及“集中决策、分布式执行”的架构视角，MCP Server 的消息处理流程实际上就是一个“翻译—决策—执行”的闭环过程。

可以把 MCP Server 想象成一个“海关与物流中心”：它接收来自外部（AI/Client）的标准化集装箱（JSON），拆箱检查（解析），根据货物类型分发给不同的工厂（工具/资源），处理完后再打包发回。

以下是 MCP Server 内部消息处理的全链路深度解析：

🌐 核心架构概览：三层漏斗模型

MCP Server 的处理流程通常分为三个核心层级：

1. 传输层 (Transport Layer)：负责物理连接和字节流传输（Stdio 或 HTTP/SSE）。
2. 协议层 (Protocol Layer)：负责 JSON-RPC 消息的解析、路由和会话管理。
3. 业务层 (Business Layer)：负责具体的工具执行、资源读取和提示词生成。

---

🚀 详细处理流程五步曲

第一步：连接与握手

在正式处理业务消息前，Server 必须先“上线”。

• 启动：Server 作为一个独立进程（Stdio模式）或服务（HTTP模式）启动。
• 握手：Client 发送 initialize 请求。Server 接收后，协商协议版本（通常是 JSON-RPC 2.0），并交换能力清单（Capabilities，例如：“我支持 Tools，但不支持 Prompts”）。
• 会话建立：Server 为该 Client 分配一个会话 ID（Session ID），用于后续的状态隔离。

第二步：消息接收与“翻译”

这里提到的“结构化信息传递”的关键入口。

• 读取流：Server 从 stdin（标准输入）或 HTTP POST 请求体中读取原始字节流。
• 反序列化：将原始字符串解析为 JSON 对象。
  • 输入：{"jsonrpc": "2.0", "id": 1, "method": "tools/call", ...}
  • 动作：Server 检查 JSON 格式是否合法，是否符合 JSON-RPC 2.0 标准。

第三步：路由分发

Server 根据 JSON 中的 method 字段，将消息分发到不同的处理管道。MCP 定义了三大类原语，路由逻辑如下：

消息类型 (Method)	路由目标	处理逻辑
Tools (tools/call)	执行器	查找已注册的函数，准备执行代码逻辑。
Resources (resources/read)	读取器	查找文件路径或数据源 URI，准备读取数据。
Prompts (prompts/get)	模板引擎	查找预定义的提示词模板，填充参数。
初始化/列表 (initialize, tools/list)	元数据管理器	返回 Server 自身的能力描述（即你之前看到的 JSON Schema 定义）。

第四步：业务执行

这是 Server 最核心的“苦力活”阶段。

1. 参数提取：从 params 字段中提取参数（如 {"price": 100, "rate": 0.1}）。
2. 类型校验：Server 会利用 JSON Schema 对参数进行校验。如果 AI 传了字符串 "100" 而不是数字 100，Server 会在此处拦截并报错。
3. 调用实现：
   • 工具调用：执行对应的 Python/Node.js 函数。
   • 资源读取：打开文件流，读取内容，转换为 Base64 或文本。
4. 异常捕获：如果代码崩溃（如除以零），Server 会捕获异常，并将其转换为标准的 JSON-RPC 错误对象。

第五步：响应封装与回传

执行完毕后，Server 需要将结果“翻译”回 AI 能听懂的语言。

• 结果封装：将执行结果包装在 result 字段中。
  • 输出：{"jsonrpc": "2.0", "id": 1, "result": {"content": "税费为 10 元"}}
• 序列化：将 JSON 对象转回字符串。
• 发送：通过 stdout 或 SSE 流将字符串写回给 Client。

---

⚙️ 两种核心模式的差异

根据传输方式的不同，处理流程在底层略有区别：

1. Stdio 模式（本地进程）

• 流程：同步阻塞式。
• 特点：Client 启动 Server 进程 -> Server 监听 stdin -> 收到一行 JSON -> 处理 -> 输出一行 JSON -> 进程保持运行。
• 优势：简单、低延迟，适合本地文件操作。

2. SSE / Streamable HTTP 模式（远程服务）

• 流程：异步事件驱动。
• 特点：
  • Client 发送 HTTP POST 请求（携带 JSON）。
  • Server 接收请求，放入消息队列。
  • Server 的处理线程从队列取消息执行。
  • Server 通过 SSE 连接（Server-Sent Events）将结果“推”送给 Client。
• 优势：支持高并发、长连接，适合云端部署。

📌 总结：从代码到智能的映射

结合之前的深刻见解，MCP Server 的消息处理流程本质上是在做一件事：将 AI 的“意图”（非结构化/半结构化 JSON）映射为计算机的“动作”（函数调用），再将“结果”（结构化数据）翻译回 AI 的“认知”。

• 输入：AI 说“我要算税”（Tools Call）。
• 处理：Server 翻译为 calculate_tax(price=100, rate=0.1)。
• 输出：Server 翻译回“结果是 10 元”（Text Content）。

这个闭环，就是 AI 能够操作物理世界和数字世界的基石。

📌 流程总结

为了让你更清晰地理解，可以参考以下简化的调用链：

1. 客户端请求 → 服务端响应
   Client Request → Server 读取请求(Read) → Server JSON 解析(parse) → 根据 method 路由(HandleRequest) → Server 调用工具函数(Execute Tool) → 构造响应(Create Response) → Server 写入(Write) → Client收到执行结果

2. 客户端通知 → 服务端处理（不回包）
   Client Notification → Server 读取(Read) → JSON 解析(parse) → 根据 method 路由(HandleRequest) → 调用通知处理器(Execute Notification) → 结束(无响应)

3. 服务端主动推送Server 业务逻辑 → 构造通知(Create Notification) → Server 写入(Write) → Client