理解 MCP 客户端

社区译文；来源： MCP 80041ab0

宿主应用会实例化 MCP 客户端，以便与特定 MCP 服务器通信。Claude.ai 或 IDE 等宿主应用负责管理整体用户体验，并协调多个客户端。每个客户端只负责与一个服务器直接通信。

理解这一区别非常重要：宿主 是用户直接交互的应用，而 客户端 是支持服务器连接的协议层组件。

客户端核心功能

客户端除了使用服务器提供的上下文，还可以向服务器提供多种功能。这些客户端功能让服务器作者能够构建更丰富的交互。

信息征询

信息征询让服务器能够在交互期间向用户请求特定信息，从而构建更动态、响应更及时的工作流。

概述

信息征询为服务器按需收集必要信息提供了结构化方式。服务器不必要求用户预先提供全部信息，也不必在缺少数据时直接失败；它可以暂停当前操作，向用户请求特定输入。由此形成的交互更加灵活，服务器可以适应用户需求，而不是遵循僵化流程。

信息征询支持两种模式：

• 表单模式：服务器要求客户端向用户收集结构化数据。请求中包含 schema，客户端据此构建输入表单并验证响应。
• URL 模式：服务器提供一个由用户打开的 URL。交互在带外进行，其数据不会经过客户端，因此适合凭据输入或第三方 OAuth 授权等敏感流程。

信息征询遵循多轮往返请求（MRTR）模式。当服务器在处理 tools/call 等请求期间需要用户输入时，会返回 InputRequiredResult，其中 inputRequests 字段携带一个或多个 elicitation/create 请求。客户端收集输入后重试原请求，附上收集到的 inputResponses，并回传服务器提供的所有 requestState。

信息征询流程：

  sequenceDiagram
    participant User
    participant Client
    participant Server

    Client->>Server: tools/call (id: 1)
    Note over Server: Server needs more information
    Server-->>Client: InputRequiredResult with elicitation/create request

    Note over Client,User: Human interaction
    Client->>User: Present elicitation UI
    User-->>Client: Provide requested information

    Note over Client,Server: Retry request with user input
    Client->>Server: tools/call (id: 2, inputResponses)

    Note over Server: Continue processing with new information
    Server-->>Client: Final result

该流程支持动态收集信息。服务器可以在需要时请求特定数据，用户通过适当的 UI 提供信息，服务器再使用新获得的上下文完成重试后的请求。

信息征询请求示例（在 InputRequiredResult.inputRequests 内传递）：

