1.什么是MCP 客户端 #
MCP 客户端 = 主机应用里专门和某个 MCP 服务器「对话」的组件。
- 主机:你直接用的应用(如 Claude.ai、VS Code),负责整体体验、协调多个客户端
- 客户端:协议层面的组件,每个对应一个服务器,负责和该服务器的通信
通俗理解:主机是「总指挥」,客户端是派去和每个服务器对接的「代表」。
2 客户端能提供什么?—— 三个核心功能 #
除了使用服务器提供的工具、资源、提示,客户端还可以反过来向服务器提供能力,让服务器能构建更丰富的交互:
| 功能 | 通俗理解 | 举例 |
|---|---|---|
| 引导(Elicitation) | 服务器向用户要信息 | 预订时问座位偏好、房间类型、联系方式 |
| 根目录(Roots) | 告诉服务器能访问哪些目录 | 指定旅行工作区路径,限制文件访问范围 |
| 采样(Sampling) | 服务器通过客户端请求 LLM 帮忙 | 让 LLM 从 47 个航班里选最佳方案 |
3 引导:让服务器能「向用户要信息」 #
3.1 引导是什么? #
引导让服务器在交互过程中按需向用户请求信息,而不是要求一开始就提供全部数据。需要什么就问什么,流程更灵活。
3.2 流程示意 #
sequenceDiagram
participant User as 用户
participant Client as 客户端
participant Server as 服务器
Server->>Client: 创建信息收集请求
Client->>User: 显示表单/弹窗
User-->>Client: 填写并提交
Client-->>Server: 返回用户响应
Server->>Server: 用新信息继续处理
3.3 典型场景:预订确认 #
用户选好巴塞罗那行程后,服务器在正式预订前需要确认和补充信息,例如:
- 是否确认预订(航班+酒店 $3,000)
- 座位偏好:靠窗 / 靠过道 / 无所谓
- 房间类型:海景 / 城景 / 园景
- 是否加旅行保险($150)
服务器发引导请求,客户端展示表单,用户填写后返回给服务器,服务器再继续预订流程。
3.4 设计原则 #
| 原则 | 说明 |
|---|---|
| 清晰有上下文 | 说明是哪个服务器在问、为什么需要、会怎么用 |
| 结构化输入 | 用 schema 定义字段类型,支持验证 |
| 用户可拒绝 | 用户可拒绝提供、说明原因或取消操作 |
| 隐私保护 | 不请求密码、API 密钥;对可疑请求给出警告 |
4. 根目录:告诉服务器「能看哪些目录」 #
4.1 根目录是什么? #
根目录是客户端告诉服务器的文件系统访问范围,用 file:// URI 表示。服务器应在此范围内操作,避免越界访问。
4.2 根目录示例 #
{
"uri": "file:///Users/agent/travel-planning",
"name": "旅行规划工作区"
}4.3 典型场景:旅行代理工作区 #
| 根目录 | 用途 |
|---|---|
file:///Users/agent/travel-planning |
主工作区,所有行程文件 |
file:///Users/agent/travel-templates |
可复用行程模板 |
file:///Users/agent/client-documents |
客户护照等文档 |
服务器应只在上述目录内读写。当用户打开新文件夹(如归档目录)时,客户端可通过 roots/list_changed 通知服务器根目录已更新。
4.4 重要说明 #
- 根目录是协调机制,不是硬性安全边界
- 规范要求服务器「应尊重」根目录,实际安全依赖操作系统权限和沙箱
- 适用于:可信服务器、防止误操作、界定工作范围
4.5 谁在管理根目录? #
- 自动:用户打开文件夹时,客户端自动将其加入根目录
- 手动:高级用户可在配置中指定或排除某些目录
5. 采样:让服务器能「请 LLM 帮忙」 #
5.1 采样是什么? #
采样让服务器通过客户端请求 LLM 补全,而不必自己接入或付费 LLM。客户端控制权限和安全,用户可在请求前后进行审核。
5.2 流程示意 #
sequenceDiagram
participant LLM as 大语言模型
participant User as 用户
participant Client as 客户端
participant Server as 服务器
Server->>Client: 请求 LLM 分析/生成
Client->>User: 展示请求,等待审批
User-->>Client: 批准/修改/拒绝
Client->>LLM: 转发已批准的请求
LLM-->>Client: 返回生成内容
Client->>User: 展示结果,等待审批
User-->>Client: 批准/修改/拒绝
Client-->>Server: 返回已批准的响应
5.3 典型场景:航班推荐 #
用户问「帮我订下个月去巴塞罗那的最佳航班」时:
- 服务器的
findBestFlight工具调用航空公司 API,拿到 47 个航班 - 服务器通过客户端发起采样请求:请 LLM 根据用户偏好(早班、最多 1 次转机)分析并推荐
- 客户端展示请求,用户可批准或修改
- LLM 分析后返回推荐,客户端再展示给用户审核
- 用户确认后,结果才返回给服务器
5.4 用户如何参与? #
| 机制 | 说明 |
|---|---|
| 审批控制 | 采样前需用户同意,可批准、拒绝或修改 |
| 透明度 | 展示提示内容、模型选择、token 限制等 |
| 配置选项 | 可设模型偏好、对可信操作自动批准等 |
| 安全 | 客户端做速率限制、内容校验;敏感数据需用户确认后再返回服务器 |
6. 本章小结 #
| 功能 | 作用 |
|---|---|
| 引导 | 服务器按需向用户要信息,支持表单、确认、补充 |
| 根目录 | 界定服务器可访问的文件范围 |
| 采样 | 服务器通过客户端请求 LLM,由用户审批后返回 |
记忆要点:客户端不只是「用」服务器,还能「服务」服务器——提供用户输入、文件范围、LLM 能力。