Function Calling Schema Generator

When a weather assistant needs current conditions, a function call lets it request a lookup for a specific location. The large language model (LLM) selects an available operation and proposes arguments. Application code performs the lookup and can return its result to the model for a reply. The same arrangement supports product searches, appointment checks and other operations whose data or actions come from an application.

A function definition describes that operation through a name, a description and a parameter schema. The name identifies what to call, the description explains when and how to use it, and the schema describes acceptable inputs. JSON Schema supplies the rules for objects, strings, numbers and other JSON values. The definition describes the possible inputs; the arguments contain the values for one particular call.

Three distinctions determine what an application can expect to receive.

Required

The property must be present in the argument object. Its value must also satisfy the property's other rules.

Nullable

The property's value may be null. This does not, by itself, allow the property to be omitted.

Enumeration

An enum limits a value to a listed set, such as "celsius" and "fahrenheit".

A weather lookup might require a location while allowing the temperature unit to be omitted. The application can then choose its default unit. An explicit null, an absent property and an empty string are different inputs, so application code must decide how each is handled. A nullable type with an enum still needs null in that enum if null is intended to be valid.

Descriptions also carry meaning that types alone cannot express. A string called location could mean a city and country, an airport code or a street address. Stating the expected form and the meaning of optional values helps the model choose useful arguments. It also makes the definition easier to compare with the application's actual input requirements.

Moving a function between providers involves both its surrounding JSON structure and its input rules. OpenAI, Anthropic and Google Gemini place the parameter schema under different fields in their application programming interfaces (APIs). The Model Context Protocol (MCP) describes tools exposed by servers to clients. It is a protocol rather than another model provider. These systems can describe the same operation while accepting different schema features and enforcing different strict-mode requirements.

Strict schema enforcement can constrain argument structure, but it cannot establish that a city exists, an account belongs to the caller or an operation is authorized. Those checks remain part of the application. OpenAI's strict function schemas also represent optional values through required nullable fields, whereas Anthropic can preserve omission. That difference matters whenever application defaults depend on a property being absent.

A structured final response serves a different purpose. If the goal is to receive a report with named JSON fields, a response schema may be sufficient. A function definition is appropriate when the model needs to request an application's data or actions. Declaring the function does not create the executable operation or connect it to a service.

How to Use This Tool:

Start with the editable weather example, your own parameter schema or an existing definition. The initial target is OpenAI Responses, with Strict output on and readable formatting.

1. Choose Target format for the API or MCP integration that will receive the definition. OpenAI Responses and OpenAI Chat Completions have different surrounding structures.
2. Paste an object-root JSON Schema into Parameter schema, or edit top-level parameters under Edit parameter fields. Change nested object fields and array items in the schema text. Changing a parameter's Type clears its existing enum and nested fields.
   To reuse a definition, open Import a schema or provider definition and select Import definition. Import accepts one schema, one tool entry or an object containing a one-tool tools array. It retains the current target and strictness. A rejected import leaves the current definition unchanged.
3. Enter Function name and Function description for the operation your application provides. A successful import fills these when they are supplied in the imported definition.
4. Set Strict output to match your intended integration. For Gemini and MCP it shows Not applied. Under Advanced, enable Compact output only if you want JSON without indentation.
5. Review Compatibility checks, especially any Review change entries for optional values or extra object keys.
   If Check your definition appears, correct the reported JSON error, unsupported keyword, name or limit. Results return automatically when the inputs pass the local checks.
6. Copy Tool definition into the appropriate integration and test it with the selected model and your application code. Use Example arguments as a starting input, replacing illustrative values with meaningful test data.

Interpreting Results:

Definition ready for review means the selected definition passed the generator's structural checks. It does not establish API acceptance or model support. A Review change outcome identifies an intentional change to the allowed arguments, such as requiring a previously optional field or rejecting extra keys. Confirm that your application accepts the resulting contract before sending it to a provider.

• Example arguments contain deterministic sample values, not a model response. Empty arrays do not exercise their item schemas, and null values do not exercise the corresponding non-null alternatives.
• Definition sizes compare UTF-8 bytes of the generated definitions. They do not measure tokens, price, latency or compatibility. Only the selected target receives the full local validation checks; a size bar for another target does not prove that target would accept the same name or schema.

