devtools.codes

The OpenAI function calling schema format

Your tool input is processed locally in your browser and is not intentionally uploaded to our servers. Advertising and analytics providers may still process normal page, device, cookie and network information.

An OpenAI function-calling definition is a thin wrapper around a JSON Schema. The wrapper carries the name and description; the schema sits inside a parameters field and describes the arguments.

The name is an identifier rather than prose. It must be a valid function-style name, and it is what appears in the model response when a call is made, so it should be descriptive enough to distinguish between several tools. The description is prose, and it is genuinely important: with several tools available, the description is what the model uses to decide which one applies.

The parameters field holds a standard JSON Schema object. One detail catches people out: the $schema keyword does not belong here. The API expects the schema body, not a standalone schema document, and including $schema is a common cause of a rejected definition.

Keep argument descriptions specific. A parameter described as "the query" gives the model very little; "the search query, as the user phrased it, without added keywords" gives it something to follow. The same principle that applies to structured output applies here, because it is the same mechanism.

Strict mode, where available, enforces the schema rather than treating it as a suggestion, and it imposes its own requirements — additionalProperties must be false, and every property must be listed as required. If you intend to use it, design the schema for it from the start rather than retrofitting.

The practical workflow is to build and validate the schema first, confirm it describes the arguments you want, and only then wrap it in the provider format. A schema that is wrong will be wrong in either wrapper.

More on the OpenAI function calling schema format

Why is my function definition rejected?

The two usual causes are a $schema keyword inside parameters, which the API does not expect there, and a name that is not a valid identifier. Spaces, full stops and hyphens in the name are rejected. After that, check that parameters is an object schema rather than a bare type or an array at the top level.

What are the rules for strict mode?

Strict mode enforces the schema rather than treating it as guidance, and it imposes conditions in return: additionalProperties must be false on every object, and every property must appear in the required array. Optional fields are expressed as a nullable type instead. Design for it from the start, because retrofitting means revisiting every nested object.

How does the model choose between several tools?

Mostly from the descriptions. The name narrows the field, but the description is what distinguishes two plausible candidates. Describe when the tool applies rather than only what it does, and make the boundary explicit where two tools are adjacent — the wrong tool being selected is nearly always a description problem.

The tool behind this, and related guides