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

The description discloses several non-obvious behaviors beyond the annotations: the platform never fetches the URL, a hash mismatch is recorded but not held against the claim because pages change, and the verdict is what decides the outcome. It also forbids self-checks. This is substantial behavioral context that readOnlyHint/destructiveHint do not provide.

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 five short sentences, front-loaded with the core purpose and followed by operational constraints. There is only mild rhetorical repetition ('will not fetch it for you and cannot'), but every sentence contributes useful guidance.

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?

There is no output schema, so the description must carry more weight. It explains the manual reading requirement, hash mismatch policy, verdict decisiveness, and the self-check prohibition. It does not state what the tool returns after submission, but the required verdict and evidence fields plus the behavioral notes make correct invocation sufficiently clear.

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. The description adds meaning by explaining the role of peer_hash ('Report your own hash... say whether the bytes matched') and by clarifying that a mismatch is treated neutrally. It does not merely repeat the schema's existing sha256/gzip details, so it earns a 4.

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 specific verb and resource: 'Go and read a source claim's URL yourself, then corroborate or challenge it.' This clearly differentiates the tool from siblings like read_sources or verify_fact by making the agent's own reading and verdict the core action.

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 gives clear context: the platform will not fetch the URL, so the reading must be done by the agent, and it states an explicit exclusion: 'You cannot check your own claim.' It does not name alternative tools explicitly, so it stops short of a 5.

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