Two kinds of problem live in a tool definition. The first is structural: a type that is not a JSON Schema type, a required name that is not among the properties, an array with no items, strict mode without the rules strict mode imposes. Those get rejected, usually with a message that names the field but not the reason. The second kind validates perfectly and causes a different problem — the tool is called at the wrong moment, or with plausible nonsense in an argument, because nothing in the schema says what any of it means. This checks both, reports each finding against the path it came from, and accepts whatever shape you paste: one tool, an array of them, a request fragment, or a bare schema.
Features
Accepts a single tool, an array, a tools fragment, or a bare schema
Every finding carries the path it came from
Catches invalid types, including on individual properties
Catches a required name that is not a property
Enforces strict mode's rules and says which properties break them
Flags a schema under the wrong key
Catches duplicate tool names across an array
Warns about undescribed parameters and empty enums
How to use the Tool Schema Checker
Paste the tool definition, in whatever shape you have it
Read the findings against their paths
Fix the errors first, then the descriptions
Re-check until nothing is left
Example
Input
"required": ["email", "customer_id"]
Output
Error: “customer_id” is required but is not among the properties
A required name with no matching property is rejected outright.
Common errors & troubleshooting
The API rejects the tool but names no field. — Paste it here — the findings carry a path, so the offending node is named rather than left to be searched for.
It says my schema is under the wrong key. — The Messages API reads input_schema. Definitions written for other conventions often use parameters, which is valid JSON and simply not read.
Strict mode fails on a schema that looks fine. — Strict mode needs additionalProperties: false and every property listed as required. Both are checked, with the offending properties named.
It warns about descriptions rather than errors. — Those are the second class of problem. They will not stop the tool being accepted; they are why it gets called with the wrong arguments.
Frequently asked questions
What shapes can I paste?
A single tool object, an array of tools, a {"tools": [...]} request fragment, or a bare input schema. A bare schema is recognised and noted, since a tool also needs a name and a description.
Why does it warn about missing descriptions?
Because they are the most common cause of a tool being called incorrectly, and they never produce an error. A parameter with a name and no description leaves its meaning to be guessed from the name alone.
Does it check my schema against real arguments?
No — it checks the definition itself. Whether a particular set of arguments validates is a different question, and one the API answers when you make the call.
Are $refs supported?
They are flagged. References are not reliably resolved in tool schemas, so a definition that relies on one often behaves differently from what its author read. Inlining the definition avoids the question.
Can I check several tools at once?
Yes — paste the whole array. Duplicate names across the set are caught, which is a problem that only shows up when the tools are considered together.