MCP 客户端由主机应用程序实例化，用于与特定 MCP 服务器通信。主机应用程序（如Claude.ai或IDE）管理整体用户体验并协调多个客户端。每个客户端处理与一个服务器的直接通信。 理解这种区别很重要：主机是指用户与之交互的应用程序，而用户是指支持服务器连接的协议级组件。

​
核心客户端功能

除了利用服务器提供的上下文，客户端也可以向服务器提供若干功能。这些客户端特性让服务器开发者能够构建更丰富的交互体验。
功能特性说明解释示例
采样采样功能允许服务器通过客户端请求LLM完成，实现智能体工作流。这种方法让客户端完全掌控用户权限和安全措施。一个预订旅行服务的服务器可能会向LLM发送航班列表，并请求LLM为用户选择最佳航班。
RootsRoots允许客户端指定服务器可以访问哪些文件，引导它们访问相关目录同时维护安全边界。一个预订旅行服务的服务器可能会被授权访问特定目录，从中可以读取用户的日历。
信息收集信息收集使服务器能够在交互过程中向用户请求特定信息，为服务器按需收集信息提供结构化方式。一个预订旅行的服务器可能会询问用户对飞机座位、房间类型的偏好或联系方式，以完成预订。

​
触发

请求功能允许服务器在交互期间向用户请求特定信息，从而创建更具动态性和响应性的工作流。

​
概览

Elicitation 提供了一种结构化的方式，让服务器能够按需收集必要信息。服务器无需预先获取所有信息或在数据缺失时失败，而是可以暂停操作来向用户请求特定输入。这创造了更灵活的交互方式，使服务器能够适应用户需求，而不是遵循固定模式。 启发流程： 该流程支持动态信息收集。服务器可在需要时请求特定数据，用户通过合适的UI界面提供信息，服务器则利用新获取的上下文继续处理。 启发组件示例： 
{
  method: "elicitation/requestInput",
  params: {
    message: "Please confirm your Barcelona vacation booking details:",
    schema: {
      type: "object",
      properties: {
        confirmBooking: {
          type: "boolean",
          description: "Confirm the booking (Flights + Hotel = $3,000)"
        },
        seatPreference: {
          type: "string",
          enum: ["window", "aisle", "no preference"],
          description: "Preferred seat type for flights"
        },
        roomType: {
          type: "string",
          enum: ["sea view", "city view", "garden view"],
          description: "Preferred room type at hotel"
        },
        travelInsurance: {
          type: "boolean",
          default: false,
          description: "Add travel insurance ($150)"
        }
      },
      required: ["confirmBooking"]
    }
  }
}

​
示例：假期预订审批

一个旅行预订服务器通过在最终预订确认流程中展示诱导的功能。当用户选择了他们理想的巴塞罗那度假套餐后，服务器需要收集最终批准以及任何遗漏的细节才能继续。 服务器通过结构化请求来获得预订确认,该请求包含行程摘要(巴塞罗那航班6月15-22日,海滨酒店,总计3000美元)以及任何额外偏好的字段——例如座位选择、房型或旅行保险选项。 随着预订的进行，服务器会收集完成预订所需的联系信息。它可能会询问航班预订的旅客详细信息、酒店的特殊要求或紧急联系信息。

​
用户交互模式

引导交互旨在清晰、具有情景性，并尊重用户的自主权： 请求展示: 客户端会清晰展示服务器的信息请求，包括哪个服务器在询问、为何需要该信息以及将如何使用。请求消息解释目的，而模式则提供结构和验证。 响应选项: 用户可以通过适当的UI控件（文本字段、下拉菜单、复选框）提供所请求的信息，可选择附带说明拒绝提供信息，或取消整个操作。客户端在将响应返回给服务器之前，会依据提供的模式验证响应内容。 隐私考量: Elicitation绝不会请求密码或API密钥。客户端会对可疑请求发出警告，并允许用户在发送前审查数据。

​
根对象

Roots定义了服务器操作的文件系统边界，允许客户端指定服务器应关注的目录。

​
概览

Roots是一种机制，供客户端向服务器传递文件系统访问边界。它们由文件URI组成，指示服务器可以操作的目录，帮助服务器理解可用文件和文件夹的范围。不是给予服务器无限制的文件系统访问权限，roots将它们引导至相关的工作目录，同时保持安全边界。 根结构： 
{
  "uri": "file:///Users/agent/travel-planning",
  "name": "Travel Planning Workspace"
}
Roots 专门表示为文件系统路径，并始终使用 file:// URI 方案。它们帮助服务端理解项目边界、工作空间组织以及可访问目录。根目录列表可随着用户处理不同项目或文件夹而动态更新，当边界发生变化时，服务端会通过 roots/list_changed 接收通知。 需要重点注意的是，虽然根目录向服务器提供了操作指引，但客户端始终完全掌控文件访问权限。根目录仅传达预期边界——实际的文件访问始终受客户端安全策略的调控。

