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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries most of the burden and largely succeeds: it discloses that the claim is never trusted, that verification is done by the watchdog, and that a signed hash-chained receipt is returned. It also surfaces a metered cost ($0.002 after the one-time 100-check trial) and plan rules, which is exactly the kind of context annotations cannot express. It stops short of stating idempotency or what happens on a failed verification.

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?

Two compact sentences plus a terse args fragment; the core trust model is front-loaded before the cost note. The phrasing is dense and jargon-heavy ('hash-chained verdict receipt'), but no sentence is superfluous.

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 non-destructive mutation with no output schema and two undocumented parameters, the description covers the trust model and billing well but leaves the parameter contract and the shape of the returned receipt unclear. An agent knows why to call it and roughly what comes back, but not precisely how to populate 'claimed'.

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 0%, so both parameters rely entirely on the description, which offers only 'Args: run_id, claimed?' with no explanation of what run_id identifies or what form the optional 'claimed' artifact must take. The phrase 'the declared artifact itself' hints that 'claimed' is the artifact declaration, but that is inference rather than documentation.

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 concrete verb+resource ('Claim completion') and immediately characterizes what the tool actually does: the watchdog independently verifies the declared artifact and issues a signed, hash-chained verdict receipt. That sharpens it well beyond the bare name 'complete_run'. Sibling tools like verify_now and list_verdicts are not named, so differentiation is implicit rather than spelled out.

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?

Usage is only implied: an agent can infer this is the call to make when a run is finished and a verified verdict is wanted. There is no explicit statement of when to prefer this over verify_now, watchdog_tick, or last_verified_success, and no prerequisites or exclusions are given.

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