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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: inputs are processed transiently and not stored or retained, browser delegation occurs for compute:'browser' or gpu:true nodes, an execution_hash artifact is exported for chain provenance, and the FV-status file is a snapshot that does not gate offline verification. This is real disclosure beyond the annotations, though much of it is templated chain-graph boilerplate rather than this tool's specific semantics.

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 purpose and decision criteria — the most valuable content — appear last, behind multiple paragraphs of identical-looking OpenChainGraph compute-node template text, upstream/downstream artifact lists, and a raw URL and FV-hash string. Front-loading is poor and a large fraction of the text is not this tool's own semantics.

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?

The description lists all output fields (receipt_verdict, hnp_verdict, mandate_chain_intact, etc.), names upstream and downstream artifacts, and covers retention and delegation behavior, which is strong given no output schema. What it lacks is guidance on how to populate the evidently central policy_parameters object — the shape of payment_receipt, mandate_chain, and hnp_policy is left to a separate describe_tool call.

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 earns above baseline by clarifying what the opaque policy_parameters object actually checks: amount, category, mandate age, and cart freshness under the HNP guardrail — information the schema's bare nested keys (hnp_policy, mandate_chain, payment_receipt) do not convey. It also restates the compute contract, which the schema already covers, so the gain is partial.

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 'Summary' sentence gives a specific verb and resource: 'Verifies an AP2 v0.2 PaymentReceipt against its signed Intent/Cart/Payment mandate chain' plus an HNP autonomy guardrail. However, the purpose is buried after several paragraphs of compute-node boilerplate and there is no explicit differentiation from close siblings such as validate_ap2_mandate_chain, validate_ap2_mandate_credential, or authorize_payment_against_mandate.

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?

No when-to-use, when-not-to-use, or sibling routing is given. The compute-mode text is operational detail about execution location, not guidance on choosing this tool over validate_ap2_mandate_chain or authorize_payment_against_mandate. The only directive is the 'use synthetic or anonymised inputs only' constraint, which is an input policy, not usage guidance.

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