{
  method: "elicitation/create",
  params: {
    mode: "form",
    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 控件（文本字段、下拉列表、复选框）提供所需信息，也可以拒绝提供并选择性说明原因，或取消整个操作。客户端在向服务器返回响应前，应按照提供的 schema 验证响应。

URL 处理：在 URL 模式下，客户端显示完整 URL，在打开前取得用户明确同意，并且绝不自动获取该 URL。客户端只知道用户是否同意；实际交互始终发生在用户与目标站点之间。

隐私注意事项：服务器不得使用表单模式请求密码、API 密钥、访问令牌或支付凭据等敏感信息。这些交互应使用 URL 模式，使数据保持带外传递，不经过客户端或 LLM 上下文。客户端应对可疑请求发出警告，并允许用户在发送前检查表单数据。

根目录

根目录为服务器操作定义文件系统边界，让客户端可以指定服务器应关注哪些目录。

概述

根目录是客户端向服务器传达文件系统访问边界的机制。它们由表示服务器可操作目录的文件 URI 组成，帮助服务器理解可用文件和文件夹的范围。根目录表达的是预期边界，并不强制实施安全限制。实际安全限制必须通过操作系统级别的文件权限和/或沙箱落实。

根目录结构：

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

根目录只能是文件系统路径，并且始终使用 file:// URI scheme。它们帮助服务器理解项目边界、工作区组织方式和可访问目录。随着用户切换项目或文件夹，根目录列表也可以变化。服务器下次请求根目录列表时会取得更新后的边界。

示例：旅行规划工作区

为多个客户行程提供服务的旅行 Agent 可以使用根目录组织文件系统访问。设想一个工作区，其中不同目录分别存放旅行规划的各类资料。

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

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

当 Agent 创建巴塞罗那行程时，行为规范的服务器会尊重这些边界：访问模板、保存新行程，并引用指定根目录内的客户文档。服务器通常会使用相对于根目录的路径访问文件，或者使用遵守根目录边界的文件搜索工具。

如果 Agent 打开 file:///Users/agent/archive/2023-trips 这样的归档文件夹，客户端会将其加入根目录列表；服务器下次请求 roots/list 时即可看到新的边界。

有关遵守根目录的完整服务器实现，请参阅官方 servers 仓库中的文件系统服务器。

设计理念

根目录是客户端与服务器之间的协调机制，不是安全边界。规范要求服务器“SHOULD respect root boundaries”，而不是“MUST enforce”这些边界，因为服务器运行的代码不受客户端控制。

当服务器可信或经过审查、用户理解根目录仅有建议性质，并且目标是防止误操作而不是阻止恶意行为时，根目录最为有效。它们适合限定上下文范围（告诉服务器关注何处）、预防意外（帮助行为规范的服务器保持在范围内），以及组织工作流（例如自动管理项目边界）。

用户交互模型

根目录通常由宿主应用根据用户操作自动管理，不过部分应用也可能提供手动根目录管理功能：

自动检测根目录：用户打开文件夹时，客户端自动将其作为根目录开放。打开旅行工作区后，客户端可以把该目录作为根目录，帮助服务器理解当前操作涉及哪些行程和文档。

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

采样

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

概述

采样让服务器无需直接集成 AI 模型或承担模型费用，也能执行依赖 AI 的任务。服务器可以请求已经具备 AI 模型访问能力的客户端代为处理，而不是自行处理。该方式让客户端完全控制用户权限和安全措施。由于采样请求发生在其他操作（例如分析数据的工具）的上下文中，并作为独立模型调用处理，因此不同上下文之间保持清晰边界，也能更高效地使用上下文窗口。

采样遵循同一种多轮往返请求流程，如信息征询一节所述，其中 InputRequiredResult 携带 sampling/createMessage 请求。

服务器还可以在采样请求中加入 tools 数组和可选 toolChoice 字段，请求模型使用工具。工具定义只在当前采样请求范围内有效，无需对应服务器自身开放的工具。客户端通过 sampling.tools capability 声明支持；服务器不得向未声明该能力的客户端发送启用工具的采样请求。详情请参阅规范中的采样。

采样流程：

  sequenceDiagram
    participant LLM
    participant User
    participant Client
    participant Server

    Client->>Server: tools/call (id: 1)
    Note over Server: Server needs an LLM completion
    Server-->>Client: InputRequiredResult with sampling/createMessage request

    Note over Client,User: Human-in-the-loop review
    Client->>User: Present request for approval
    User-->>Client: Review and approve/modify

    Note over Client,LLM: Model interaction
    Client->>LLM: Forward approved request
    LLM-->>Client: Return generation

    Note over Client,User: Response review
    Client->>User: Present response for approval
    User-->>Client: Review and approve/modify

    Note over Client,Server: Retry request with approved response
    Client->>Server: tools/call (id: 2, inputResponses)
    Server-->>Client: Final result

该流程通过多个人工介入检查点保障安全。客户端用批准后的响应重试原请求前，用户可以检查并修改初始请求和生成结果。

请求参数示例：

{
  messages: [
    {
      role: "user",
      content: {
        type: "text",
        text: "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 个航班]。用户偏好：早间出发，最多中转一次。”

客户端发起采样请求，让 AI 评估不同权衡，例如价格更低的红眼航班和时间更方便的早间航班。工具利用分析结果给出排名前三的建议。

用户交互模型

虽然并非强制要求，但采样的设计允许人工介入控制。用户可以通过多种机制保持监督：

审批控制：采样请求可以要求用户明确同意。客户端可以展示服务器要分析什么以及原因。用户可以批准、拒绝或修改请求。

透明度功能：客户端可以展示准确的提示词、模型选择和 token 限制，让用户在 AI 响应返回服务器前进行检查。

配置选项：用户可以设置模型偏好，为可信操作配置自动批准，或要求批准全部操作。客户端还可以提供敏感信息遮盖选项。

安全注意事项：客户端和服务器在采样过程中都必须妥善处理敏感数据。客户端应实施速率限制，并验证所有消息内容。人工介入设计可确保服务器请求的 AI 交互不会在未经用户明确同意的情况下危及安全或访问敏感数据。