Google已推出Gemini API的一項高度需求功能，允許在單一API呼叫中結合內建工具與自訂函式。這項功能目前處於預覽階段，僅支援Gemini 3模型。 Gemini 3的核心能力在於「工具context流通」機制，這使得模型能在單次生成中結合Google搜尋、Google地圖、檔案搜尋、URL Context等內建工具，並執行使用者定義的自訂函式。這樣的設計支援複雜的Agent工作流程，例如模型可先從即時網路資料驗證自身，再呼叫特定的商業邏輯函式。 實現這項功能需要三個步驟。首先，必須將include_server_side_tool_invocations標誌設為true以啟用工具context流通。其次，需要將function_declarations與想使用的內建工具一同納入，以觸發組合行為。 第三，若使用者未納入function_declarations，工具context流通仍會作用在已包含的內建工具上，只要該標誌已設定。 API的回應會在單一響應中返回多個部分。對於內建工具，API返回toolCall和toolResponse部分以保留伺服器端工具執行的context和結果。 對於自訂函式，API返回functionCall部分供使用者執行，使用者在下一回合返回functionResponse。 程式執行工具則返回executableCode和codeExecutionResult。 所有部分必須在每次後續請求中完整返回給模型，以維護context並啟用工具組合。 API返回的部分包含三個關鍵欄位：id（映射呼叫到回應的唯一識別碼，必須在函式回應中使用相同id）、tool_type（識別特定工具的字面名稱）、thought_signature（嵌入各部分的加密context）。 Context無法在不使用thought_signature的情況下重建；若未在每回合返回所有部分的thought_signature，模型將出錯。 Google搜尋、Google地圖、URL Context和檔案搜尋等工具會返回特定工具類型的使用者可見資料。 值得注意的是，toolCall和toolResponse部分在請求中計入prompt_token_count，因為這些中間工具步驟已可見且返回給使用者，形成對話歷史的一部分。 此規則的例外是Google搜尋工具，其已套用自有的查詢層級定價模型，不會被重複計費。 該功能有幾項限制。啟用include_server_side_tool_invocations標誌時，必須預設為VALIDATED模式，AUTO模式不支援。 由於Google搜尋等工具依賴位置和時間資訊，若系統指令或函式宣告描述中有衝突的位置與時間資訊，工具組合功能的效果可能不佳。 支援的工具包括Google搜尋、Google地圖、URL Context和檔案搜尋等伺服器端工具，以及程式執行工具。 程式執行具有內建的context流通解決方案。 電腦使用和自訂函式則為客戶端工具，亦具備內建的context流通支援。