Keep your original parameter schema when generating several formats. Importing an already converted strict definition preserves its current required and nullable choices; it cannot recover which fields were optional before conversion. Import also extracts the schema and supplied function name and description, rather than preserving every field of a complete API request.

Technical Details:

JSON Schema rules apply to the value at each schema location. Object rules govern named properties, while an array's item schema governs each element. Consequently, strict requirements for object properties also matter inside nested objects and array items.

The provider rules below reflect documentation retrieved on 26 October 2026, including MCP specification version 2026-07-28. Supported keywords, model capabilities and service limits can change. The references identify the relevant provider documentation.

Transformation core

Generation first checks the parameter schema, applies the selected strict rules to a copy, and places the resulting schema in the target's tool-definition structure. The output is one tool definition, not a complete authenticated request.

The OpenAI, Anthropic and Gemini outputs are entries for the request's tools array. Gemini's parametersJsonSchema and its alternative parameters representation are mutually exclusive; only the former is emitted. The MCP result describes one tool and does not configure or start an MCP server.

Strict rules and changes to optional values

For OpenAI Responses and Chat Completions, strict output applies three rules recursively, including to objects inside arrays.

1. Set additionalProperties to false on every object.
2. Put every property name in that object's required list.
3. For each property that was originally optional, add "null" to its type and add null to any enum that does not already include it.

Originally required properties do not become nullable merely because strictness is enabled. When an optional object is made nullable, its child properties still follow the strict rules whenever the supplied value is an object. Adding null to an enum as well as its type matters because a value must satisfy both constraints.

Anthropic strict output closes every object but retains the original required lists and nullable types. Optional properties therefore remain omittable. Closing an object deliberately narrows any earlier permission to supply undeclared keys, whether that permission was explicit or came from omitting additionalProperties.

With strict output off, those transformations are skipped. Gemini and MCP also skip them regardless of the stored strict setting. The editable parameter schema is retained, so switching strictness off restores generation from that original schema. The recognized dialect-annotation removal described below is independent of strictness.

Accepted parameter-schema keywords

The generator accepts a deliberately bounded subset for all five targets. Every schema needs an explicit type, and the root must be "type": "object". An empty properties object is valid for a function without named parameters.

All other keywords are rejected rather than silently removed. That includes references, schema composition, numeric and length bounds, string patterns and formats, default values and titles. Duplicate JSON keys, unknown required names and mismatched keyword types are also rejected.

A root $schema naming the JSON Schema 2020-12 dialect is the exception. The accepted identifier is linked in References. It is accepted, omitted from the generated parameter schema and reported as a change. Other annotation values are rejected. Removing a dialect annotation does not convert the schema's meaning from one dialect to another.

This generator rejects numeric values that change value when parsed and serialized, including overflow, underflow and integers outside the inclusive safe range from −9,007,199,254,740,991 to 9,007,199,254,740,991. This is a generator limit, not a JSON Schema or provider restriction. Use a string type and quoted enum values for long identifiers when every digit must be preserved.

Provider support beyond this subset

A keyword rejected here may still be accepted by a particular API. Provider support and the generator's input subset are different constraints.

• OpenAI strict schemas support nested anyOf, references, selected string patterns and formats, numeric bounds and array bounds, subject to the documented subset and model restrictions. A root anyOf is not allowed, and allOf, not and conditional or dependent-schema rules are excluded.
• Anthropic strict schemas support const, anyOf, allOf without $ref, internal references, default, selected formats and patterns, and minItems of 0 or 1. Recursive schemas, external references, numerical bounds and string-length bounds are unsupported.
• Gemini GenerateContent documents an object-root JSON Schema field and demonstrates type, properties, required, additionalProperties and propertyOrdering. Its field reference does not supply an exhaustive keyword whitelist. Acceptance of wider schemas must be checked for the selected API and model; response-schema rules should not be assumed to describe function parameters.
• MCP defaults to JSON Schema 2020-12 when no dialect is declared and requires support for that dialect. Its schema vocabulary is broader than this generator's subset. A client's conversion of an MCP definition to a model provider's format can introduce further restrictions.