​
示例：旅行规划工作空间

一名处理多个客户行程的旅行智能体可从根目录获益，以便组织文件系统访问。设想一个工作空间，其中包含针对旅行规划不同方面的各种目录。 客户端向行程规划服务器提供文件系统根目录：
  • file:///Users/agent/travel-planning - 主工作空间，包含所有旅行文件
  • file:///Users/agent/travel-templates - 可复用的行程模板和资源
  • file:///Users/agent/client-documents - 客户护照和旅行证件
当智能体创建巴塞罗那行程时，服务器在这些边界内工作——访问模板、保存新行程以及引用客户文档。它无法访问这些根目录之外的文件。服务器通常通过使用根目录的相对路径或利用遵守根目录边界的文件搜索工具来访问根目录内的文件。 如果智能体打开一个存档文件夹例如 file:///Users/agent/archive/2023-trips，客户端通过 roots/list_changed 更新根目录列表。

​
用户交互模式

根目录通常由宿主应用程序根据用户操作自动管理，不过部分应用可能会提供手动管理根目录的功能： 自动根节点检测: 当用户打开文件夹时，客户端会自动将它们设置为根目录。开启工作区后，服务器可获得该目录内的行程安排和文档访问权限。 手动根配置: 高级用户可通过配置指定根路径。例如，添加 /travel-templates 用于可复用资源，同时排除包含财务记录的目录路径。

​
采样

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

​
概览

采样功能使服务器能够执行与AI相关的任务，而无需直接集成或支付AI模型费用。取而代之的是，服务器可以请求已具备AI模型访问权限的客户端代表其处理这些任务。这种方法让客户端完全掌控用户权限和安全措施。由于采样请求发生在其他操作（如工具分析数据）的上下文中，并以独立的模型调用方式处理，它们在不同上下文之间保持了清晰的界限，从而更高效地利用上下文窗口。 抽样流程： 该流程通过多个人工参与检查点确保安全性。在返回服务器之前，用户会审查并可以修改初始请求和生成的响应。 请求参数示例： 
{
  messages: [
    {
      role: "user",
      content: "Analyze these flight options and recommend the best choice:\n" +
               "[47 flights with prices, times, airlines, and layovers]\n" +
               "User preferences: morning departure, max 1 layover"
    }
  ],
  modelPreferences: {
    hints: [{
      name: "claude-3-5-sonnet"  // Suggested model
    }],
    costPriority: 0.3,      // Less concerned about API cost
    speedPriority: 0.2,     // Can wait for thorough analysis
    intelligencePriority: 0.9  // Need complex trade-off evaluation
  },
  systemPrompt: "You are a travel expert helping users find the best flights based on their preferences",
  maxTokens: 1500
}

​
示例：航班分析工具

考虑一个旅行预订服务器，带有一个名为findBestFlight的工具，它使用抽样分析可用航班并推荐最佳选择。当用户询问“给我预订下个月去巴塞罗那的最佳航班”时，该工具需要AI协助来评估复杂的权衡。 工具查询了航空公司的API并收集了47个航班选项。然后请求AI助手分析这些选项：“分析这些航班选项并推荐最佳选择：[47个含有价格、时间、航空公司和转机信息的航班] 用户偏好：早晨出发，最多1次转机。” 客户端发起采样请求，允许AI评估权衡——比如廉价的红眼航班与便捷的早间航班。该工具使用此分析来呈现前三名的推荐。

​
用户交互模式

虽然不是必需的，但采样设计允许人在环中进行控制。用户可以通过以下几种机制保持监督： 审批控制: 抽样请求可能需要明确的用户同意。客户端可以显示服务器希望分析的内容及原因。用户可批准、拒绝或修改请求。 透明度特性: 客户端可以显示确切的提示、模型选择和令牌限制，使用户能够在AI响应返回服务器之前进行审阅。 配置选项: 用户可以设置模型偏好，为可信操作配置自动批准，或者对所有操作要求批准。客户端可提供选项以屏蔽敏感信息。 安全性考虑: 客户端和服务端在采样过程中都必须妥善处理敏感数据。客户端应实施速率限制并验证所有消息内容。人工介入设计确保在没有用户明确同意的情况下，服务端发起的AI交互不会危及安全或访问敏感数据。