2.1 拆解 MCP——Client-Host-Server 三层架构
小周决定学 MCP 了。他打开 Claude Desktop 准备配置一个 GitHub MCP Server，但看到配置文件里的 command、args、mcpServers 一脸懵——他需要先理解 MCP 的架构是怎么运转的。
三层架构
MCP 采用三层架构，灵感来自 LSP：
三个角色详解
Host（宿主）
Host 是创建和管理 Client 的应用程序。它是 AI 和 MCP 之间的桥梁。
| Host | 说明 |
|---|---|
| Claude Desktop | Anthropic 的桌面应用，最先支持 MCP |
| VS Code | 微软的编辑器，2025 年添加 MCP 支持 |
| Cursor | AI 编程编辑器，通过 Settings → MCP 配置 |
| ChatGPT | OpenAI 的聊天应用，2025 年支持 MCP |
| Claude Code | CLI 工具，已内置文件读写、Git、Bash 等能力，可通过 .claude/settings.json 配置额外 MCP Server |
Host 的职责：
- 创建和管理多个 MCP Client 实例
- 汇聚所有 Client 发现的工具，暴露给 AI 模型
- 处理 AI 模型的工具调用请求，分发给对应的 Client
Client（客户端）
Client 是 Host 内部的协议状态机，与 Server 保持 1:1 连接。
Server（服务端）
Server 是提供能力的独立进程。它可以是：
- 本地进程（通过 stdio 通信）——如文件系统 Server
- 远程服务（通过 HTTP 通信）——如 GitHub API Server
Server 的职责：
- 注册和暴露工具（Tools）、资源（Resources）、模板（Prompts）
- 处理 Client 的请求
- 发送通知（工具变更、进度更新、日志）
- 可选：请求 Client 做事（Sampling、Elicitation）
传输方式
MCP 支持两种传输方式，分别对应本地和远程场景：
stdio 的关键规则
stdio Server 绝不能向 stdout 写入非协议数据。stdout 只能用于 JSON-RPC 消息，否则会破坏协议解析。所有日志必须写入 stderr。
生命周期
MCP 连接经历三个阶段：
initialize 请求，携带自己的能力和协议版本 → Server 回复自己的能力和版本 → Client 发送 initialized 通知 → 双方按协商的能力开始工作。关键：能力协商——Client 声明支持 sampling/elicitation/roots，Server 声明提供 tools/resources/prompts。
小周的观察
小周打开了 Claude Desktop，配置了两个 MCP Server（文件系统和 GitHub）。他在输入框旁边看到了工具图标，悬停后显示了所有可用的工具。
这就是三层架构在起作用：
- Claude Desktop（Host）创建了两个 Client 实例
- 每个 Client 分别连接到文件系统 Server 和 GitHub Server
- 两个 Server 各自暴露工具，Client 汇聚后交给 Claude 模型使用
本节核心要点
- MCP 三层架构：Host（管理 Client）→ Client（1:1 连接 Server）→ Server（提供能力）
- Server 之间完全隔离，不直接通信
- 两种传输：stdio（本地子进程）和 Streamable HTTP（远程 HTTP）
- 生命周期三阶段：初始化（能力协商）→ 正常通信 → 关闭
- stdio Server 绝不能向 stdout 写非协议数据
思考题：如果一个 Server 需要访问另一个 Server 的能力（比如 GitHub Server 需要读写文件），MCP 架构下应该怎么做？（提示：想想 Server 之间的隔离原则）
参考思路
MCP 架构下 Server 之间完全隔离，不直接通信。解决方案有两种：(1) 让 AI（Client/Host 层）编排——先调用 filesystem-server 读文件，再调用 github-server 创建 Issue；(2) 在 Server 内部直接使用需要的 API（如 GitHub Server 内部调用文件系统库），但这意味着该 Server 自己承担了职责，绕过了 MCP 的隔离。