1.客户端概念 #

MCP（Model Context Protocol）客户端是宿主应用程序实例化的组件，用于与特定的MCP服务器进行通信。宿主应用程序（如Claude.ai或IDE）负责管理整体用户体验并协调多个客户端。每个客户端处理与单个服务器的直接通信。

理解其中的区别至关重要：宿主是用户与之交互的应用程序，而客户端是支持服务器连接的协议级组件。

2.核心客户端功能 #

除了利用服务器提供的上下文外，客户端也可以向服务器提供若干功能。这些客户端特性使得服务器开发者能够构建更丰富的交互体验。例如，客户端可允许MCP服务器通过询问方式向用户请求额外信息。客户端可提供以下能力：

3.采样 (Sampling) #

采样允许服务器通过客户端请求语言模型补全，在保持安全性和用户控制的同时，实现代理行为。

3.1 采样概述 #

采样技术使服务器能够执行依赖AI的任务，而无需直接集成或支付AI模型费用。服务器可以请求已具备AI模型访问权限的客户端代其处理这些任务。这种方式让客户端完全掌控用户权限和安全措施。由于采样请求发生在其他操作（如数据分析工具）的上下文中，并以独立模型调用的方式处理，它们在不同上下文间保持了清晰界限，从而能更高效地利用上下文窗口。

3.2 采样流程 #

该流程通过多个"人在回路"检查点确保安全性。用户在请求返回服务器前，既能审查初始请求，也可修改生成的响应。

3.3 请求参数示例 #

// 采样请求的完整参数结构
{
  messages: [
    {
      role: "user",
      content: "请分析以下航班选项并推荐最佳选择：\n" +
               "[47个航班，包含价格、时间、航空公司及中转信息]\n" +
               "用户偏好：早班出发，最多1次中转"
    }
  ],
  modelPreferences: {
    hints: [{
      name: "claude-3-5-sonnet"  // 建议的模型
    }],
    costPriority: 0.3,      // 不太关心API成本
    speedPriority: 0.2,     // 可以等待详细分析
    intelligencePriority: 0.9  // 需要复杂的权衡评估
  },
  systemPrompt: "你是一名旅行专家，帮助用户根据其偏好选择最佳航班",
  maxTokens: 1500
}

3.4 示例：航班分析工具 #

考虑一个名为findBestFlight的旅行预订服务器工具，该系统通过采样分析可用航班并推荐最优选择。当用户询问"帮我预订下个月去巴塞罗那的最佳航班"时，该工具需要借助AI来评估复杂的权衡因素。

该工具查询航空公司API并收集了47个航班选项，随后请求AI协助分析这些数据。

3.5 用户交互模型 #

采样的设计以人在回路控制为基本原则，用户通过多种机制保持监督：

审批控制：每个采样请求都需要用户的明确同意。客户端会展示服务器想要分析的内容及其原因。用户可以批准、拒绝或修改这些请求。

透明度特性：客户端会显示确切的提示词、模型选择及token限制。用户在AI响应返回服务器前可进行审核。

配置选项：用户可以设置模型偏好，配置对可信操作的自动批准，或要求对所有操作进行审批。客户端可能提供选项来编辑敏感信息。用户决定在采样请求中可以包含多少对话上下文（includeContext参数）。

隔离：默认情况下，采样请求与主对话上下文相互隔离。服务器无法访问用户对话内容。

安全考量：客户端和服务器在采样过程中都必须妥善处理敏感数据。客户端应实施速率限制并验证所有消息内容。人机协同设计确保，未经用户明确同意，服务器发起的AI交互不会危及安全或访问敏感数据。

4.根目录 (Roots) #

Roots定义了服务器操作的文件系统边界，使客户端能够指定服务器应关注哪些目录。

4.1 概述 #

Roots是一种机制，客户端通过它向服务器传达文件系统访问边界。它们由文件URI组成，这些URI指向服务器可操作的目录，帮助服务器理解可用文件和文件夹的范围。Roots并非赋予服务器无限制的文件系统访问权限，而是引导它们进入相关的工作目录，同时维持安全边界。

根目录结构：

{
  "uri": "file:///Users/agent/travel-planning",
  "name": "Travel Planning Workspace"
}

根目录仅为文件系统路径且始终使用file://URI方案。它们帮助服务器理解项目边界、工作区组织以及可访问的目录。随着用户处理不同项目或文件夹，根目录列表可以动态更新，服务器会通过roots/list_changed通知接收这些变更。

需要注意的是，虽然roots为服务器提供了操作范围的指引，但客户端始终完全掌控文件访问权限。roots仅传达预期的边界——实际的文件访问始终由客户端的安全策略进行调控。

4.2 示例：旅行规划工作空间 #

