{
"name": "get_weather",
"description": "Current weather for a city",
"input_schema": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "City name"
}
},
"required": [
"city"
],
"additionalProperties": false
}
}(เอกสารเป็นภาษาอังกฤษ)
What it does
Function-calling and MCP tools are defined by a JSON Schema, and providers run that schema in strict mode: additionalProperties: false on every object, every property listed in required, no defaults, typed throughout. This tool does two things about that:
- Build — fill in a tool name, a description, and parameter rows; it generates a schema that is strict-clean by construction, live, with a copy button.
- Lint — paste any tool definition; it checks it against the strict-mode contract and lists every violation with its exact path. One click applies auto-strict — the mechanical fixes — while names and descriptions stay yours to write.
The rules (the exact contract the linter enforces)
| Rule | What it checks |
|---|---|
non-empty-name |
name is 1–64 chars of [a-z0-9_-] (the get_weather convention) |
description-present |
the tool and every property carry a real description |
no-additional-properties |
every object — root and nested — sets additionalProperties: false |
all-required |
required lists every property, at every level |
no-defaults |
no default keys — providers reject or ignore them |
typed-properties |
every property’s type is one of string · number · integer · boolean · object · array |
enum-values |
enums are non-empty and share one primitive type |
array-items |
arrays declare items with a type |
json-parseable |
the input parses and input_schema is a typed object |
Auto-strict fixes no-additional-properties, all-required (including junk entries in required), and no-defaults — recursively, idempotently. It never invents names or descriptions: those are semantic, not mechanical.
How to use it
- Build mode: enter the tool name and description, add a row per parameter (name, type, description), and copy the generated schema. There is deliberately no “optional” toggle — strict mode requires every property in
required, so optionality belongs in your model’s semantics, not the schema. - Lint mode: paste a definition (try the chips — one valid, one broken). Issues appear with rule ids and paths; press Auto-strict to fix the mechanical ones; the fixed schema replaces the input for review, with a copy button.
- Point your agent at the rule table above — it is the answer surface for “why is my tool schema rejected?”
Examples
A clean tool — get_weather with city and a unit enum: zero issues, copies as-is into any provider’s tool definition.
A typical broken one — an empty description, a default, a missing additionalProperties, and a required that forgot unit: the linter names all six violations; auto-strict fixes three instantly; the rest need two sentences of copy from you.
Good to know
- 100% client-side. Nothing is sent anywhere — schemas can be proprietary.
- Strict mode is the safe default: it guarantees the model’s arguments validate against your schema, which is what makes a tool call trustworthy enough to execute.
- Go twin: the same rules ship as
cosmodev tool-schema-builderin the CLI (shared test vectors), so agents can lint schemas locally. - Why no optional params? Strict-mode providers require every property in
required; the ecosystem convention is to describe optionality in the description and let the model omit values semantically.