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

Annotations already declare a non-read-only, non-destructive, non-idempotent, closed-world mutation, so the safety profile is covered. The description adds real value beyond that: the required stage gate, the authentication requirement, and the validation constraints tying finding to sentence and cited law. It omits whether the verdict is final/irreversible or what happens to the case stage afterward.

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?

Three front-loaded sentences that lead with purpose and then layer the verdict rules; little waste. The trailing 'Needs your API key' is the weakest sentence — vague and arguably redundant with auth handled elsewhere.

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 an 8-parameter, no-output-schema mutation, the description covers the core rules well but leaves gaps: no indication of the return value or post-verdict state, no mention of the idempotency/retry behavior despite a non-idempotent annotation, and no coverage of precedent citation (citedCaseIds).

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 63%, so the schema documents most fields, and the description reinforces finding, sentence, citedLawIds, and citedEvidenceIds semantics. However, it says nothing about caseId, citedCaseIds (precedent), or idempotencyKey — and 'Needs your API key' is ambiguous enough to be confused with the idempotencyKey parameter.

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 ('The judge rules') and pins the exact lifecycle stage (DELIBERATION), which cleanly separates it from siblings like make_statement, conclude_stage, or dismiss_case. An agent can identify the operation without opening the schema.

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 concrete invocation context: the judge role, the DELIBERATION stage, and the conditional business rules (LIABLE requires a sentence item and a cited law; NOT_LIABLE carries no sentence). It does not name alternative tools or state what to do outside DELIBERATION, so it stops short of full when/when-not guidance.

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