MCP 架构:Client-Server 模型

文档摘要

MCP 架构:Client-Server 模型本节摘要:MCP 的架构分三层:Host(你的 IDE)→ Client(协议适配层)→ Server(实际干活的进程)。理解这个分层,你就能明白为什么「一个 Server 能被所有 IDE 使用」、为什么配置里要写和、以及 stdio 和 SSE 两种传输方式各自适合什么场景。本节用一张架构图和逐步拆解,把 MCP 的通信机制讲透。

MCP 架构:Client-Server 模型

本节摘要:MCP 的架构分三层:Host(你的 IDE)→ Client(协议适配层)→ Server(实际干活的进程)。理解这个分层,你就能明白为什么「一个 Server 能被所有 IDE 使用」、为什么配置里要写 command 和 args、以及 stdio 和 SSE 两种传输方式各自适合什么场景。本节用一张架构图和逐步拆解,把 MCP 的通信机制讲透。

一、三层架构总览

三层各自的职责:

层	是什么	做什么
Host	你的 IDE(Cursor / VS Code 等)	管理多个 Client;决定 AI 能调用哪些 Tool;展示确认对话框
Client	Host 内部的协议适配器	维护与一个 Server 的 1:1 连接;处理协议消息的编解码
Server	独立进程(本地或远程)	暴露 Tool / Resource / Prompt;实际执行操作(读文件、查数据库等)

关键概念:一个 Host 可以同时连接多个 Server(通过多个 Client)。比如你的 Cursor 同时连着 Filesystem Server、Search Server 和 Database Server——AI 根据需要选择调用哪个。

二、通信生命周期

一个 MCP 连接从建立到关闭,经历以下阶段:

初始化:Host 根据配置启动 Server 进程(如 npx @modelcontextprotocol/server-filesystem /path/to/dir)
能力协商:Server 告诉 Client「我有哪些 Tool / Resource / Prompt」;Client 记录这些能力
就绪:Host 把 Server 的能力汇总后告诉 AI 模型「你现在可以用这些工具」
运行时:AI 决定调用某个 Tool → Client 发请求给 Server → Server 执行 → 返回结果 → Client 转给 AI
关闭:IDE 关闭或用户手动断开时,Client 发送关闭消息,Server 进程退出

💡 技巧:如果 AI 说「我没有这个工具」或「无法执行此操作」,很可能是 Server 没有正常启动或能力协商失败。检查 IDE 的 MCP 面板,看 Server 状态是否为「Connected」。

三、传输层:stdio vs SSE

MCP 支持两种传输方式,适用场景不同:

stdio(标准输入/输出)

原理:Server 是一个本地子进程,通过 stdin/stdout 与 Client 通信
配置:你在 IDE 中指定 command(如 npx、python)和 args(参数)
优点:零网络开销、低延迟、无需端口、安全性高(不暴露网络服务)
适用:本地工具(文件系统、本地数据库、命令行工具)
限制:Server 必须跟 IDE 在同一台机器上

SSE(Server-Sent Events)

原理:Server 是一个 HTTP 服务,Client 通过 HTTP 长连接与之通信
配置:你在 IDE 中指定 Server 的 URL(如 http://localhost:3001/sse)
优点:可以跨网络(远程 Server);多个 Client 可以共享一个 Server
适用:远程服务(云端数据库、团队共享的知识库、SaaS API 网关)
限制:需要网络;需要处理认证和 CORS

选择规则:

Server 跑在本地 → stdio(简单、安全)
Server 跑在远程/需要共享 → SSE

四、能力协商详解

Server 启动后,第一件事是「自我介绍」——告诉 Client 自己能做什么:


Server → Client: "我有以下能力:
  Tools: [read_file, write_file, list_directory]
  Resources: [file:///{path}]
  Prompts: []"

Client 收到后,把这些信息汇总给 Host。Host 再把所有已连接 Server 的能力合并,注入到 AI 的上下文中。这就是为什么 AI「知道」它可以调用 read_file——不是硬编码的,而是 Server 动态声明的。

这意味着:

你安装一个新 Server,AI 自动获得新能力(不需要更新 IDE)
Server 升级加了新 Tool,AI 下次连接自动可用
你禁用一个 Server,AI 立刻失去对应能力

五、消息格式(JSON-RPC 2.0)

MCP 底层用 JSON-RPC 2.0 格式通信。你不需要手写这些消息(IDE 和 SDK 会处理),但了解格式有助于调试:

请求示例(Client → Server,调用 Tool):


{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "read_file",
    "arguments": { "path": "/src/main.py" }
  },
  "id": 1
}

响应示例(Server → Client):


{
  "jsonrpc": "2.0",
  "result": {
    "content": [{ "type": "text", "text": "文件内容..." }]
  },
  "id": 1
}

⚠️ 注意:日常使用不需要关心消息格式。但如果你开发自定义 Server(第 05 节)或排查连接问题,理解 JSON-RPC 格式能帮你快速定位问题(比如用 MCP Inspector 工具查看实际通信内容)。

本节要点回顾

三层架构:Host(IDE)→ Client(协议适配)→ Server(执行操作),一对多关系
生命周期:初始化 → 能力协商 → 就绪 → 运行时调用 → 关闭
传输选择:本地用 stdio(简单安全),远程用 SSE(跨网络)
能力协商:Server 动态声明能力,AI 自动获知——安装新 Server 即获新能力
消息格式:JSON-RPC 2.0,日常无需关心,调试和开发时需要了解

架构清楚了,下一步就是动手:在你的 IDE 中配置第一个 MCP Server。