Tool-Schema Designer

Function calling lets a model ask your code to run something, and the tool definition is the whole contract: a name, a description and a JSON Schema for the arguments. This designer builds that definition field by field and prints it in the Claude or the OpenAI format, so the JSON is valid before you paste it into a request.

What it computes

The inputs are a tool name, a description, and a list of parameters, each with a name, a type (string, number, boolean, array or object), a description and a required toggle. The output is assembled the same way every time:

properties[name] = { "type": type, "description": desc }
required         = names of parameters toggled req
schema           = { "type": "object", properties, required }

Claude   { "name", "description", "input_schema": schema }
OpenAI   { "type": "function",
           "function": { "name", "description", "parameters": schema } }

Names and descriptions are trimmed, a parameter with a blank name is left out, a parameter whose name repeats an earlier one is left out and flagged, and the JSON is printed with two-space indentation, exactly the text the Copy button puts on the clipboard. A warning appears if the tool name contains anything but letters, digits, underscores and hyphens.

A worked example

The defaults describe a weather lookup: the tool get_weather, a required string location and an optional string unit. In the Claude format, selected by default, the designer prints exactly:

{
  "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"
    ]
  }
}

Only location appears in required, because unit is not toggled. Switch to OpenAI and the same schema object moves, unchanged, under function.parameters:

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "Get the current weather for a given location.",
    "parameters": { the same object as input_schema }
  }
}

When the model decides to call the tool, it returns arguments that fit the schema, such as {"location": "Austin, TX"}: Claude in a tool_use block, OpenAI in a tool_calls entry whose arguments arrive as a JSON string. Your code runs the function and sends the result back.

Assumptions and limits

• Flat parameters. Each property gets only a type and a description: no enum, no items for arrays, no nested properties for objects, no integer type, default or format. An array or object parameter tells the model nothing about its contents until you add them.
• Partial name check. The warning covers the character set, not length; Claude and OpenAI both cap tool names at 64 characters.
• Chat Completions shape. The OpenAI output targets Chat Completions. The Responses API puts name, description and parameters at the top level, beside "type": "function".
• No strict mode. OpenAI's strict function calling also needs "strict": true, "additionalProperties": false and every property listed as required.
• No check of meaning. Valid JSON says nothing about whether a model can tell from the descriptions when to call the tool.

How to use the result

• Write the description for a reader who has nothing else. Say what the tool does, when to use it and when not to; the model picks tools from this text.
• Put formats and units in parameter descriptions, and after copying, turn a free-text choice like unit into an enum.
• Require only what the function cannot run without. Each required field is one the model must produce, and without the facts it may guess instead of asking.
• Keep definitions short and distinct. They are sent with every request and billed as input tokens, and overlapping tools make the choice harder.

When to use it, and when not

Use it for a first draft of a new tool, to move a definition between the Claude and OpenAI shapes, or to review wording with someone who does not read JSON: the form puts every description in front of you, and the descriptions are where most tool bugs live.

Skip it when the function already exists as typed code. Generating the schema from the types, with a schema library such as Pydantic or Zod, keeps the definition and the code from drifting apart. Skip it too for schemas that need enums, nested objects or arrays of objects; you would rebuild most of the output by hand. An MCP server declares the same kind of JSON Schema under inputSchema, so the schema object transfers but the wrapper does not.

Trade-offs and limits

The designer checks shape, not design. The choices that decide whether a model calls the tool correctly are all yours:

It also leaves out two request-level settings. tool_choice decides whether the model may, must or must not call a tool, or must call one named tool. And arguments are not guaranteed to match the schema unless the API enforces it, as OpenAI's strict mode does, so validate them before acting.

Common mistakes

• Two parameters with the same name. A JSON object can hold a key only once, and JSON Schema requires the entries of required to be unique, so a hand-written schema with a repeated name is broken. The designer keeps the first definition, leaves the later one out and flags it so you rename it; in hand-edited JSON nothing flags it, and JavaScript's JSON.parse and Python's json silently keep the last value.
• Typing identifiers as numbers. A ZIP code such as 02134 loses its leading zero as a number, and long IDs can lose precision. Make IDs and codes strings; make counts integer after copying, since number allows 2.5.
• Acting on a call without checking it. A tool call is a request from the model, not a validated command. Check arguments, and for anything destructive or costly, confirm before running it.
• Reading OpenAI arguments as an object. In Chat Completions they arrive as a JSON string to parse, which can fail. Claude's input is already an object.
• Trusting the name check. It tests characters only. A 70-character name of letters and underscores shows no warning, and both APIs reject names over 64 characters.

Check yourself