JSON Schema → Tool Use Converter (Claude / OpenAI / Gemini)
Automatically generate Anthropic Claude's tool_use, OpenAI's function calling, and Google Gemini's function declaration formats from JSON Schema or manually written parameter definitions. Build from scratch using a form UI, or paste an existing schema to convert all three formats simultaneously.
Usage: drop this JSON into the tools[] array of your SDK call
📖 Where people get stuck
Convert a JSON Schema or a hand-written parameter definition into the tools format for Claude, function calling for OpenAI, or function declarations for Gemini. Everything runs in the browser. Matching the format does not mean the model will call the tool correctly — what decides whether it calls it at all is not the JSON structure but what the description says.
| Case | What happens | What to do |
|---|---|---|
| The model never calls the tool | The cause is a description that is too short, or one that only states what the tool does. From "Gets the weather" alone the model cannot work out when it should be called. Where two tools do similar things it cannot tell them apart, so it favours one arbitrarily or calls neither. Empty descriptions on the parameters do the same damage. |
Write both when to use it and when not to. Something like "Use when the user asks for the current weather in a named city. Do not use for historical data or forecasts — use get_forecast for those" works far better, because it draws the boundary explicitly. Do the same for each parameter: not "date" but "The date, as YYYY-MM-DD. Example: 2026-07-26". |
| The arguments come back the wrong type | Declaring "type": "integer" does not stop a string "3" coming back. The boundary between numbers and strings, the handling of null, and date formats are not fully enforced by the schema alone. Deeply nested objects, and schemas containing oneOf or anyOf branches, degrade further. |
Always validate the arguments on your side — run them through zod, pydantic or similar, and when validation fails, return the error to the model as the tool result. Say "date must be YYYY-MM-DD; received 2026/07/26" and the model corrects itself and calls again. Alongside that, keep the schema shallow: two levels of nesting at most, and split complex branching into separate tools — accuracy improves more from that than from any wording. |
| Accuracy drops as you add tools | Every tool definition is included in the input on every request. Twenty of them add a few thousand tokens as a fixed cost, and worse, the more similar the descriptions look, the less stable the choice becomes. With get_user, fetch_user and load_user_data side by side, a person could not choose either. |
Pass only the tools that situation actually needs. Switching tool sets by conversation state or by screen is the practical approach. Where names are similar, merge them, or rename so the name alone identifies the use — search_users_by_email says both what it searches and how, and stops colliding. Measure the token weight with the token counter. |
The three formats are similar but nest the schema in different places: Claude puts it directly under input_schema, OpenAI under function.parameters, Gemini under functionDeclarations[].parameters. On top of that, Gemini supports only a subset of JSON Schema keywords — things like $ref and additionalProperties that pass elsewhere can be dropped. After porting, make one real call and confirm the arguments arrive as expected. A format being accepted and the thing behaving as intended are separate facts.
❓ Frequently Asked Questions
Differences between formats?
strict mode?
Multiple tools?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.