本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
工具範圍
有兩種開發工具的方法：精細和粗粒。
精細
在精細的方法中，您會為每個 API、動作或查詢建立工具。例如，您可以為 Git get_issue儲存庫建立 create_issue、assign_issue、、 add_label和 close_issue工具。這可讓 LLM 對每個 API 進行精細呼叫，並視需要協調每個 API。考慮以下提示：「為名為「僅查詢傳回部分結果」的產品服務建立問題，將其標記為錯誤和高優先順序，並將其指派給 Alice。」 下圖顯示每個 tool-per-API方法如何回應此提示。
在此方法中，系統提示和每個已註冊的工具定義會在每次呼叫時提供給 LLM。這會消耗額外的內容並產生延遲懲罰，因為每個工具呼叫代表對 LLM 的個別呼叫。它也會增加在工作流程中處理錯誤的複雜性。
粗粒
粗略粒度或工作流程驅動的方法將是工作流程導向的工具。此工具著重於end-to-end使用者對 API 結構的意圖。您有一個工具可確定地呼叫許多 APIs，而不是tool-per-API 的工具。使用先前的 Git 儲存庫範例，您可以建立由代理程式呼叫一次create_and_setup_issue的工具。工具實作會根據提供給工具的參數，建立問題、新增標籤，並將其指派給使用者。下圖顯示粗粒方法如何處理相同的提示。
此方法顯示 LLM 層如何隱藏所有複雜性。當協同運作邏輯內嵌在工具實作中時，所有循序步驟、記錄、重試邏輯、斷路器和速率限制都會在工具中決定性地執行。工作流程驅動型方法可讓 LLM 更輕鬆地使用正確的參數叫用正確的工具。請務必注意，某些 APIs可能已經提供工作流程意圖，例如 Amazon EC2 RunInstances API。在這些情況下，tool-per-API可能會提供您想要的工作流程導向設計。
不過，工具也可能變得太粗粒。如果您的單一工作流程工具嘗試執行太多動作，並且有許多可能的參數，LLM 可能會難以判斷如何正確使用工具。它也可以透過參數選擇和錯誤處理來產生挑戰。因此，工具開發必須達到與使用者意圖一致的平衡，並避免單一工具中的功能太少或太多。我們建議您根據完整的使用者工作流程設計工具，綁定通常一起發生的操作 （例如三個或更多的 API 呼叫）。我們也建議您分解超過八個或更多參數的工具，或處理多個不同的使用者意圖。使用實際提示 進行測試，以確認客服人員是否可以正確使用每個工具。
如果您有複雜且動態的工作流程，無法輕鬆地封裝為確定性工具，您可以考慮使用agent-as-tool模式。專門的代理程式可以充當工具，而不是您的主要代理程式嘗試在工作流程中協調複雜的任務。這些類型的工具可以實作進階決策和分支，而且可以處理無法在確定性程式碼中輕鬆管理的錯誤和重試邏輯。這類似於但不同於 Agent2Agent (A2A) 通訊協定
我們建議您從工作流程分析開始，映射最常見的使用者工作流程，以識別每個客服人員所需的核心功能。這會建立您的最低可行工具集。根據我們大規模開發 MCP 伺服器的經驗，我們建議下列實務。當這些實務發生衝突時，請優先考慮使用者意圖和工作流程。
MCP 工具範圍的最佳實務
-
思考使用者案例並綁定常見操作 – 工具應直接映射以完成使用者互動，而不是需要協調多個操作。如果工作流程通常需要三個以上的個別呼叫，請將它們合併為單一工具。這可減少 LLM 的認知負載、將工具呼叫次數降至最低、減少完成任務所需的內容耗用和延遲，並改善準確性和延遲。
-
將參數限制為八個或更少 – 如果工具超過八個參數，請將它分解為多個工具。隨著複雜性的增加，LLMs難以選擇參數。
注意
如果綁定操作需要八個以上的參數，則優先於參數計數的綁定，因為簡化工作流程比嚴格的參數限制更有價值。
-
個別的讀取和寫入操作 – 提供不同的工具來讀取資料並進行修改。當客服人員執行潛在破壞性操作、啟用不同的授權政策，並降低在資訊收集期間意外修改的風險時，這種區隔會明確顯示。
-
提供合理的預設值 – 設計工具，讓 LLM 只需要指定個別請求特有的參數。預設值可降低 LLM 必須考量的資訊，藉此降低參數複雜性並改善工具選擇的準確性。
-
偏好確定性執行 – 盡可能讓工具執行和輸出確定性。確定性工具更可靠且更容易測試。對於需要智慧型協同運作、分支邏輯或進階錯誤處理的複雜工作流程，如果無法在確定性程式碼中輕鬆管理，請考慮使用專用代理程式做為工具。不過，請選擇性地使用此模式，因為它會增加複雜性。
