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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the description earns credit for going further: it defines how undetermined values are excluded from n_checked, that untested elements come from a cap, narrow applies_to, or no volume, that n_body_gaps is a count with no verdict, and that rule_scope names every rule that did not run. These are genuine result-semantics disclosures not derivable from annotations. It does not discuss cost, runtime, or limits on model size, which holds it below 5.

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 first clause front-loads the purpose well, but the remainder is a dense chain of em-dash parentheticals and semicolons that is hard to parse on a single read, and the IDS definition arrives before the agent knows what it needs. Little is outright redundant, yet the compressed telegraphic style costs clarity rather than saving it. The trailing JSON example is well-placed and earns its space.

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?

For a five-parameter tool with deeply nested objects and no output schema, the description carries the necessary load by explaining result fields (n_checked, n_body_gaps, rule_scope, untested_why) and the IDS applicability/requirement split, and it points to get_guide for the rule catalogue it cannot inline. The main residual gap is that it never summarizes the shape of the returned report or the echo, which matters without an output schema.

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 coverage is 100%, so the baseline is 3, but the description adds interaction semantics beyond the schema: applies_to is a filter while requires is the obligation, rules entries replace defaults and 'thresholds names it with its source', categories and depth compose, and rule defaults must be looked up via get_guide topic=rules. That cross-parameter and mode-composition meaning is real added value over the already-detailed property descriptions.

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 establishes a specific verb and resource: a model check run performed 'before handover' that evaluates elements against IDS applicability and requirements plus built-in rules. It explains what a check produces (satisfied / violated / undetermined) and that omitting both requires and categories falls back to the default rule set for file structure, networks and stair steps, so it is clearly a validation tool rather than a query or edit tool. It never explicitly names a sibling it is not, relying on the reader to infer that get_guide only documents rules, which keeps it short of a 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?

It gives concrete selection guidance: use it as a pre-handover double-check, use categories to run whole areas, depth=deep to add body-reading rules, rules for single rules with custom limits, and consult get_guide topic=rules for what each rule checks and its default limit. It also explains the default when nothing is named. There is no explicit when-not / alternative-sibling exclusion (e.g. versus check_contacts for geometry adjacency), so it stops at 4.

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