MCP工具設計：實用方法及權衡

當模型上下文協議（MCP）工具表現不佳時，原因往往不在協議本身，而在於工具設計。許多團隊直接暴露現有API，期望智能體自行處理其餘部分，但這常導致工具調用失敗、參數錯誤及重試，浪費上下文並降低性能。本文分析了這些失敗背後的兩大問題——臃腫與混亂，並提出了通過上下文工程優化的實用方法。

臃腫指工具定義在每次調用時加載到LLM上下文，即使未使用也會消耗資源。多個MCP服務器連接後，用户尚未提問上下文就已填滿，影響推理能力。混亂則源於語義相似的工具、過多選項及命名模糊，使LLM選擇錯誤工具或參數。常見做法是豐富工具描述，但這又會加劇臃腫。

為解決這些問題，文章介紹了多種策略。首先是改進描述和響應：清晰定義字段含義，提供自然語言映射，並優化錯誤消息。其次是採用模式約束：重命名參數以匹配LLM理解，使用枚舉限制有效值，設置默認值，減少參數數量。AWS建議每個工具的參數不超過八個。第三是重構工具和延遲加載：將多功能工具拆分為專用工具，並僅按需加載上下文，可減少高達85%的令牌消耗。第四是服務端推理：通過自選LLM的“內省工具”解釋用户自然語言查詢，返回精準指令。最後是代理工具：完全由自己的代理處理整個交互，將工具變成自然語言端點。

文章隨後通過一個模擬的K-12內容搜索API的六個版本進行了實際對比。該API有14個可篩選字段，LLM需將教師的口語化請求映射到精確值。V1為原始回傳，參數名稱內部化且無指導，導致頻繁重試。V2改進描述，列出有效值和同義詞映射，準確性提升但定義更臃腫。V3重命名參數並使用枚舉和默認值，防止錯誤值。後續版本進一步應用延遲加載、服務端推理和代理工具。測試表明，在減少上下文消耗和提升首次調用準確率方面，延遲加載和模式約束效果顯著。

總之，MCP工具設計需要平衡臃腫和混亂，根據具體場景選擇合適的策略。本文提供的六種方法及對比代碼可幫助開發者評估不同設計的實際效果。