資訊徵詢

MCP 的 資訊徵詢（Elicitation）讓伺服器能在處理請求期間，透過用戶端向使用者取得額外資訊；用戶端仍掌握使用者互動與資料分享的控制權。

Elicitation 支援兩種模式：

• 表單模式（Form mode）：透過 MCP 用戶端蒐集結構化資料，並可使用受限 JSON Schema 驗證。
• URL 模式（URL mode）：把使用者導向外部 URL 完成敏感互動；除了 URL 本身之外，敏感資料不得經過 MCP 用戶端。

使用者互動模型（User Interaction Model）

Elicitation 可巢狀出現在其他 MCP server feature 的處理流程中。協定不強制特定 UI，但用戶端必須維持清楚的來源與同意邊界。

MCP 用戶端 MUST（必須）：

• 清楚顯示是哪一個 server 正在要求資訊。
• 尊重使用者隱私，並提供明確的 decline 與 cancel 選項。
• Form mode 必須允許使用者在送出前檢視並修改回覆。
• URL mode 必須先顯示目標 domain/host，取得使用者同意後才能導向。

能力宣告（Capabilities）

支援 Elicitation 的用戶端 MUST（必須）在每個 request 的 _meta.io.modelcontextprotocol/clientCapabilities 宣告 elicitation capability：

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

為向後相容，空的 elicitation: {} 等同只支援 form mode。宣告 Elicitation 的 client MUST（必須）至少支援 form 或 url 其中一種；server MUST NOT（不得）要求 client 未宣告的 mode。

協定訊息（Protocol Messages）

Server 在處理用戶端 request 時，MAY（可以）回傳 InputRequiredResult，並在 inputRequests 中放入 elicitation/create。所有 elicitation request 都必須提供人類可讀的 message，並以 mode 指定 form 或 url；為向後相容，form mode MAY（可以）省略 mode，而 client MUST（必須）把缺少 mode 的 request 視為 form mode。

欄位	說明
mode	form 或 url；form 可省略並預設為 form。
message	向使用者說明為什麼需要這次互動的人類可讀文字。

表單模式（Form Mode）

Form mode request MUST（必須）明確指定 mode: "form" 或省略 mode，並 MUST（必須）包含 requestedSchema。該 schema 描述預期回覆；為簡化使用者體驗，只允許 flat object 與 primitive property，支援 string、number/integer、boolean，以及單選／多選 enum。

String 可使用 email、uri、date、date-time format；各 primitive 可提供 default。支援 default 的 client SHOULD（應該）預先填入表單。

複雜 nested object、一般 object array 與其他進階 JSON Schema feature 刻意不在此模式支援範圍。

{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "請提供您的 GitHub 使用者名稱",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": { "type": "string" }
      },
      "required": ["name"]
    }
  }
}

使用者接受後，用戶端把結果放進 MRTR 重試 request 的 inputResponses：

{
  "action": "accept",
  "content": { "name": "octocat" }
}

URL 模式（URL Mode）

URL mode 用於必須離開 MCP client 完成的敏感或安全互動，例如 API key 設定、付款流程或第三方 OAuth。Request MUST（必須）指定 mode: "url"、message 與有效的 url；url MUST（必須）是有效 URL。

{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "請完成 API key 設定後繼續。"
  }
}

action: "accept" 只代表使用者同意前往該 URL，不代表外部互動已完成。Client 重試原 request 後，server 依 requestState 或自己的 state 判斷是否完成；若尚未完成，可再次回 InputRequiredResult。Client SHOULD（應該）提供手動重試或取消控制。

回應動作（Response Actions）

Form 與 URL mode 共用三種 action：

• accept：使用者明確同意。Form mode 的 content 包含送出的資料；URL mode 不帶 content。
• decline：使用者明確拒絕。
• cancel：使用者關閉或中斷互動，沒有做出明確同意或拒絕。

Server SHOULD NOT（不應）假設 elicitation 一定成功，並 MUST（必須）妥善處理使用者 decline / cancel，或 client 無法處理 elicitation request 的情況。

狀態與身分（Statefulness and Identity）

MRTR 讓 elicitation 不必要求 server 保存協定層狀態；但 server 若自行保存 state，MUST（必須）安全地把 state 綁定到個別使用者，而且 state storage MUST（必須）防止未授權存取。遠端 MCP server 在可行時，使用者身分 MUST（必須）來自 MCP Authorization 所取得並由 server 驗證的 credentials，例如 token 的 sub。

第三方授權（Third-party Authorization）

URL mode 可以讓 MCP server 自己成為第三方 API 的 OAuth client。這時存在兩組完全不同的授權邊界：

• MCP Authorization：MCP client ↔ MCP server。
• 第三方 Authorization：MCP server ↔ 第三方 resource server。

第三方 credentials MUST NOT（不得）經過 MCP client；MCP server 也 MUST NOT（不得）拿 MCP client 的 token 當第三方 token passthrough。使用者 MUST（必須）直接授權 MCP server 存取第三方服務，而不是把第三方授權交給 MCP client 代辦。第三方 token 由 MCP server 自己取得、保存並綁定到使用者身分，且透過 URL mode 取得的 credentials MUST NOT（不得）回傳給 MCP client。

安全 URL 處理（Safe URL Handling）

Server 提供 elicitation 時：

• URL mode MUST NOT（不得）把 credentials、PII 或其他敏感使用者資訊放在 URL。
• URL mode MUST NOT（不得）提供已預先認證、拿到 URL 即可冒用使用者的 protected-resource URL。
• Form mode request 的任何欄位 SHOULD NOT（不應）包含意圖讓使用者點擊的 URL。
• 非開發環境 SHOULD（應該）使用 HTTPS URL。

實作 URL mode 的 client MUST（必須）謹慎處理 URL：

• MUST NOT（不得）自動 pre-fetch URL 或 metadata。
• MUST NOT（不得）在沒有明確使用者同意時開啟 URL。
• MUST（必須）先顯示完整 URL，並以安全方式開啟，使 client 或 LLM 無法檢視使用者輸入。
• SHOULD（應該）醒目標示 domain，並對 Punycode 等可疑 URI 提示警告。
• 除了 URL mode request 的 url 欄位外，SHOULD NOT（不應）把 elicitation request 其他欄位中的 URL render 成可點擊連結。

安全考量（Security Considerations）

1. Server MUST（必須）把 elicitation request 綁定到正確 client 與 user identity。
2. Server MUST NOT（不得）把 client 自行提供、未經 server 驗證的 user identification 當成可信身分；應優先依 MCP Authorization 等受驗證來源辨識使用者。
3. Client MUST（必須）清楚指出資訊要求來自哪一個 server。
4. Client SHOULD（應該）實作使用者 approval controls，允許使用者隨時 decline，並清楚呈現正在要求哪些資訊及理由。
5. Form mode MUST NOT（不得）索取 password、API key 等敏感資訊。
6. Client SHOULD（應該）依 requested schema 驗證回覆；server 也 SHOULD（應該）再次驗證。
7. URL mode 的 server MUST（必須）確認「觸發 elicitation 的使用者」和「實際開啟 URL／完成外部流程的使用者」是同一人，避免 phishing/account-takeover。