Tool Schema Builder
Build function-calling schemas visually — valid JSON for OpenAI, Anthropic and MCP.
Parameters
Nested properties (one level)
{
"name": "read_file",
"description": "Read a file from the repository. Use when the user asks about file contents or you need source context before editing.",
"input_schema": {
"type": "object",
"properties": {
"path": {
"type": "string",
"description": "Repo-relative path of the file to read"
},
"max_lines": {
"type": "integer",
"description": "Maximum number of lines to return (defaults to whole file)"
},
"options": {
"type": "object",
"description": "Read behavior tweaks",
"properties": {
"include_line_numbers": {
"type": "boolean",
"description": "Prefix each line with its 1-based line number"
}
}
}
},
"required": [
"path"
]
}
}How it works
Function calling is the backbone of every agentic workflow, and every provider asks for the same thing in a slightly different wrapper. This builder gives you a visual editor for the part that actually matters — the parameters — and generates the three envelopes you need in practice: an OpenAI function definition, an Anthropic tool definition, and an MCP tool definition. Edit once, copy whichever format your stack consumes.
Each parameter row maps to a JSON Schema property: name, type, description, a required flag, optional enum values for strings, item types for arrays, and one level of nesting for object parameters. The output panes regenerate on every keystroke, and a validation badge tracks the rules all three vendors share: tool names limited to 64 characters of letters, digits, underscores and hyphens; descriptions present on the tool and on every parameter; no duplicate parameter names. Issues are listed beneath the output rather than blocking it, so you can see the JSON taking shape while you fix them.
The deeper game in tool design is not syntax, it is selection: the model reads your descriptions to decide which tool to call and how to fill its arguments. That is why the editor nags about description quality — the highest-leverage sentence in any schema is the one explaining when to use the tool. A precise description costs a few tokens per request and saves entire failed tool-call round trips, which on a busy agent is real money.
A note on the formats: the inner schema is byte-identical across all three outputs, which is exactly why migration between providers is cheap if you keep your schemas in one place. The envelope differences — parameters versus input_schema versus inputSchema — are mechanical, and our API Translator tool converts whole requests between OpenAI and Anthropic shapes if you are migrating an existing integration rather than starting fresh. Everything here runs in your browser; schemas you build are never uploaded anywhere.
Frequently asked questions
How do tool schemas differ between OpenAI, Anthropic and MCP?
The parameter definition itself is plain JSON Schema in all three — the difference is purely the envelope. OpenAI wraps it as {type: "function", function: {name, description, parameters}}, Anthropic flattens it to {name, description, input_schema}, and MCP uses {name, description, inputSchema} with a camelCase key. Because the inner schema is shared, this builder lets you define parameters once and emits all three envelopes simultaneously, kept in sync as you edit.
What makes a good tool description?
Describe when the model should reach for the tool, not just what the tool is. "Read a file from the repository" tells the model what happens; adding "use when the user asks about file contents or you need source context before editing" tells it when to choose this tool over alternatives — which is the actual decision the model makes. The same rule applies to parameter descriptions: a parameter the model fills incorrectly is almost always one with a vague or missing description.
When should I use an enum instead of a free string parameter?
Use an enum whenever the set of valid values is small and closed — modes, formats, severity levels, sort orders. Enums turn a class of runtime validation errors into schema-level constraints the model respects at generation time, and they double as documentation. Keep free strings for genuinely open inputs like file paths or search queries. A common failure pattern is a free string parameter described as "one of: fast, slow" in prose — make it a real enum and the model stops inventing third options.
What is strict mode and should I turn it on?
OpenAI's strict mode (strict: true on the function definition) makes the model's output guaranteed to match your schema exactly, at the cost of supporting only a subset of JSON Schema — every property must be required (use union types with null for optionality), and keywords like minLength are ignored. It is worth enabling for production tools where a malformed argument breaks your handler. Anthropic does not have an equivalent flag; it follows input_schema closely but you should still validate arguments server-side.
How much nesting do tool schemas support?
All three formats accept arbitrarily deep JSON Schema, but practical reliability drops with depth — models fill flat schemas more accurately than deeply nested ones, and each nesting level adds tokens to every request that includes the tool. This builder supports one level of object nesting deliberately: it covers the common "options bag" pattern while nudging you toward flat designs. If you need deeper structures, consider splitting one mega-tool into several smaller tools; models also select between focused tools more reliably.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG