双向会话：server 反过来驱动 client

延续 01–02 的 GitHub server 场景：助手已经能读 issue、查 PR。这一章再加一个 文档总结 server——它收到一篇超长文档，却不自带模型，而是反过来请 client 用用户的模型来总结。这个"server 借模型"的动作，就是本章的主角。

3.1控制流为什么能反向

02 的 JSON-RPC 会话是持久且对称的，因此 server 可以回头向 client 发请求——这正是 MCP 区别于无状态工具 API 的根本。

底层机制（比文档深一层）：对称性在 02 就埋好了——JSON-RPC 不区分谁是 client、谁是 server，任何一端都能发 request、收 response。无状态工具 API 之所以做不到反向，不是缺一个 API，而是缺那条一直开着的连接：HTTP 请求-响应打完即走，server 手里没有指向 client 的回路。MCP 的会话保留了这条回路，于是 server→client 的请求有处可发。具体有三类，全部由 server 发起、client 应答：sampling（请 client 跑一次 LLM）、roots（问 client 允许操作哪些目录）、elicitation（请 client 向用户要一段结构化输入）。三者方向一致，都是平时被当成"被动方"的 server 反客为主。

3.2sampling：server 借用 client 的模型

sampling/createMessage 让 server 请 client 的 LLM 补全一段 prompt——server 因此不必自带模型，借用 host 的就行。

底层机制（比文档深一层）：这是 MCP 最关键、也最反直觉的一招——server 保持模型无关（model-independent）：它不需要任何 LLM SDK，也不需要自己的 API key。文档总结 server 收到 50 页文档，自己不调任何模型，而是把"请总结这段内容"打包成 sampling/createMessage 发给 client；client 用用户配置的模型（Claude、GPT、Gemini 都行）跑完，把补全结果回给 server。server 从头到尾没碰过模型权重，却完成了一次推理。这条反转还带来两个硬约束：

• human-in-the-loop：server 借的是用户的模型、用户的额度，所以 client 应当用一道用户确认来把关每次 sampling——让人看到"这个 server 想用你的模型跑这段 prompt"，可以拦下。控制权仍在 host 手里。
• modelPreferences 只能给倾向，点不到具体模型：server 不能直接点名某个具体模型（如 claude-3-opus）。它只能发抽象的 costPriority / speedPriority / intelligencePriority（0..1 的权重）外加建议性的 hints；client 可以无视或重映射——server 提示 claude-3-sonnet，client 完全可以改用 Gemini。模型选择的最终决定权，留在持有模型的那一端。

2025-11-25 修订版还给 sampling 加上了带工具调用的能力：server 发起的这次 sampling 里，模型可以再触发工具，从而在 server 侧跑一个 agentic 循环。反向请求不再只是"补全一段文本"，而能驱动一整段自主推理。

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "用三句话总结这篇文档：\n\n<50 页正文>"
        }
      }
    ],
    "modelPreferences": {
      "hints": [{ "name": "claude-3-sonnet" }],
      "costPriority": 0.3,
      "speedPriority": 0.2,
      "intelligencePriority": 0.8
    },
    "maxTokens": 400
  }
}

注意 method 是 server 发出的——在 02 的 GitHub 场景里，method 总是 client 发的 tools/call；这里方向反了过来。hints 里的 claude-3-sonnet 只是建议，client 可以换成任何模型；三个 priority 给的是"省钱 / 求快 / 要聪明"的相对权重，而非硬指标。

3.3roots：client 划出可操作的边界

client 通过 roots 告诉 server"你被允许在这些目录/URI 范围内操作"；server 用 roots/list 来问，URI 必须是 file://。

底层机制（比文档深一层）：server 发 roots/list（又一个 server→client 请求），client 回一组 root URI。规范限定这些 URI 必须是 file://——roots 表达的是文件系统边界，不是任意网络地址。它和 sampling 共享同一条反向回路，只是用途从"借模型"变成"问作用域"。当用户授权的目录变化时，client 还能用 notifications/roots/list_changed 通知 server 重新拉取。本节到此为止，重点是认得它是第二类 server→client 请求。

