Function-Calling Schema Builder

The schema is the contract between your model and your code

Large language models are brilliant at language and useless at acting on the world by themselves. They cannot read your database, hit an API, send an email, or check the weather. Function calling — also called tool use — closes that gap. You describe the functions your application exposes, the model decides when one is needed, and it returns a structured request naming the function and its arguments. Your code runs the real function and hands the result back. The model never executes anything itself; it only proposes a well-formed call. The piece that makes this reliable is the JSON Schema you give it for each function.

That schema is a contract. It tells the model the function's name, a description of what it does and when to use it, and the shape of its parameters: each parameter's name, its type, what it means, and whether it is mandatory. A good description is doing real work — it is the only signal the model has to decide whether this tool fits the user's request, so vague names like doThing with empty descriptions lead straight to wrong or skipped calls. Spend your effort there. The parameter list does the rest: it constrains the model into producing arguments your code can actually parse, instead of a sentence you have to scrape values out of.

Every parameter has a type drawn from the JSON Schema vocabulary — string, number, integer, boolean, array, or object. Choosing the right one matters: integer stops the model from handing you 3.5 where you expected a whole count, and boolean gives you a true/false you can branch on directly. Each parameter can carry its own description, and the model reads those too — a field called unit described as "temperature unit to return" produces far better calls than a bare unit with no hint.

Required versus optional, and why enums are your strongest lever

Not every parameter is mandatory. The required array lists the parameters the model must always provide; everything else is optional, and the model supplies it only when it is relevant. Getting this split right keeps your function flexible without making the model hallucinate values it has no basis for — mark a field required only when your code genuinely cannot run without it, and leave sensible defaults to your own logic. Over-marking parameters as required is a common cause of the model inventing plausible-looking but fabricated arguments.

The sharpest control you have is the enum. When a parameter accepts only a fixed set of values — celsius or fahrenheit, a list of statuses, a set of categories — listing them as an enum restricts the model to exactly those strings. This eliminates an entire class of bugs where the model returns "Centigrade" or "metric" and your switch statement falls through. Enums turn fuzzy natural language into the precise tokens your code already expects, and they make the model's job easier because it is choosing from a menu rather than guessing.

OpenAI and Anthropic wrap the same underlying JSON Schema slightly differently. OpenAI nests it under { "type": "function", "function": { ... "parameters": { ... } } }; Anthropic uses a flatter { "name", "description", "input_schema": { ... } }. The properties, types, required list and enums are identical between them — only the envelope changes. This builder assembles a plain JavaScript object from your inputs and serialises it with JSON.stringify, so the output is always valid, correctly indented JSON in whichever shape you select. Build your schema, switch formats to match your API, copy or download it, and paste it straight into your tools definition. Everything runs locally in your browser, so nothing you design is ever uploaded.