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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds scoping and return-value context, but does not disclose additional behavioral traits like caching, failure modes, or prerequisites. That matches a middle score.

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?

A single sentence delivers the action, scope, accepted values, and result without filler. The information is front-loaded and every word earns its place.

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 simple, read-only tool with two required parameters, the essential invocation details are covered: domain format comes from the schema, component choices are listed, and the return behavior is stated as an 'updated score'. It would be more complete with a brief explanation of what each component represents and the score's format or range.

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 domain parameter is well-described in the schema, but component has only an enum with no field-level explanation. The description clarifies that component selects 'checks behind one component' and repeats the enum values, partially compensating for the 50% schema description coverage. It does not define what each component means or add domain-level details.

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 a precise action ('Re-runs only the checks'), a specific resource ('one component'), enumerates the accepted components, and names the output ('returns the updated score'). The word 'only' differentiates it from a full discoverability check, making it easy to pick apart from sibling tools like check_discoverability.

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 title 'after a fix' and the verb 're-runs' clearly convey the intended use case: targeted re-verification after a fix. However, the description does not explicitly name an alternative for full audits or state when not to use this tool, so it lacks explicit exclusions.

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