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

Annotations cover the safety profile, so the description rightly spends its effort elsewhere: determinism, transient/no-retention processing of inputs, the server-vs-browser execution model for gpu:false and gpu:true nodes, AP2 artifact export with execution_hash, and an offline-verifiable FV-status receipt. That is substantial behavior an agent would not infer from readOnly/idempotent hints alone. It stops short of saying what happens on kernel failure or what the delegation URL returns.

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?

It opens by repeating the title verbatim, then devotes most of its length to platform boilerplate (Cloudflare Workers, compute binding, transient processing), a landing-page URL, and a long FV-status hash path. The genuinely tool-specific content — what the delta is — is absent while low-value infrastructure text dominates.

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?

There is no output schema, so the description must carry return-value meaning; it only says an AP2 artifact with execution_hash is exported, and lists downstream consumers by opaque IDs. For a nested-object, kernel-backed financial calculation, the core semantics (what policy_parameters should contain, what the delta measures, units/conventions) are missing.

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, and the description's explanation of compute:'auto'/'browser'/gpu:true largely restates the schema's own wording. It adds nothing for parent_hashes/parent_tool_ids chaining and gives no field-level guidance for policy_parameters, which the schema itself defers ('See the tool's manifest for field names').

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 'Basel 3.1 Reporting Delta Calculator' compute node in the capital_assessment family, but never states what is being differenced — RWA delta, capital requirement delta, or version delta — nor what the inputs/outputs represent. Siblings such as compute_rwa_erba_2026, compute_oprisk_sma_2026 and compare_basel_2023_vs_2026 are far more specific about the calculation performed. The verb 'compute' plus the resource label gives a rough idea, but an agent cannot tell from this text what the tool actually calculates.

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 context is downstream chaining ('Output feeds: sim-03-basel-rwa-scenario-modeler, ptg-01-ap2-prompt-template-generator') and an input-handling warning ('Use synthetic or anonymised inputs only'). There is no statement of when to choose this over compare_basel_2023_vs_2026, compute_rwa_erba_2026 or other Basel calculators in the sibling list.

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