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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuine limitation (unsigned, local, non-attesting), which is real value beyond the annotations, but it does not say how the comparison result is expressed even though there is no output schema to fill that gap.

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?

One tight sentence with the core action first and the caveat second; no filler. It is efficient, though so terse that it withholds information the agent needs for a four-parameter tool.

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?

Four required parameters at zero schema coverage, no output schema, and minimal annotations leave the description responsible for the return shape and field meanings, which it does not supply. It is insufficient for a tool with this much undocumented surface area.

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?

All four parameters have 0% schema description coverage and none are mentioned in the description. The phrase 'recompute' faintly implies that payload and receipt_sha256 feed a hash, but the roles of actor and action, and the expected format of receipt_sha256, are entirely undocumented.

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 names a specific verb and resource: recomputing an unsigned receipt fingerprint. It implicitly distinguishes itself from the sibling privi_receipt_hash by framing this as a verification/recompute step, though it never names the sibling explicitly.

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 clause 'this cannot attest execution or authorship' gives a partial when-not condition, warning the agent off attestation scenarios. However, there is no positive guidance on when to choose this over privi_receipt_hash or the chain-verification siblings, and no stated prerequisites.

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