一位与多个客户行程打交道的旅行社代理，通过roots组织文件系统访问会受益匪浅。设想一个工作空间，其中包含针对旅行规划不同方面的多个目录。

客户端向旅行规划服务器提供文件系统根目录：

• file:///Users/agent/travel-planning - 包含所有旅行文件的主工作区
• file:///Users/agent/travel-templates - 可重复使用的行程模板和资源
• file:///Users/agent/client-documents - 客户护照及旅行证件

当代理创建巴塞罗那行程时，服务器会在这些边界内工作——访问模板、保存新行程以及引用客户文档。它无法访问这些根目录之外的文件。服务器通常通过使用根目录的相对路径，或利用遵守根目录边界的文件搜索工具，来访问根目录内的文件。

如果代理打开一个存档文件夹，比如file:///Users/agent/archive/2023-trips，客户端通过更新根列表roots/list_changed通知服务器。

4.3 用户交互模型 #

根节点通常由宿主应用根据用户操作自动管理，不过部分应用可能提供手动管理功能。

自动检测root权限：当用户打开文件夹时，客户端会自动将其暴露为根目录。打开一个travel工作区后，服务器便能访问该目录内的行程安排和文档。

手动根配置：高级用户可以通过配置指定根目录。例如，添加/travel-templates针对可重复使用的资源，同时排除包含财务记录的目录。

5.启发 (Elicitation) #

引导功能使服务器能在交互过程中向用户请求特定信息，从而创建更具动态性和响应性的工作流程。

5.1 概述 #

启发式询问为服务器提供了一种结构化的方式，按需收集必要信息。它无需预先获取全部数据或在信息缺失时直接失败，而是允许服务器暂停操作，向用户请求特定输入。这种方式创造了更灵活的交互体验，使服务器能适应用户需求，而非遵循僵化的固定模式。

启发流程：

该流程支持动态信息收集。服务器可在需要时请求特定数据，用户通过合适的UI界面提供信息，服务器则利用新获取的上下文继续处理。

启发式组件示例：

// 完整的启发式请求结构
{
  method: "elicitation/requestInput",
  params: {
    message: "请确认您的巴塞罗那度假预订详情：",
    schema: {
      type: "object",
      properties: {
        confirmBooking: {
          type: "boolean",
          description: "确认预订（机票+酒店=￥3,000）"
        },
        seatPreference: {
          type: "string",
          enum: ["靠窗", "靠过道", "无偏好"],
          description: "航班座位偏好"
        },
        roomType: {
          type: "string",
          enum: ["海景房", "市景房", "花园景观房"],
          description: "酒店房型偏好"
        },
        travelInsurance: {
          type: "boolean",
          default: false,
          description: "添加旅行保险（￥150）"
        }
      },
      required: ["confirmBooking"]
    }
  }
}

5.2 示例：假期预订确认 #

一个旅行预订服务器通过最终的预订确认流程展示了需求引导的力量。当用户选择了他们理想的巴塞罗那度假套餐后，服务器需要收集最终确认和任何缺失的详细信息才能继续操作。

服务器通过结构化请求获取预订确认，其中包含行程摘要（6月15日至22日巴塞罗那航班、海滨酒店、总计3000美元）以及用于填写额外偏好的字段——例如座位选择、房间类型或旅行保险选项。

随着预订流程的推进，服务器会询问完成预订所需的联系方式。它可能会要求提供航班预订所需的旅客详细信息、酒店的特殊要求或紧急联系人信息。

5.3 用户交互模型 #

启发式交互设计旨在清晰、情境化且尊重用户自主权：

请求演示：客户端在展示信息征询请求时，会明确说明是哪个服务器在询问、为何需要该信息以及将如何使用这些信息。请求消息解释目的，而schema则提供结构化和验证机制。

响应选项：用户可以通过适当的UI控件（如文本框、下拉菜单、复选框）提供所需信息，可选择附带说明拒绝提供信息，或取消整个操作。客户端会根据提供的schema验证响应内容，再将其返回给服务器。

隐私考量：Elicitation从不索要密码或API密钥。客户端会警示可疑请求，并让用户在发送前审核数据。

6.总结 #

MCP客户端概念为构建安全、可控且用户友好的AI应用程序提供了强大的基础。通过采样、根目录和启发这三种核心功能，客户端能够在保持用户控制的同时，为服务器提供丰富的交互能力。

这些功能共同工作，创造了一个平衡的生态系统，其中：

• 用户保持对AI交互的完全控制
• 服务器能够执行复杂的任务
• 安全性通过多层检查点得到保障
• 用户体验通过直观的界面得到优化

通过理解和正确实现这些概念，开发者可以创建既强大又安全的MCP应用程序。