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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real behaviour: deterministic execution, auto/server/browser compute binding including gpu:true always delegating, transient processing with no storage/logging/retention, and an AP2 artifact export carrying execution_hash for chain provenance. The only deduction is that the compute-mode sentences duplicate the schema's own description of the `compute` parameter.

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 front matter (calculator name, domain, regulatory deadline, compute semantics, data-handling rule) is well ordered, but the tail — the ainumbers.co URL and the FV-status hash path with the 'snapshot, not a subscription...' disclaimer — is boilerplate that does not help an agent select or call the tool. Roughly a third of the text does not earn its place.

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 4-parameter, nested-object tool with no output schema, the description supplies the deadline, execution modes, data-retention policy, artifact export and downstream linkage. What it omits is the substantive part: what inputs belong in policy_parameters and what the computed delta result contains, leaving an agent to guess at the core of the 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 description coverage is 100%, so the schema already explains compute, parent_hashes, parent_tool_ids and policy_parameters; baseline 3 applies. The description reinforces the provenance purpose of parent_hashes ('chaining'/'chain provenance') but says nothing about the contents of policy_parameters, which the schema defers to an external manifest — a gap the description does not close.

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 opening line largely restates the name/title ('Basel 3.1 Reporting Delta Calculator: OpenChainGraph compute node (capital_assessment)') and adds a domain and a go-live date, but never says what the 'delta' actually measures or against which baseline it is computed. Siblings such as compare_basel_2023_vs_2026, compute_rwa_scenarios and compute_basel_haircut_adjusted_exposure are in the same neighbourhood and get no differentiation. An agent knows the domain but not the exact computation.

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 gives useful positioning context — a 2027-01-01 UK PRA PS1/26 deadline, downstream consumers (sim-03-basel-rwa-scenario-modeler, ptg-01-ap2-prompt-template-generator), and a hard input constraint ('Use synthetic or anonymised inputs only'). That implies when the tool is relevant, but there is no statement of when NOT to use it and no routing to any alternative sibling. Usage is implied rather than directed.

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