Tool-Schema Designer
Compose a tool/function definition field by field — name, description, parameters, required flags — and export valid tool-use JSON for the Claude and OpenAI formats, with the JSON Schema generated for you. Stop hand-writing function-calling schemas and fighting silent validation errors.
{
"name": "get_weather",
"description": "Get the current weather for a given location.",
"input_schema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and region, e.g. \"Austin, TX\"."
},
"unit": {
"type": "string",
"description": "Temperature unit: \"celsius\" or \"fahrenheit\"."
}
},
"required": [
"location"
]
}
}How models call your code
Function calling (tool use) is how an LLM reaches beyond text to do things — search, fetch data, send an email. You don't hand the model your functions; you hand it schemas: JSON descriptions of each tool's name, purpose and parameters. The model reads them and emits a structured call your code executes. The schema is the interface, so its quality decides whether the model uses the tool correctly.
What a good tool definition needs
- A clear name and description — the model's only clue about when to use the tool. Describe its purpose, and when not to call it.
- Typed parameters — each argument needs a type, a description, and a required flag. Enums constrain the model to valid choices.
- Just enough tools — too many overlapping tools confuse the model about which to pick; keep them distinct and minimal.
Why the schema matters so much
Ambiguous descriptions and loose types are the top cause of tool-calling failures: the model picks the wrong tool, omits a required field, or invents a value. A precise schema is the cheapest reliability win in an agent. Design the tool visually above and export valid JSON you can drop straight into any function-calling API.
How it works
- A tool = name + description + a JSON Schema of its parameters.
- The model uses your descriptions to decide when and how to call it.
- Required params go in the schema’s "required" array.
- Same inputs export to both Claude (input_schema) and OpenAI (function) formats.
Frequently asked questions
What is a tool (function) definition for LLMs?
It is a structured description — name, what it does, and a JSON Schema of its parameters — that you give a model so it can decide when to call the function and produce correctly-shaped arguments. It is the contract between your code and the model’s tool use.
How do Claude and OpenAI tool formats differ?
They carry the same information in slightly different shapes: Claude uses an input_schema field on each tool, while OpenAI nests the definition under a function object with a parameters field. This builder emits both from the same inputs so you do not have to remember the difference.
Why does the parameter description matter so much?
The model relies on each parameter’s description to fill it correctly. Vague descriptions lead to wrong or missing arguments. Clear, specific descriptions (including format and units) are the single biggest lever on reliable tool calling.
What does marking a parameter "required" do?
Required parameters are listed in the schema’s required array, signalling the model that it must supply them to call the tool. Optional parameters can be omitted. Getting this right prevents the model from calling a tool with incomplete arguments.