Function-Calling JSON Schema Builder

Function-calling JSON schema builder

Function calling (OpenAI) and tool use (Anthropic) both require you to describe your tools as JSON Schema. Writing that schema by hand is fiddly and easy to get subtly wrong — a missing required array or a mistyped property breaks the model’s ability to call your function. This builder gives you a form: name the function, add typed parameters, mark which are required, and copy clean, provider-ready JSON.

How it works

You define the function once. Each parameter has a name, a JSON Schema type, a description, and a required flag; string parameters can also carry an enum to restrict the allowed values. The tool assembles a standard JSON Schema parameters object — a type: "object" with a properties map and a required array — then wraps it in either the OpenAI { type: "function", function: {...} } envelope or the Anthropic { name, description, input_schema } shape. Switch formats with a toggle and copy.

Tips and notes

• Descriptions are the prompt. The model reads them to decide when to call the tool and how to fill each field. Be specific about units, formats, and constraints.
• Use enums to prevent invalid values. If a parameter has a fixed set of options, list them as an enum so the model cannot invent a value outside it.
• Mark only truly mandatory fields required. Over-requiring forces the model to guess values it does not have, which causes bad calls.
• Everything is local. Your schema never leaves the browser.

Why tool descriptions matter more than the schema type

When a model decides whether to call a tool and how to fill its parameters, it reads the function description and the parameter descriptions — not the types. The types prevent invalid values after the decision is made, but the descriptions are what drive the decision.

A parameter defined as description: "sort order" is far less effective than description: "Sort direction. Use 'asc' for oldest-first or 'desc' for newest-first." The first version leaves the model to guess. The second version tells the model exactly what the parameter does, eliminates ambiguity with an enum, and gives concrete values it can use confidently.

OpenAI vs Anthropic format differences

Both formats wrap the same JSON Schema parameters block, but the envelope structure differs:

OpenAI (tools array format):

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a location.",
    "parameters": {
      "type": "object",
      "properties": {
        "location": { "type": "string", "description": "City name or zip code" }
      },
      "required": ["location"]
    }
  }
}

Anthropic (tools array format):

{
  "name": "get_weather",
  "description": "Get the current weather for a location.",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City name or zip code" }
    },
    "required": ["location"]
  }
}

The parameters key becomes input_schema, and Anthropic’s format does not use the outer type: "function" wrapper. This builder generates both from one definition — toggle the output format with the selector and copy.

When to use enum vs free-text string

Use enum whenever your parameter has a finite, known set of acceptable values. Enums prevent the model from hallucinating a value that your code cannot handle. For example, a status filter that accepts "active", "inactive", and "pending" should always use an enum — a free-text string parameter would let the model pass "enabled", which your handler would not recognise.

Reserve free-text strings for genuinely open-ended values: user-provided search queries, natural language descriptions, or content that cannot be enumerated in advance.