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

Beyond the annotations (read-only, idempotent, non-destructive), the description adds substantial behavioral context: inputs are 'processed transiently... not stored, logged, or retained', gpu:true nodes 'always delegate to the browser', the node is 'deterministic', and it 'Exports an AP2 artifact with execution_hash for chain provenance'. The synthetic-inputs constraint is a meaningful usage boundary. No contradiction with annotations — the artifact export is consistent with a read-only compute node.

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?

Densely informative but repetitive — 'OpenChainGraph compute node' appears twice in the first two lines — and the trailing URL plus FV-status receipt reads as a metadata dump appended without structural separation. Most sentences do earn their place (privacy, delegation, provenance), but the wall-of-text format and the redundant opener prevent a higher score.

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 infrastructure envelope is thoroughly covered: compute modes, data-retention behavior, provenance artifact, downstream consumer, access URL, and offline verification receipt — and the strong annotations carry the safety profile. But the core domain semantics are absent: what a parametric trigger payout is, what policy_parameters must contain beyond 'see the manifest', and what the computed response actually looks like. With no output schema, that gap leaves an agent guessing about the substance of the computation.

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 100%, so the baseline is 3. The description adds no parameter-level meaning: the compute-mode explanation restates the schema's enum text ('auto' = server for gpu:false registered kernels, 'browser' = delegation URL), and policy_parameters guidance merely repeats 'See the tool's manifest for field names'. No defaults beyond 'auto', no example values, no payload structure hints are offered.

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 title and opening line identify the resource ('Parametric Trigger Payout Calculator', 'OpenChainGraph compute node') and the downstream feed ('art-252-validate-cat-bond-trigger-terms') gives pipeline context, so an agent can roughly tell what domain it serves. However, the body never crisply states what the computation actually produces — it buries the purpose under execution mechanics (Cloudflare Workers, compute modes, AP2 artifact export) and never says 'computes the payout amount for a parametric trigger'. It distinguishes from siblings only via its domain name, not any explicit comparison.

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 provides operational context: 'Use synthetic or anonymised inputs only', compute-mode selection behavior, and pipeline placement ('Output feeds: art-252-validate-cat-bond-trigger-terms'). But it never states when to prefer this tool over an alternative or names any sibling, despite an enormous compute_* sibling set; the compute-mode guidance largely duplicates the schema's enum description rather than adding selection criteria.

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