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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, so the description's job is lighter. It still adds real context beyond them: the record will attest that a human reviewed it, which is why self-approval is forbidden, and the note dependency on decision type. It does not spell out irreversibility or what a repeat call does, which the non-idempotent hint implies.

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?

Two sentences, front-loaded with the action and its allowed values, then the safety constraint. The POST endpoint reference is mildly technical clutter but is the only spec anchor for that sentence.

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 destructive, non-idempotent write with no output schema, the description covers the essential hazards: human attestation integrity and the conditional note requirement. It omits return behavior on success and whether repeated reviews supersede earlier ones, which an agent handling retries would want.

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 50%: record_id and output_label carry their own descriptions, while note and human_decision do not. The description compensates for the note gap by tying it to override/reject and enumerates the human_decision enum values, but output_label's role ('the outcome the person chose, when it differs') is left entirely to the schema. Partial compensation matches a 3.

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 plus resource ('Record a person's review of an AI decision') and enumerates the allowed outcomes, so the operation is unmistakable. It does not explicitly distinguish itself from the sibling record_ai_decision, leaving the agent to infer that this one attaches a human review to an existing decision rather than creating one.

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?

Gives a clear conditional rule ('overriding or rejecting needs a note') and an explicit prohibition against approving on the agent's own judgement. It never names an alternative sibling tool, so an agent unsure whether it wants record_ai_decision must decide unaided.

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