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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety bar is lowered, but the description adds real behavioral context beyond them: inputs are processed transiently and not stored, logged, or retained; gpu:true nodes always delegate to the browser; execution is deterministic; and the call exports an AP2 artifact carrying an execution_hash. It stops short of describing failure modes or delegation-URL behavior in detail, so it is strong but not complete.

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 text restates the title verbatim, repeats "OpenChainGraph compute node" twice, and pads the tail with a documentation URL and a long FV-status hash path that do not help an agent choose or call the tool. The genuinely useful content (compute modes, transient processing, artifact export) is buried among boilerplate, so the structure wastes attention.

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 tool with a free-form nested `policy_parameters` object whose actual field names are deferred to a manifest, the description should tell the agent what inputs the decision function expects — it does not. It also relies on "call describe_tool(...)" instead of supplying return-shape information, and with no output schema present the description carries that burden and fails to meet it.

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's compute-mode paragraph largely restates what the schema already documents for the `compute` enum, and it adds nothing about `parent_hashes`/`parent_tool_ids` ordering or the undocumented `policy_parameters` field contents (the schema itself just defers to "the tool's manifest"). No compensating detail is added.

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 leans on the title ("Parametric Trigger Payout Calculator") and labels itself an "OpenChainGraph compute node (compliance_mandate)" but never says what a parametric trigger payout is or what the decision function decides. It does distinguish itself structurally from siblings by naming its downstream consumer ("Output feeds: art-252-validate-cat-bond-trigger-terms"), but the actual computation is left opaque, making this a vague-purpose case rather than a clear verb+resource statement.

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 only usage rule given is "Use synthetic or anonymised inputs only," which is a data-handling constraint rather than when-to-use guidance. There is no statement of when an agent should pick this tool over the many sibling compute/validate tools, and no prerequisites or exclusions. The compute-mode selection is explained, but that belongs to parameter semantics, not tool selection.

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