Input bounds and provider limits

These input limits apply before provider-specific strict checks. Schema depth counts the root as level 1, with each child property schema or array-item schema adding a level. Property totals include nested objects and array items.

Text units are UTF-16 code units, so some characters, including many emoji, count as two. They are different from the UTF-8 bytes counted for generated definitions. Imported schemas are reformatted before validation, so both the pasted import and its extracted, formatted schema must fit the text limit.

Function names and function descriptions are trimmed before generation. Function names are then checked separately. OpenAI names allow 1 to 64 ASCII letters, digits, underscores or hyphens. Anthropic allows the same character set up to 128 characters. Gemini's declaration-name check also allows colons and dots, up to 128 characters. MCP allows ASCII letters, digits, underscores, hyphens and dots from 1 to 128 characters. The MCP rule is a naming recommendation that this generator enforces; it cannot check name uniqueness on your server.

For OpenAI strict output, the transformed schema may contain at most 1,000 enum entries in total. Added null entries count toward that limit. An individual input enum with 100 entries can therefore produce 101 entries after an optional-value conversion, while still being subject to the overall limit.

Anthropic documents request-wide limits for strict schemas.

The generator checks one Anthropic strict definition, including nested schemas. Counts of 24 optional properties or 16 nullable schemas pass their count checks; 25 or 17 fail. Other tools and response schemas are excluded. Combined complexity can still cause provider rejection.

Anthropic warns that string enum and const capitalization can vary under strict output. Validate returned values and avoid alternatives distinguished only by case.

Example arguments and byte counts

Sample arguments include only required properties. For an enum, the sample uses null when both the type and enum allow it; otherwise it uses the first enum value. Other nullable schemas produce null. Non-null objects recurse through required children, arrays produce an empty array, strings use "example", booleans use false, and numbers use zero. These choices satisfy the supported structural rules without inferring business data from descriptions.

Definition size is the byte length of the exact serialized JSON for one generated tool definition.

Here, J is the generated JSON text and B is its length in bytes after UTF-8 encoding. Quotes, field names, punctuation, escapes and output whitespace all count. Results are whole bytes with no rounding. Readable output uses two-space indentation; compact output removes formatting whitespace without changing the parsed definition. Fair comparisons keep the function name, description, parameter schema, strict setting and spacing choice fixed. Different strict transformations can still produce different allowed arguments across providers.

Privacy Notes:

Definition generation and structural checks run in your browser without sending the schema to an LLM provider. No model is called and no function is executed during generation.

Edited inputs can be carried in the page URL, including the parameter schema, function name, description and settings. A copied link or browser history can therefore retain that content. Keep credentials and sensitive values out of definitions and inspect the URL before sharing it.

Worked Examples:

{
  "type": "object",
  "properties": {
    "location": {
      "type": "string",
      "description": "City and country, for example Paris, France."
    },
    "unit": {
      "type": "string",
      "description": "Temperature unit.",
      "enum": ["celsius", "fahrenheit"]
    }
  },
  "required": ["location"],
  "additionalProperties": false
}

{"type":"function","name":"get_weather","description":"Get the current weather for a city.","parameters":{"type":"object","properties":{"location":{"type":"string","description":"City and country, for example Paris, France."},"unit":{"type":["string","null"],"description":"Temperature unit.","enum":["celsius","fahrenheit",null]}},"required":["location","unit"],"additionalProperties":false},"strict":true}

References:

• Function calling, OpenAI.
• Structured model outputs and supported schemas, OpenAI.
• Create chat completion, OpenAI.
• Define tools, Anthropic.
• Strict tool use, Anthropic.
• Structured outputs, schema limitations and complexity limits, Anthropic.
• GenerateContent function declarations, Google AI for Developers.
• Tools, Model Context Protocol, 28 July 2026.
• JSON Schema usage, Model Context Protocol, 28 July 2026.
• JSON Schema 2020-12 dialect identifier, JSON Schema.
• Object properties and required fields, JSON Schema.
• Enumerated values, JSON Schema.
• RFC 8259: The JavaScript Object Notation Data Interchange Format, IETF, December 2017.
• RFC 3629: UTF-8, a transformation format of ISO 10646, IETF, November 2003.