3.4elicitation：操作中途向用户要输入

elicitation/create 让 server 在操作进行到一半时，经由 client 向用户索取一段结构化输入——用 requestedSchema 描述要什么。

底层机制（比文档深一层）：server 发 elicitation/create，附一个 requestedSchema 描述需要哪些字段；client 据此渲染一张表单给用户填，再把结果回送。用户的回复是三选一动作：accept（填了并提交）、decline（明确拒答）、cancel（直接关掉不决定）——server 必须分别处理这三种，而不是只看"有没有数据"。两条硬约束值得钉死：

• 禁止借表单要密钥：server 不得用表单式 elicitation 索取密码、token 等机密。这类敏感凭据走另一条路（见下）。
• schema 刻意保持扁平：requestedSchema 只允许原始类型字段（字符串、数字、布尔、枚举），不允许嵌套对象或数组。这不是协议没做完，而是有意的约束——扁平 schema 让 client 渲染表单这件事保持极简，任何 client 都能稳定地把它画成几个输入框，不必处理任意嵌套结构。

2025-11-25 修订版补了一条 URL-mode elicitation：当真要走 OAuth / 凭据这类敏感流程时，server 让 client 把用户引导到一个带外（out-of-band）URL 完成，并配了专门的错误码来表达这条路径——既满足"要凭据"的现实需求，又守住了"表单不碰机密"的红线。

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "elicitation/create",
  "params": {
    "message": "要把 issue 建到哪个仓库？",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "repo": { "type": "string", "title": "仓库 owner/name" },
        "assignToMe": { "type": "boolean", "title": "指派给我" }
      },
      "required": ["repo"]
    }
  }
}

requestedSchema 里只有 string 和 boolean 两个扁平字段，没有嵌套对象——这正是约束所在。client 收到后画两个输入框，用户填完以 accept 回送 { "repo": "acme/web", "assignToMe": true }，GitHub server 的建 issue 操作随即从暂停处恢复。

3.5有状态会话：嵌套才是"会话"的实质

会话保存着三样东西：协商出的 protocolVersion 与 capabilities、按 id 关联的在途请求、以及一次 sampling/elicitation 嵌套在某个工具调用内部的上下文。

底层机制（比文档深一层）：把前几节的反向请求叠到 02 的握手上，会话里实际驻留三层状态：

• 协商结果：02 握手敲定的 protocolVersion 和双方 capabilities——后续每个请求都默认在这套约定下进行。
• 在途请求关联：JSON-RPC 用 id 把 request 和 response 对上号。会话里会同时有多个请求在飞，靠 id 各认各的回包。
• 嵌套上下文（关键）：一次 sampling 或 elicitation 往往发生在某个 tools/call 还没返回的中途——GitHub server 处理 create_issue 到一半，回头发 elicitation/create 问用户仓库，拿到答复再继续把 issue 建完。外层工具调用挂起、内层反向请求嵌在里面，这种"调用套调用"的嵌套，才是把它叫会话而非无状态调用的实质。

3.6招牌能力，部署最少

sampling 是 MCP 概念上的心脏（server 借模型），却是采用率最低的能力——这个反差本身就是值得直说的洞察。

底层机制（比文档深一层）：原因直接接上 3.5 的无状态后门。server→client 请求要成立，前提是那条一直开着的回路；而无状态传输（不带 session 的纯 Streamable HTTP）根本支撑不了 server→client 请求——没有持久连接，server 无处发起反向调用。现实里大量 server 为了好部署、易扩展，选了无状态形态，于是多数已部署的 server 干脆完全跳过 sampling。结果就是这个反差：server 借用 host 模型这件事，是 MCP 区别于普通工具 API 的整个立意所在，却在真实部署里几乎没人用。