Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden of behavioral disclosure. It does state 'The body is discarded,' which implies no state change, but it does not disclose the return format, error behavior when JSON is invalid, or which input parameter is actually consumed—especially since the schema contains many seemingly unrelated fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the purpose: 'Check whether a body is valid JSON.' The second sentence provides useful behavioral information about discarding the body. It is concise, though the ambiguity of 'body' prevents top marks for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has seven parameters and no output schema, yet the description leaves it unclear which parameter to supply and what the tool returns (e.g., boolean, error). Given the sibling list of shape-check tools, the description should specify that only the `json` parameter matters and clarify the validation result semantics; these gaps make it incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage across all seven parameters, so the baseline is 3. The description adds no additional parameter-level meaning; it only says 'body' without connecting it to the `json` field, and the schema already explains that `json` is 'JSON text to validate; discarded after the check.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the core operation ('Check whether a body is valid JSON') with a specific verb and resource, and this clearly distinguishes it from sibling shape-check tools like domain-shape or github-repo-shape. However, the term 'body' is ambiguous and does not explicitly map to one of the input schema's parameters, so it falls short of a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use validate-json versus the various sibling tools, and no alternatives or exclusions are mentioned. The agent would have to infer from the tool name and schema which shape-checking task it applies to.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.