verify_fix

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important behavior: verification is rejected unless a human approval is recorded, and new rules introduced since the original scan are reported. However, it does not disclose whether the tool has side effects, writes any state, or what happens when verification succeeds or fails beyond the rejection condition.

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 concise and well-structured. It leads with the primary action, then states the key rejection condition, and finishes with the additional reporting behavior. Every sentence adds meaningful information without redundancy.

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 tool with no annotations, no output schema, and three undocumented parameters, the description is not complete enough. It omits crucial details such as what constitutes a valid finding_id, how session_id should be obtained, what format url_or_html should take, what the returned result looks like, and what side effects (if any) the verification process causes. An agent would likely need to guess or consult external sources to use it correctly.

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 schema provides no descriptions for the parameters (0% coverage), and the description does not explicitly define them. It only offers indirect context: 'previously observed finding' hints at finding_id, 'fixed page' suggests url_or_html, and 'original scan' implies session_id. This is insufficient for an agent to confidently map parameters to their intended values without additional inference.

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 explicitly states a specific action ('re-scan a fixed page') and the core determination (whether a previously observed finding cleared), and it also mentions the additional behavior of reporting new rules. This clearly distinguishes it from sibling tools like run_accessibility_review, which would perform a fresh review rather than verifying a prior finding.

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 implies the intended use case—verifying a previously observed finding after a fix—and states a key precondition (human approval must be recorded). However, it does not explicitly mention when not to use it or name alternative tools for related scenarios, such as running a fresh accessibility review instead of verifying a specific finding.

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