烂翻译系列之——MCP中的概念——客户端
MCP clients are instantiated by host applications to communicate with particular MCP servers. The host application, like Claude.ai or an IDE, manages the overall user experience and coordinates multiple clients. Each client handles one direct communication with one server.
MCP 客户端由宿主应用程序（host application）实例化，用于与特定的 MCP 服务端进行通信。宿主应用程序（例如 Claude.ai 或一个集成开发环境 IDE）负责管理整体用户体验，并协调多个客户端。每个客户端负责与一个服务端建立直接通信。
Understanding the distinction is important: the host is the application users interact with, while clients are the protocol-level components that enable server connections.
Core Client Features 核心客户端功能
In addition to making use of context provided by servers, clients may provide several features to servers. These client features allow server authors to build richer interactions.
除了利用服务端提供的上下文外，客户端还可以向服务端提供若干功能。这些客户端功能使服务端开发者能够构建更丰富的交互体验。
|
Feature 功能特性 |
Explanation 说明 |
Example 示例 |
|---|---|---|
|
Sampling 采样 |
Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. 采样功能允许服务端通过客户端请求大语言模型（LLM）的补全结果，从而实现代理式（agentic）工作流。该机制将用户权限和安全措施的控制权完全交由客户端掌握。 |
A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user. 一个旅行预订服务端可将航班列表发送给 LLM，并请求模型为用户挑选最佳航班。 |
|
Roots 根目录 |
Roots allow clients to specify which files servers can access, guiding them to relevant directories while maintaining security boundaries. 根目录功能允许客户端指定服务端可访问的文件路径，引导服务端访问相关目录的同时，确保安全边界不被突破。 |
A server for booking travel may be given access to a specific directory, from which it can read a user’s calendar. 旅行预订服务端可被授权访问某个特定目录，从中读取用户的日程文件。 |
|
Elicitation 信息征询 |
Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand. 信息征询功能使服务端能够在交互过程中向用户请求特定信息，为服务端按需获取数据提供结构化方式。 |
A server booking travel may ask for the user’s preferences on airplane seats, room type or their contact number to finalise a booking. 旅行预订服务端可询问用户对飞机座位的偏好、房间类型偏好或联系方式，以完成预订。 |
Elicitation 信息征询
Elicitation enables servers to request specific information from users during interactions, creating more dynamic and responsive workflows.
Overview 概述
Elicitation provides a structured way for servers to gather necessary information on demand. Instead of requiring all information up front or failing when data is missing, servers can pause their operations to request specific inputs from users. This creates more flexible interactions where servers adapt to user needs rather than following rigid patterns.
信息征询为服务端提供了一种按需获取必要信息的结构化机制。服务端无需在开始时获取全部信息，也不必在数据缺失时直接失败，而是可以在操作过程中暂停，并向用户请求具体输入。这使得交互更加灵活，服务端能够根据用户需求动态调整，而非遵循僵化的流程。
Elicitation flow: 信息征询流程：
The flow enables dynamic information gathering. Servers can request specific data when needed, users provide information through appropriate UI, and servers continue processing with the newly acquired context.
该流程支持动态的信息收集。服务端可在需要时请求特定数据，用户通过合适的UI提供信息，服务端随后利用新获取的上下文继续处理任务。
Elicitation components example: 信息征询组件示例：
{
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"]
}
}
}Example: Holiday Booking Approval 示例：假期预订确认
A travel booking server demonstrates elicitation’s power through the final booking confirmation process. When a user has selected their ideal vacation package to Barcelona, the server needs to gather final approval and any missing details before proceeding.
一个旅行预订服务端通过最终预订确认流程，展示了信息征询（Elicitation）的强大功能。当用户已选择理想的巴塞罗那度假套餐后，服务端在继续执行预订前，需要获取用户的最终确认以及任何缺失的细节。
The server elicits booking confirmation with a structured request that includes the trip summary (Barcelona flights June 15-22, beachfront hotel, total $3,000) and fields for any additional preferences—such as seat selection, room type, or travel insurance options.
服务端通过一个结构化请求发起征询，内容包括行程摘要（巴塞罗那，6月15日至22日航班、海滨酒店，总价3000美元），并附上用于填写额外偏好的字段——例如座位选择、房型偏好或旅行保险选项。
As the booking progresses, the server elicits contact information needed to complete the reservation. It might ask for traveler details for flight bookings, special requests for the hotel, or emergency contact information.
随着预订流程的推进，服务端进一步征询完成预订所需的联系信息。例如，它可能会请求旅客的详细信息（用于机票预订）、酒店特殊需求，或紧急联系人信息。
User Interaction Model 用户交互模型
Elicitation interactions are designed to be clear, contextual, and respectful of user autonomy:
信息征询（Elicitation）的交互设计旨在清晰、有上下文支持，并尊重用户的自主权：
Request presentation: Clients display elicitation requests with clear context about which server is asking, why the information is needed, and how it will be used. The request message explains the purpose while the schema provides structure and validation.
请求呈现：客户端会清晰地展示征询请求，说明是哪个服务端发起的请求、为何需要该信息以及信息将如何使用。请求消息解释其目的，而数据模式（schema）则提供结构化格式和输入验证依据。
Response options: Users can provide the requested information through appropriate UI controls (text fields, dropdowns, checkboxes), decline to provide information with optional explanation, or cancel the entire operation. Clients validate responses against the provided schema before returning them to servers.
响应选项：用户可通过合适的UI控件（如文本框、下拉菜单、复选框）提供所需信息；也可选择拒绝提供信息（可附带说明原因），或直接取消整个操作。客户端会在将响应返回给服务端前，根据提供的 schema 对用户输入进行验证。
Privacy considerations: Elicitation never requests passwords or API keys. Clients warn about suspicious requests and let users review data before sending.
隐私考量：信息征询绝不允许请求密码或 API 密钥等敏感凭证。客户端会对可疑的请求发出警告，并允许用户在发送前预览和审查所提交的数据，以保障隐私与安全。
Roots 根目录
Roots define filesystem boundaries for server operations, allowing clients to specify which directories servers should focus on.
Overview 概述
Roots are a mechanism for clients to communicate filesystem access boundaries to servers. They consist of file URIs that indicate directories where servers can operate, helping servers understand the scope of available files and folders. Rather than giving servers unrestricted filesystem access, roots guide them to relevant working directories while maintaining security boundaries.
根目录是一种客户端向服务端传达文件系统访问边界的机制。它由文件 URI 组成，指向服务端可以操作的目录，帮助服务端了解可用文件和文件夹的范围。通过根目录，客户端无需向服务端开放整个文件系统，而是引导其访问特定的相关工作目录，从而在提供功能性的同时保障系统安全。
Root structure: 根目录结构：
{
"uri": "file:///Users/agent/travel-planning",
"name": "Travel Planning Workspace"
}Roots are exclusively filesystem paths and always use the file:// URI scheme. They help servers understand project boundaries, workspace organization, and accessible directories. The roots list can be updated dynamically as users work with different projects or folders, with servers receiving notifications through roots/list_changed when boundaries change.
根目录仅限于文件系统路径，且始终使用 file:// URI 方案。它们帮助服务端理解项目边界、工作区结构以及可访问的目录。随着用户切换不同的项目或文件夹，根目录列表可以动态更新；当访问边界发生变化时，服务端会通过 roots/list_changed 通知收到更新。
It’s important to note that while roots provide guidance to servers about where to operate, the client is always in full control of file access. Roots simply communicate intended boundaries—actual file access is always mediated by the client’s security policies.
需要特别注意的是，尽管根目录为服务端指明了操作范围，但文件访问的实际控制权始终在客户端。根目录仅用于传达预期的访问边界，所有文件读写操作仍由客户端根据其安全策略进行中介和管控。
Example: Travel Planning Workspace 示例：旅行规划工作区
A travel agent working with multiple client trips benefits from roots to organize filesystem access. Consider a workspace with different directories for various aspects of travel planning.The client provides filesystem roots to the travel planning server:
一位处理多个（客户）行程的旅行agent可通过根目录来有效组织文件系统的访问权限。假设其工作区包含多个用于不同用途的目录。
The client provides filesystem roots to the travel planning server:
客户端向旅行规划服务端提供以下文件系统根目录：
file:///Users/agent/travel-planning- Main workspace containing all travel files 主工作区，包含所有旅行相关文件file:///Users/agent/travel-templates- Reusable itinerary templates and resources 可复用的行程模板和资源file:///Users/agent/client-documents- Client passports and travel documents 客户护照和旅行证件
When the agent creates a Barcelona itinerary, the server works within these boundaries—accessing templates, saving the new itinerary, and referencing client documents. It cannot access files outside these roots. Servers typically access files within roots by using relative paths from the root directories or by utilizing file search tools that respect the root boundaries.
当agent创建巴塞罗那行程方案时，服务端会在既定根目录范围内进行操作——包括访问模板文件、保存新行程方案以及引用客户文档。它无法越权访问这些根目录之外的文件。服务端通常通过两种方式访问根目录内的文件：使用从根目录出发的相对路径，或利用遵循根目录边界约束的文件搜索工具。
If the agent opens an archive folder like file:///Users/agent/archive/2023-trips, the client updates the roots list via roots/list_changed.
如果agent随后打开了一个归档文件夹（如 file:///Users/agent/archive/2023-trips），客户端将通过 roots/list_changed 通知更新根目录列表，使服务端能够临时访问该归档目录。
User Interaction Model 用户交互模型
Roots are typically managed automatically by host applications based on user actions, though some applications may expose manual root management:
根目录通常由宿主应用程序根据用户的操作自动管理，但部分应用程序也可能提供手动配置根目录的功能：
Automatic root detection: When users open folders, clients automatically expose them as roots. Opening a travel workspace gives servers access to itineraries and documents within that directory.
自动根目录识别：当用户打开某个文件夹时，客户端会自动将其作为根目录公开给服务端。例如，用户打开一个旅行规划工作区后，服务端即可访问该目录内的行程单和相关文档。
Manual root configuration: Advanced users can specify roots through configuration. For example, adding /travel-templates for reusable resources while excluding directories with financial records.
手动根目录配置：高级用户可通过配置手动指定根目录。例如，添加 /travel-templates 目录以供服务端访问可复用资源，同时排除包含财务记录的敏感目录，以增强安全性和访问控制。
Sampling 采样
Sampling allows servers to request language model completions through the client, enabling agentic behaviors while maintaining security and user control.
Overview 概述
Sampling enables servers to perform AI-dependent tasks without directly integrating with or paying for AI models. Instead, servers can request that the client—which already has AI model access—handle these tasks on their behalf. This approach puts the client in complete control of user permissions and security measures. Because sampling requests occur within the context of other operations—like a tool analyzing data—and are processed as separate model calls, they maintain clear boundaries between different contexts, allowing for more efficient use of the context window.
采样使服务端能够在不直接集成或支付 AI 模型费用的情况下执行依赖 AI 的任务。相反，服务端可以请求客户端（已具备 AI 模型访问权限）代表其处理这些任务。该机制将用户权限和安全控制的主导权完全保留在客户端手中。由于采样请求通常发生在其他操作的上下文中（例如某个工具在分析数据时需要 AI 辅助），并且这些请求会作为独立的模型调用进行处理，因此能够在不同上下文之间保持清晰的边界，从而更高效地利用模型的上下文窗口（context window）。
Sampling flow: 采样流程：
The flow ensures security through multiple human-in-the-loop checkpoints. Users review and can modify both the initial request and the generated response before it returns to the server.
该流程通过多个“人工介入审核”（human-in-the-loop）的检查点来确保安全性。用户可以审查并修改初始请求，以及在请求返回服务端之前，审查并修改模型生成的响应。
Request parameters example: 请求参数示例：
{
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
}Example: Flight Analysis Tool 示例：航班分析工具
Consider a travel booking server with a tool called findBestFlight that uses sampling to analyze available flights and recommend the optimal choice. When a user asks “Book me the best flight to Barcelona next month,” the tool needs AI assistance to evaluate complex trade-offs.
思考一个旅行预订服务端，其包含一个名为 findBestFlight 的工具，该工具通过采样功能调用 AI 来分析可用航班并推荐最佳选择。当用户提出“下个月帮我预订去巴塞罗那的最佳航班”时，该工具需要借助 AI 来评估复杂的权衡因素。
The tool queries airline APIs and gathers 47 flight options. It then requests AI assistance to analyze these options: “Analyze these flight options and recommend the best choice: [47 flights with prices, times, airlines, and layovers] User preferences: morning departure, max 1 layover.”
该工具首先查询航空公司 API，收集到 47 个航班选项。随后，它发起一次 AI 采样请求以进行分析：“请分析以下航班选项并推荐最佳选择：[包含价格、时间、航空公司和中转信息的 47 个航班]。用户偏好：早上出发，最多一次中转。”
The client initiates the sampling request, allowing the AI to evaluate trade-offs—like cheaper red-eye flights versus convenient morning departures. The tool uses this analysis to present the top three recommendations.
User Interaction Model 用户交互模型
While not a requirement, sampling is designed to allow human-in-the-loop control. Users can maintain oversight through several mechanisms:
虽然并非强制要求，但采样的设计初衷是支持“人工介入审核”的控制机制，使用户能够保持对流程的监督。具体可通过以下几种方式实现：
Approval controls: Sampling requests may require explicit user consent. Clients can show what the server wants to analyze and why. Users can approve, deny, or modify requests.
审批控制：采样请求可能需要用户的明确同意。客户端可展示服务端希望分析的内容及其原因，用户可选择批准、拒绝或修改请求内容。
Transparency features: Clients can display the exact prompt, model selection, and token limits, allowing users to review AI responses before they return to the server.
透明性功能：客户端可显示实际发送的提示词、所选模型以及 token 限制等信息，允许用户在响应返回服务端前，有机会审查 AI 生成的内容。
Configuration options: Users can set model preferences, configure auto-approval for trusted operations, or require approval for everything. Clients may provide options to redact sensitive information.
配置选项：用户可设置模型偏好，为可信操作配置自动批准，或对所有请求都要求手动确认。客户端还可提供选项，用于自动脱敏或隐藏敏感信息。
Security considerations: Both clients and servers must handle sensitive data appropriately during sampling. Clients should implement rate limiting and validate all message content. The human-in-the-loop design ensures that server-initiated AI interactions cannot compromise security or access sensitive data without explicit user consent.
安全考量：在采样过程中，客户端和服务端都必须妥善处理敏感数据。客户端应实施速率限制，并验证所有消息内容。通过“人工介入审核”的设计，确保由服务端发起的 AI 交互不会在未经用户明确许可的情况下危及安全或访问敏感信息。
浙公网安备 33010602011771号