required and additionalProperties before using it as a contract. One example cannot tell you which fields are optional across all valid responses.A response from a successful request contains every field. A schema inferred from that one response may reject a perfectly valid response from an older account with no profile data. The generator can identify observed types; it cannot infer the API's full rules from one instance.
\n\nOpen the tool, replace the sample with this JSON, leave “Required fields” checked, and leave “Allow additional properties” unchecked:
\n\n{\"status\":\"paid\",\"amount\":499,\"roles\":[\"sdet\"]}The generated object has status as a string, amount as an integer, and roles as an array of strings. It lists all three keys in required and sets additionalProperties to false. The $schema value names Draft 2020-12.
Those choices are visible decisions, not facts established by the sample. If roles can be omitted, remove it from required. If the API allows new response fields, turn on “Allow additional properties” or edit that rule after copying. JSON Schema defines required as property presence and additionalProperties as a rule for names outside those declared in properties.
The observed string \"paid\" becomes {\"type\":\"string\"}. It does not become an enum, so the schema would also accept \"unknown\" unless you add an allowed-value rule. The number 499 becomes an integer, but the generator does not know whether negative amounts are forbidden or what unit the amount uses.
Array inference examines the elements it sees. An empty array gives the generator no item type to learn. Try a response with several valid shapes, then edit the schema against the actual API contract. JSON Diff can help find fields that changed across two captured responses, but neither tool replaces contract review. If the schema is headed for an MCP tool's outputSchema, paste the tool definition into the MCP Tool Schema Checker too; it reports required names that no longer match a property.
Does the generator validate my API? No. It produces a schema document from an example. Run that schema through a validator against separate positive and negative fixtures. When the JSON comes from a language model rather than an API, the reviewed schema can become a promptfoo is-json assertion; the LLM Eval Test-Case Builder writes it into the config as a mapping.
Should every observed field be required? Only if the contract says it must always appear. The checkbox expresses a starting assumption, not a discovery.
\n\nGenerate a schema from one real response. Mark every required field and closed-object rule that came from the sample alone. Check those decisions against the API specification or at least two contrasting fixtures before adding the schema to CI.
\n\ntype, required, and additionalProperties.