MCP 客户端特性现状：Elicitation 当立，Roots 与 Sampling 已弃用（SEP-2577）

写 MCP 客户端前必须知道的一件事：2026-07-28 规范版通过 SEP-2577 弃用了 Roots 与 Sampling 两个客户端特性——按特性生命周期政策，两者在规范中保留至少 12 个月，新实现 SHOULD NOT 采用；三者中唯一保留并持续演进的是 Elicitation，且它扩展出了全新的 URL 模式。本文基于 2026-09-08 重抓的三份官方规范页逐条拆解现状、弃用背景与迁移方向，供存量实现对照迁移。

1. 现状总览：一保留、两弃用

两条通用的生命周期规则：弃用特性在规范中保留至少 12 个月（自该版发布起算），到期才可移除；新实现 SHOULD NOT 采用弃用特性，存量实现 SHOULD 迁移。

2. Elicitation：保留者的双模式设计

Elicitation 让服务器在处理请求的过程中，经客户端向用户请求额外信息——客户端保持对用户交互与数据共享的控制权。2026-07-28 版把它扩展成两种模式：

Form 模式：结构化数据收集

服务器请求用户提供结构化数据，可用可选的 JSON Schema 校验响应。能力声明形如 elicitation: {form: {}, url: {}}（空对象等价于仅声明 Form 模式，向后兼容）；声明方必须至少支持一种模式，服务器不得向未声明对应模式的客户端发送请求。

{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": { "form": {}, "url": {} }
    }
  }
}

URL 模式：敏感交互带外完成

服务器把用户引导到外部 URL 完成敏感交互——这类交互不经 MCP 客户端。规范给的示例是 API key 提供：请求体带 mode: "url"、目标 url 与 message；用户返回 action: "accept" 表示同意前往，但交互本身在带外进行，客户端不直接获知结果——客户端重试原请求时，服务器根据回传的 requestState 判断交互是否完成。

{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "Please provide your API key to continue."
  }
}

公告同时给了一个重要用例：URL 模式可用于承接 OAuth 授权流，与《MCP 授权机制拆解：OAuth 2.1 落进 MCP 的完整流程（2026-07-28 规范版）》里的授权链路设计直接衔接。

安全红线（MUST 级）

• 服务器 MUST NOT 用 Form 模式请求密码、API key、access token、支付凭据；
• 此类敏感交互 MUST 走 URL 模式。"敏感信息"指授予访问权或授权交易的机密与凭据；一般联系信息（姓名、邮箱、用户名）不在此列，由服务器自行斟酌、以用户可审查可拒绝为前提。

客户端侧的 MUST：UI 必须明示是哪个服务器在请求信息；提供清晰的拒绝与取消选项；Form 模式允许用户发送前审阅并修改响应；URL 模式必须展示目标域名/主机并在跳转前取得用户同意。

{
  "action": "accept",
  "content": { "propertyName": "value" }
}

（URL 模式的 accept 不含 content；另有 decline / cancel 两种动作。）

3. Roots：信息性指导的退场

Roots 的原设计：客户端向服务器暴露文件系统的"根"，告知哪些目录和文件是相关的，服务器据此聚焦操作。规范原本就写明两条限制——它是信息性指导而非访问控制，协议不强制服务器停留在 roots 内；uri 必须是 file:// URI。

弃用后的迁移方向（引自弃用声明）：把目录与文件经工具参数、资源 URI 或服务器配置传入。迁移时注意：原来指望 roots 充当"权限边界"的实现要重新设计——它从来不是访问控制，弃用只是把这件事挑明。

4. Sampling：服务器借模型通道的退场

Sampling 的原设计：服务器经客户端请求 LLM 采样（completions / generations），支持文本、音频、图像交互，可在 prompt 中带入 MCP 上下文——价值是客户端保持对模型访问、选择与权限的控制，服务器无需自己的 API key。它也有完整的配套约束： SHOULD 始终有人类在环可拒绝采样请求；客户端应提供可审阅可编辑 prompt 的 UI；带工具的采样需声明 sampling.tools 能力，服务器不得向未声明方发送。

弃用后的迁移方向：直连 LLM provider API——模型调用的控制与凭据管理回到实现方自己的 provider 集成。存量使用在 12 个月保留期内照常工作，新实现不应再声明 sampling 能力。

5. 迁移清单与常见错误

• 先盘点能力声明：roots、sampling、sampling.tools 的声明与调用点都在迁移清单上；替换顺序建议"先补替代路径、再撤旧声明"，避免功能真空。
• Roots 换成"配置传入"不是换个名字：工具参数传入路径后，路径校验与权限边界由你的实现负责——原来就不是访问控制，现在更不是。
• Sampling 替代要重做安全设计：直连 provider API 后，"客户端在环审批"的保护没有了；prompt 注入防护与费用控制需要自己实现。
• Elicitation 不要超红线：Form 模式请求 API key 是 MUST 级违规；敏感交互一律 URL 模式 + 域名展示 + 同意。
• 能力声明要精确：声明了不支持的特性或漏声明已支持的特性，都会让对端行为不可预期（服务器不得向未声明能力的客户端发送对应请求）。

6. 下一步

• 授权链路（与 Elicitation URL 模式衔接）：《MCP 授权机制拆解：OAuth 2.1 落进 MCP 的完整流程（2026-07-28 规范版）》。
• 实现层安全清单：《MCP 安全指南：官方 8 类攻击面与缓解清单》。
• stdio 本地场景的传输细节：《MCP stdio 传输详解：消息帧、进程生命周期与向后兼容（2026-07-28 规范版）》。