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

The sentence 'The body is discarded' does disclose a side effect: the input is not retained after the validation. Since annotations are absent, this is valuable. But the description stops there – it does not clarify that this is a read-only operation, what the return value is, what happens on invalid JSON, or whether any external resources are touched. It hints at safety but does not fully describe behavior.

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 a single, tightly-worded sentence with no fluff. The core action and side effect are front-loaded ('Check whether a body is valid JSON. The body is discarded.'). Every word serves a purpose and the total weight is appropriate for a simple validator.

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 accepts 9 optional parameters, most of which resemble unrelated add-ons (city, feed, host, query), but the description only mentions 'a body'. It does not explain which parameter actually carries the JSON, nor does it expect that no parameters are required. Additionally, without an output schema, it should mention the return type or true/false nature, but it does not. An agent cannot determine how to supply the JSON or interpret the result.

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?

Schema description coverage is 100%, so each parameter is already explained structurally; the baseline is 3. The description adds no parameter-level meaning beyond repeating the 'discarded' concept already present in the schema. In fact, it uses the term 'body' which does not map to any parameter name, so it does not even help the agent choose the 'json' argument.

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 uses a specific verb and resource ('Check whether a body is valid JSON') that clearly identifies a JSON validation function. It differentiates the tool from its siblings, which are mostly URL/path/domain checks, by naming JSON as the target format. However, it refers to a 'body' while the schema uses a 'json' parameter, which slightly weakens the mapping without negating the clear intent.

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?

The description provides no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of 'use when you have a JSON string to validate' or 'use instead of fetch-status/search-query-len' for other purposes. An agent is left to infer selection solely from the tool name and schema, which is incomplete for a set of 28 sibling tools.

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