MCP 的 Tools、Resources、Prompts 與 Sampling 如何分工？

為什麼「能力」不能都叫工具？

當 Host 連上一個 MCP Server，它需要知道的不只是「這裡有功能」。它還要區分：這個東西是可以執行的操作、可以讀取的資料、由使用者選擇的提示模板，還是請求模型產生文字的協作機制。四者的輸入、控制者和風險不同；混在一起會讓權限提示和使用者預期都變得模糊。

Tools：可以造成外部效果的操作

Tool 是 Server 提供、Client 可以呼叫的可執行能力，例如查詢天氣、搜尋資料或建立一筆記錄。Client 先透過 tools/list 發現工具的名稱、說明和輸入 schema（欄位規格），再用 tools/call 傳入參數。

Tool 的關鍵不是「模型可以自由執行函式」，而是它可能有副作用。讀資料、刪檔案、送出付款請求的風險完全不同，所以 Host 應讓使用者看懂目前暴露了哪些工具，並在需要時提供確認或拒絕的機會。工具的 schema 可以描述輸入格式，卻不會替 Host 完成授權決策。

Resources：可以被讀取的外部內容

Resource 是 Server 暴露給 Client 的資料項目，通常以 URI、名稱、說明與 MIME type（內容格式標記）描述。Client 可以用 resources/list 發現可用資源，再以 resources/read 取得內容；Resource 也可以透過 URI template（可填入參數的 URI 樣板）表示一組可參數化的資料。

把 Resource 看成「可讀取的內容入口」會比把它當成另一種 Tool 更準確。它可以是檔案、文件或其他資料來源，但「唯讀」不代表沒有風險：資料仍可能含有敏感內容，URI 仍需要授權與驗證，Host 仍要決定哪些內容可以放進模型上下文。

Prompts：由使用者選擇的提示模板

Prompt 是 Server 提供的結構化提示模板。Client 可以用 prompts/list 發現它們，再用 prompts/get 加上參數取得訊息。和「模型自行決定是否呼叫」不同，Prompts 的設計是讓使用者明確選擇何時使用；提示內容則由 Server 定義。

例如，Server 可以提供一個「檢查這段程式碼」模板，使用者從 Host 的介面選取後，Client 才把模板和參數交給模型。這種能力適合重複工作流程，不應被描述成 Server 可以偷偷改寫使用者的 system prompt。

Sampling：仍可互通，但已不適合新設計

Sampling 讓 Server 在處理 Client 已發起的請求時，要求 Client 代為取得一次語言模型生成結果。它的核心想法是讓 Server 可以請求 Host 所控制的模型，而不是把模型供應商憑證交給 Server。

但這裡有一個不能省略的版本邊界：MCP 2026-07-28 已將 Sampling 標記為 deprecated（不再建議新實作採用）。既有實作仍可在相容期間使用；新實作不應再把它當成首選，官方建議改為直接整合模型供應商 API。當代的 Sampling 請求也透過 input_required 的多輪往返承載，不應再照舊版文件寫成任意的 Server-to-Client 背景請求。

因此，這一節保留 Sampling 是為了讓讀者看懂現有 Server 和舊文章，而不是推薦在新的架構中採用它。版本敏感的能力，必須同時讀規格的功能頁和 deprecated features registry，不能只看 SDK 的函式名稱。

四種能力放在一起比較

這張表是閱讀與設計的心智模型，不是把四種能力當成同一層的安全等級。真正可用的權限仍取決於 Host、Server、認證方式、傳輸和部署環境；下一篇會進入 Client 建置，而不是把這些能力直接等同於某個 Python 或 Anaconda 安裝流程。

來源與版本邊界

Tools 的發現、呼叫與人類確認原則見 MCP 2026-07-28 Tools；Resources 的列舉、讀取與 URI templates 見 Resources；Prompts 的使用者控制模型見 Prompts。Sampling 的 deprecated 狀態、能力宣告與 sampling/createMessage 流程見 Sampling。本文沒有把舊版 Anaconda 部署步驟保留成當代規格的一部分；環境與 Client 的實作選擇留給後續 entry，避免把版本敏感的安裝指令誤當成 MCP 能力定義。