跳到主要内容
MCP 客户端由宿主应用程序实例化，用于与特定的 MCP 服务器进行通信。宿主应用程序（例如 Claude.ai 或 IDE）负责管理整体用户体验并协调多个客户端。每个客户端负责处理与单个服务器的一次直接通信。 理解二者的区别很重要：宿主 (Host) 是用户交互的应用程序，而 客户端 (Client) 是实现服务器连接的协议级组件。

​
客户端核心功能

除了利用服务器提供的上下文外，客户端还可以向服务器提供多项功能。这些客户端功能使服务器开发者能够构建更丰富的交互体验。
功能说明示例
引出启发式引导 (Elicitation) 使服务器能够在交互过程中向用户请求特定信息，从而为服务器按需收集信息提供了一种结构化的方式。旅行预订服务器可能会要求用户提供有关飞机座位、房间类型或联系电话的偏好，以完成预订。
根根目录 (Roots) 允许客户端指定服务器应关注的目录，并通过协调机制传达预期的操作范围。旅行预订服务器可以被授予对特定目录的访问权限，并从中读取用户的日历信息。
采样采样 (Sampling) 允许服务器通过客户端请求 LLM 完成任务，从而实现代理工作流。这种方法使客户端能够完全控制用户权限和安全措施。旅行预订服务器可以将航班列表发送给 LLM，并要求 LLM 为用户选出最佳航班。

​
引出

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

​
概述

启发式引导为服务器按需收集必要信息提供了一种结构化方式。服务器无需在开始时要求提供所有信息，也不必在缺少数据时直接失败，而是可以暂停操作并向用户请求特定输入。这创造了更灵活的交互，使服务器能够适应用户需求，而不是遵循死板的模式。 启发式引导流程： 该流程实现了动态信息收集。服务器可以在需要时请求特定数据，用户通过适当的 UI 提供信息，服务器则利用新获得的上下文继续处理。 启发式引导组件示例：
{
  method: "elicitation/create",
  params: {
    message: "Please confirm your Barcelona vacation booking details:",
    requestedSchema: {
      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 日，海滨酒店，总价 3,000 美元）以及用于填写其他偏好的字段——例如座位选择、房间类型或旅行保险选项。 随着预订的推进，服务器会引导用户提供完成预订所需的联系信息。它可能会询问航班预订所需的旅客详细信息、酒店特殊要求或紧急联系信息。

​
用户交互模型

启发式引导交互旨在清晰、关联性强并尊重用户自主权： 请求展示：客户端显示启发式引导请求时，会提供明确的上下文，说明是哪个服务器在提问、为什么需要这些信息以及将如何使用。请求消息解释目的，而模式 (schema) 提供结构和验证。 响应选项：用户可以通过适当的 UI 控件（文本框、下拉菜单、复选框）提供请求的信息，也可以选择拒绝提供（可附带解释）或取消整个操作。客户端会在将响应返回给服务器之前，根据提供的模式对响应进行验证。 隐私考虑：启发式引导绝不会请求密码或 API 密钥。客户端会对可疑请求发出警告，并允许用户在发送前审查数据。

​
根

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

​
概述

根目录是客户端向服务器传达文件系统访问边界的一种机制。它们由指示服务器可操作目录的文件 URI 组成，帮助服务器了解可用文件和文件夹的范围。虽然根目录传达了预期的边界，但它们并不强制执行安全限制。实际的安全保障必须在操作系统层面通过文件权限和/或沙盒机制来执行。 根目录结构：
{
  "uri": "file:///Users/agent/travel-planning",
  "name": "Travel Planning Workspace"
}
根目录仅限于文件系统路径，并且始终使用 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 模型访问权限）代为处理这些任务。这种方法使客户端能够完全控制用户权限和安全措施。由于采样请求是在其他操作（如数据分析工具）的上下文中发生的，并作为单独的模型调用进行处理，因此它们在不同上下文之间保持了清晰的界限，从而可以更高效地利用上下文窗口。 采样流程： 该流程通过多个“人在回路”(human-in-the-loop) 的检查点确保安全性。在初始请求和生成的响应返回给服务器之前，用户可以对其进行审查和修改。 请求参数示例：
{
  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-sonnet-4-20250514"  // 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 评估各种权衡——比如更便宜的红眼航班与便捷的上午出发航班。该工具利用此分析结果向用户展示前三名推荐。

​
用户交互模型

虽然不是强制要求，但采样的设计旨在允许“人在回路”的控制。用户可以通过多种机制保持监督： 审批控制：采样请求可能需要明确的用户同意。客户端可以展示服务器想要分析的内容及其原因。用户可以批准、拒绝或修改请求。 透明度功能：客户端可以显示确切的提示词 (Prompt)、模型选择和 Token 限制，允许用户在 AI 响应返回服务器之前进行审查。 配置选项：用户可以设置模型偏好、配置受信任操作的自动批准，或要求对所有操作进行审批。客户端可能提供脱敏敏感信息的选项。 安全考虑：在采样过程中，客户端和服务器都必须妥善处理敏感数据。客户端应实施速率限制并验证所有消息内容。“人在回路”的设计确保了服务器发起的 AI 交互不会在未经用户明确同意的情况下损害安全性或访问敏感数据。