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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-schema behavior: inputs are processed transiently and not stored or logged, compute can be server-side or delegated to the browser, and an AP2 artifact with execution_hash is exported for provenance. This is useful beyond the annotations, though much of it is generic per-node boilerplate rather than tool-specific.

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 payload is dominated by reusable boilerplate — OpenChainGraph node framing, Cloudflare Workers compute binding, a URL, and a long FV-status hash path — before the single sentence that explains the tool. The 'Outputs:' enumeration is reasonable, but the ordering buries what an agent most needs, and several sentences duplicate the input schema verbatim.

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?

With no output schema, the description compensates by enumerating the returned fields (per_pillar_coverage, receipt_backed_count, version_mismatch, etc.), which is exactly what an agent needs to interpret results. Combined with the 100%-covered input schema, an agent has enough to call and consume this tool; only the routing guidance is 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% and each of the four parameters is documented in the schema itself, including the compute enum and the parent_hashes/parent_tool_ids pairing. The description restates the compute-mode semantics but adds nothing about the policy_parameters object (aiuc1_version, control_evidence) that the schema does not already say. Baseline 3 applies.

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 precise verb and resource: lints a control-evidence bundle against the 23 automatable AIUC-1 v2026-Q1 controls, classifies each control, and reports coverage. It even names the downstream sibling (art-304-aiuc1-evidence-pack-assembler), which distinguishes it from assemble_aiuc1_evidence_pack. However, the actual purpose is buried after ~100 words of shared compute-node boilerplate, so the tool's identity is not front-loaded.

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?

There is no statement of when to call this versus alternatives such as check_etr_control_evidence or assemble_aiuc1_evidence_pack, nor any prerequisites (e.g. input must be an evidence bundle in a particular shape). The only conditional guidance is about compute modes, which is infrastructure-level, not task-level routing.

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