What schema shapes does it accept?

A plain JSON Schema object with a properties map, or a full LLM tool definition wrapper from OpenAI (function.parameters) or Anthropic (input_schema). The tool detects the wrapper and unwraps to the underlying schema automatically.

Does it handle nested objects and arrays?

Yes. Nested object properties are documented with dotted paths, and array item types are shown including the element schema. This keeps deeply structured tool inputs readable without losing the hierarchy.

Why document tool schemas at all?

When you expose function-calling tools to an LLM or to other developers, the parameter descriptions are part of the contract the model reads. Clear, human-readable docs catch missing descriptions and ambiguous types that would otherwise cause the model to call the tool incorrectly.

Is anything sent to a server?

No. Parsing and rendering happen entirely in your browser, so you can document private internal tool schemas without exposing them. Nothing leaves the page.

What is the JSON Schema → Human-Readable Docs?

Paste a JSON Schema — such as an LLM tool or function-calling definition — and get a clean Markdown documentation page listing every parameter with its type, whether it is required, allowed values, defaults, and descriptions, ready to copy into your docs. It runs free in your browser on Gera Tools, with nothing uploaded.

JSON Schema → Human-Readable Docs

Name: JSON Schema → Human-Readable Docs
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Turn a JSON Schema into docs people can actually read

A JSON Schema is precise but not pleasant to read, and for LLM tool definitions the parameter descriptions double as the contract the model reads to decide how to call your tool. This generator converts a schema — including OpenAI and Anthropic tool wrappers — into a clean Markdown reference table with types, required flags, allowed values, and defaults.

How it works

You paste a JSON Schema. If it is wrapped in a tool definition (OpenAI’s function.parameters or Anthropic’s input_schema), the tool unwraps it automatically. It then walks the properties map, recursing into nested objects and array item schemas, and emits a Markdown table. Each row shows the parameter name (with a dotted path for nested fields), its type, whether it is required, any enum values or default, and the description. Invalid JSON is reported with the parse error so you can fix it fast.

Why LLM tool schemas need human-readable docs

When you define a tool or function for an LLM to call, the parameter descriptions in the schema are not just for human readers — the model reads them at inference time to decide what arguments to pass. A schema with blank or vague descriptions is one of the most common causes of incorrect tool calls. The model cannot guess what t means or whether status should be "active" or "ACTIVE" without being told.

Converting the schema to a table makes it easy to audit:

Which fields have missing descriptions (blank cells stand out immediately)
Which fields use free-text strings where an enum would be more precise
Whether the required array matches what the code actually needs
Whether nested objects are documented or just shown as object with no detail

What the output looks like

For a tool that searches a product catalog, the generator might produce:

Parameter	Type	Required	Description
`query`	string	Yes	The search term to match against product names and descriptions
`category`	string (enum: `electronics`, `clothing`, `food`)	No	Filter results to a specific product category
`max_results`	integer	No	Maximum number of results to return. Defaults to 10
`filters.min_price`	number	No	Minimum price in USD to include in results
`filters.in_stock`	boolean	No	If true, only return products currently in stock

This kind of reference makes it obvious that category has a fixed set of values (so a model calling this tool should not invent new ones) and that filters is a nested object.

Tips for better tool docs

Write a description for every parameter. The model uses these to decide argument values; a blank description is a common cause of wrong tool calls.
Use enum for closed sets. Documenting allowed values explicitly beats a free-text string the model has to guess at.
Mark required fields accurately. The generated table surfaces gaps where a field is used but not listed in required.
Include format hints in the description. If a date field expects YYYY-MM-DD, say so — there is no JSON Schema format enforcement at call time; the model only reads the description.
Regenerate the docs whenever the schema changes so your reference never drifts from the actual contract.