AI AGENT 工具探索指南
tools/list 讓 MCP client 取得可用工具的名稱、用途與輸入規格。本文用一筆採購任務，拆解工具探索、參數驗證、授權與確認如何走到 tools/call。
直接答案：MCP client 先用 tools/list 取得機器可讀的工具目錄。語言模型從目錄挑選工具並組合參數；client 接著驗證欄位、檢查權限、顯示必要確認，再以獨立的 tools/call 請求執行。
01 · ROLES
MCP 連接把理解與執行分給四個角色
MCP 系統把一次外部動作分給 AI host、MCP client、語言模型與 MCP server。AI host 是使用者直接看到的應用程式，負責對話介面、組織政策與確認畫面。MCP client 位在 host 裡，負責向特定 server 送出協定訊息。語言模型讀取使用者需求與工具定義，產生要使用的工具和候選參數。MCP server 把庫存或採購系統包成 tools，接收呼叫後存取實際資料。
MCP 是 Model Context Protocol 的縮寫。它規定 AI 應用程式與外部服務交換資料和動作的方法。MCP 訊息採用 JSON-RPC；這是一種固定訊息格式，會標明方法名稱、請求編號、參數與對應結果。讀者不需要會寫 JSON，只要記住每個請求都清楚標示「現在要做哪一件事」。
採購助理尚未連接工具時，語言模型只看得到一句自然語言需求。MCP client 需要先向 server 詢問可用能力，後面才有工具可選。這一步使用的方法就是 tools/list。
接收使用者需求，套用組織政策，提供確認畫面與結果。
向特定 server 送出 tools/list 與 tools/call，驗證訊息格式。
比對需求與工具定義，選擇工具並產生候選參數。
宣告工具能力，接收具名呼叫，連接庫存或採購系統。
02 · CATALOG
一筆 tools/list 回應交付一份可檢查的目錄
MCP server 收到 tools/list 後，會回傳當下可用的 tool definitions。每個 definition 至少要讓 client 辨認一個具名動作與它接受的輸入。MCP 2026-07-28 規格列出幾個常見欄位：name 是程式使用的唯一名稱，title 可提供人類較容易閱讀的名稱，description 說明工具負責什麼，inputSchema 定義輸入格式，outputSchema 可定義結構化輸出，annotations 可提示工具行為。
Schema 可以理解為一張可驗證的表單規格。採購案例的 inventory_lookup 要求兩個必填字串：sku 與 warehouse。purchase_order_create 則要求料號、數量、供應商代碼與單價上限，其中數量必須是正整數。語言模型會利用名稱與說明判斷用途；MCP client 會利用 schema 檢查欄位形狀。只寫「幫我查一下」而沒有倉庫代碼時，client 應停在驗證階段，要求補足 warehouse。
Google Cloud 的產品文件把 MCP tools 稱為 actions。Gemini Enterprise 重新載入自訂 actions 時會執行一次 tools/list，把回傳項目顯示在管理介面。該預覽產品目前建議一次最多啟用 100 個 actions。100 是 Gemini Enterprise 的產品限制，MCP 協定沒有把工具目錄固定成 100 項。
工具目錄回答「server 說自己有哪些能力」。下一步要看使用者身分會讓這份目錄留下哪些項目。
inventory_lookup
查詢指定倉庫中的料號庫存。
- name
- inventory_lookup
- description
- 查詢指定倉庫的即時庫存。
- inputSchema
- sku：字串，必填
warehouse：字串，必填 - outputSchema
- available：正整數
checked_at：時間
purchase_order_create
向核准供應商建立指定數量的採購單。
- name
- purchase_order_create
- description
- 建立一張待追蹤的採購單。
- inputSchema
- sku、quantity、supplier_id、max_unit_price：必填
- annotations
- 寫入動作；host 顯示確認。
03 · AUTHORIZATION
授權會改變工具抽屜裡的內容
MCP server 可以依每次請求帶來的授權資訊，回傳不同的工具集合。訪客帳號可能只看到 inventory_lookup；採購員帳號同時看到 inventory_lookup 與 purchase_order_create；管理員帳號可能再看到供應商設定工具。MCP 2026-07-28 規格明確允許工具集合依授權而變化，因為憑證與 scope 都屬於每次請求的輸入。
Scope 是帳號獲准使用的範圍。它可能限定只讀庫存、只能操作指定倉庫，或允許建立採購單。AI host 還可以在 server 回傳後再套用 allowlist，只把組織核准的工具提供給語言模型。這兩層控制會共同決定模型實際看見的目錄。
採購案例使用採購員授權，因此兩個工具都能出現在目錄。若同一個需求改用訪客帳號，採購助理可以查到 180 顆庫存，但工具目錄沒有建立採購單的動作。語言模型此時應回報權限不足；更換提示詞不會增加工具或 scope。
切換身分，看工具集合縮小
操作前：目錄看起來像固定總表。操作後：server scope 與 host allowlist 會逐層縮小模型能選的工具。
採購員的 server 回傳 2 個工具；host 核准 2 個；模型可以查庫存與建立採購單。
04 · VALIDATION
語言模型選工具，MCP client 檢查參數
語言模型拿到 host 提供的工具目錄後，會把使用者需求與每個 tool definition 比對。採購案例先需要現在庫存，因此模型選擇 inventory_lookup，並產生 sku=FAN-48V-A3、warehouse=W-03。MCP client 依 inputSchema 確認兩個必填欄位都存在且型別正確，再送出第一筆 tools/call。
庫存系統回傳 180 顆。使用者要求 300 顆，缺口是 120 顆。這個結果造成下一個動作：語言模型準備 purchase_order_create，把 sku 設為 FAN-48V-A3、quantity 設為 120、supplier_id 設為 S-17、max_unit_price 設為 18。第二份 schema 會攔住負數數量、缺少供應商或文字型單價等格式錯誤。
Schema 只能驗證資料形狀和明文規則。它無法證明 180 顆庫存仍然最新，也無法判斷 S-17 是否仍是核准供應商。MCP client 或後端服務需要另外檢查庫存時間、供應商狀態與採購政策。格式正確和業務決策正確是兩項獨立檢查。
把輸入送過四道檢查
操作前：格式、權限、確認與結果容易被合併成一件事。操作後：每一層會在自己的失效條件停下。
- 01Schema
- 02Scope 與政策
- 03使用者確認
- 04後端結果
05 · EXECUTION
tools/call 送出前還有確認門
MCP client 準備送出 purchase_order_create 時，AI host 應把會改變資料的內容清楚顯示給使用者：料號 FAN-48V-A3、數量 120、供應商 S-17、單價上限 18 美元。使用者確認後，client 才送出第二筆 tools/call。MCP server 接著呼叫採購系統，建立單據並回傳單號；使用者拒絕時，流程停在確認畫面。
tools/list 與 tools/call 的方法名稱已經揭示分工。tools/list 交付工具目錄，tools/call 要求執行具名工具。目錄可以協助模型選擇，沒有執行外部動作。寫入權限、使用者確認、後端交易檢查與稽核紀錄都發生在後續層次。
Tool definition 可以帶 readOnlyHint、destructiveHint 等 annotations。這些欄位能幫 host 決定確認介面。MCP 規格同時要求 client 把不受信任 server 提供的 annotations 視為不受信任資訊。server 若把刪除工具錯標成只讀，annotation 本身攔不住刪除。確定性的 OAuth scope、host policy、網路控制、沙箱與人工確認仍要承擔安全責任。
一項工具從目錄走到執行，至少跨過發現、授權、參數、確認與後端五個責任位置。任一層的通過結果都不能代替下一層。
tools/list
取得工具目錄輸出名稱、說明、schema 與行為提示。這一步沒有寫入庫存或採購系統。
CONFIRM
tools/call
執行一個具名工具client 送出已驗證參數，server 接觸實際系統；後端仍需完成交易與結果檢查。
06 · BOUNDARIES
用三個問題檢查新的 MCP server
MCP client 還要處理目錄的時效與品質。MCP 2026-07-28 的 list 回應可以提供 ttlMs 與 cache scope，讓 client 暫存工具目錄；server 也能在工具集合改變時通知 client。過期 cache 可能留下已停用工具，或漏掉剛加入的工具。含糊的 description 會讓模型選錯工具；過寬的 schema 會讓不必要參數通過；格式正確的 server 回傳仍可能包含過期或錯誤資料。
評估新 MCP server 時，先問三個問題。第一，tools/list 列了哪些名稱、用途、必填欄位與輸出？第二，使用者目前的 scope 和 host allowlist 實際允許哪些工具？第三，執行前由哪一層驗證參數、顯示確認並檢查結果？這三題分別對應目錄、授權與執行控制。
回到開頭的採購任務，MCP client 先取得工具目錄，語言模型才知道可以查庫存和建立採購單；採購員 scope 決定兩個工具都可見；schema 讓 client 檢查欄位；確認門保留寫入決定；tools/call 最後才接觸庫存與採購系統。把同一套方法移到人資 server 時，讀者也能逐項檢查查詢員工、建立帳號與停權工具，不會把「看得到」誤認成「有權執行」或「已經安全」。
cache 要有期限；工具集合改變時要重新整理；庫存時間仍需後端確認。
含糊名稱或 description 可能讓模型挑錯工具，過寬 schema 也會放過多餘輸入。
annotation 協助介面判斷；權限、政策、確認與後端控制承擔確定性限制。
逐項讀 name、description、必填欄位、輸出與行為提示。
核對 server scope 與 host allowlist，確認模型實際可選集合。
找出 schema、業務政策、使用者確認、後端交易與結果核對的責任位置。
某個人資 MCP server 宣告查詢員工、建立帳號與停權三項工具。一般主管只獲得查詢 scope；IT 管理員可建立帳號，但 host allowlist 暫時排除停權。請依序寫出一般主管與 IT 管理員各自的工具目錄、建立帳號需要的 schema 欄位、應出現的確認內容，以及停權為何不會進入模型可選集合。
