~/tools / Tool Definition Checker
Tool Definition Checker — 檢查 OpenAI、Anthropic、Gemini 的工具與函式定義
依照各 API 文件記載的格式，檢查你要送給 OpenAI、Anthropic 或 Gemini 的工具（函式）定義：名稱、說明、參數 schema、strict 模式與輸入範例。在請求失敗之前先找出錯誤。內容不會離開你的瀏覽器。
規則已於 2026-10-23 對照文件核對。
文件： OpenAI / Anthropic / Gemini API 參考文件
未檢查：模型是否支援該工具、Anthropic 的 strict 工具使用細節、Anthropic 自己提供的工具，以及文件中沒有記載的規則。
所有處理都在你的瀏覽器中進行，不會上傳這些定義。
工具使用（tool use），也稱為函式呼叫（function calling），讓模型可以請你的程式碼執行某個函式。你要用 JSON 定義來描述每個函式，而三大 API 期待的結構各不相同：OpenAI Chat Completions 把函式放在 function 物件之內，OpenAI Responses 把欄位放在同一層，Anthropic 使用 name 與 input_schema，Gemini 則使用 function declarations。名稱的規則也不一樣。本工具會讀取你貼上的定義，判斷它是為哪一種 API 撰寫的，再依該廠商文件的記載進行檢查：名稱、說明、參數 schema、strict 模式，以及（針對 Anthropic）每個輸入範例是否符合 schema。如果某個在這個 API 可用的名稱會被另一個 API 拒絕，它也會指出來。這些規則是依工具下方所示的日期對照文件核對的。
使用情境
- 在把工具定義加入請求之前先檢查，避免因為名稱不合規或結構錯誤而讓呼叫失敗
- 找出 strict 模式為什麼會拒絕某個函式 schema
- 把工具從一家廠商搬到另一家時，確認哪些地方必須修改
使用方法
- 貼上單一工具定義、工具陣列，或含有 tools 陣列的請求本文，也可以載入範例。
- 先看每個工具被辨識為哪一種 API，再看檢查結果清單。「修正」表示文件記載會被拒絕或無效，「確認」表示值得看一眼，「備註」僅供參考。
- 修正定義後再貼上一次。若是 strict 模式的問題，可用 Structured Output Schema Checker 逐項查看詳細內容。
FAQ
它如何得知定義是給哪一種 API 的？
從結構判斷。含有 input_schema 的定義會被視為 Anthropic。type 為 function 且有巢狀 function 物件的，會被視為 OpenAI Chat Completions；type 為 function 且欄位在最上層的，則視為 OpenAI Responses。含有 functionDeclarations，或含有 name、description 與 parameters 的物件，會被視為 Gemini。結果會顯示每個工具被辨識成什麼。
名稱有哪些規則？
OpenAI 的文件記載可使用字母、數字、底線與連字號，最長 64 個字元。Anthropic 的文件記載可使用字母、數字、底線與連字號，最長 128 個字元。Gemini 的文件記載可使用字母、數字、底線、冒號、句點與連字號，最長 128 個字元。對某個 API 有效的名稱，可能會被另一個 API 拒絕，發生時本工具會告訴你。
strict 為 true 時，為什麼還要再檢查一次 schema？
OpenAI 表示，strict 模式要求每個物件都把 additionalProperties 設為 false，且每個屬性都列在 required 中，選填的值則要寫成同時允許 null 的 type。違反這些規則的 schema 會被拒絕。本工具會統計問題數量，並顯示第一個問題的位置。
它會檢查 input_examples 的哪些內容？
Anthropic 表示，每個範例都必須符合該工具的 input_schema，無效的範例會傳回 400 錯誤。本工具會依 schema 檢查每一個範例，並告訴你哪一個不符。
哪些內容不在檢查範圍內？
特定模型是否支援該工具、Anthropic 的 strict 工具使用細節、Anthropic 自己提供的工具，以及文件中沒有記載的任何事項。本工具不會呼叫任何 API，所以通過檢查的定義在實際請求中仍可能失敗。
我的定義會被傳送到伺服器嗎？
不會。檢查是在你的瀏覽器中執行的。