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

Beyond the readOnlyHint=false/destructiveHint=false annotations, it discloses several non-obvious traits: decisions are immutable, a revision must name the decision it supersedes, recording stamps the reviewer role as 'agent' for audit lineage, and it triggers a side effect (reassessing every cluster member). These are exactly the behavioral facts an agent cannot infer from structured fields.

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?

Opens with the verb+resource, then layers the audit-stamp and immutability facts in three focused sentences. Slightly verbose and the mid-sentence all-caps emphasis is stylistically odd, but every sentence carries information.

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 complex mutation with 7 params, nested objects, enums, and no output schema, the description covers purpose, immutability, lineage tagging, and the propagation side effect. It could say a bit more about what 'reassess' changes on members, but nothing critical for a correct call 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 coverage is 100% and the schema itself documents scope, target, outcome, clusterId, rationale, and supersedesDecisionId in detail. The description only echoes the scoping/propagation idea and supersession, adding little syntax or meaning beyond what the schema already provides, so the 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?

States a specific verb and resource ('Record one scoped adjudication for a cluster') and adds the key consequence of propagation ('reassess every member on its own checks'). It is much clearer than a tautology, but it never names a sibling like record_run_calibration_review or record_gate_result to sharpen the boundary between the several 'record_*' tools.

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?

Usage is implied by the domain context (you have a cluster from the adjudication queue and are recording a decision), but the description offers no explicit when-to-use / when-not guidance. It does not tell the agent when to prefer this over split_review_cluster, decide_approval, or the queue/inspection reads.

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