check_draft

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

With no annotations, the description carries the full disclosure burden and does so thoroughly: it calls itself 'Heuristic and NON-authoritative,' explains regex-based extraction and unverified foreign/federal authority, warns about nearest-cite misattribution and sentence-local treatment signals, and gives the severity ranking. This is far beyond a generic mutation/read hint.

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 description is long but every block earns its place: a front-loaded summary, a bulleted breakdown of the four checks, a severity ladder, and a caveats paragraph that prevents misuse. It is structured so an agent can skim the first sentence and drill into details as needed.

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 composite, six-parameter tool with no annotations, the description covers purpose, customization, output severity semantics, failure modes, and alternatives. An output schema exists for return details, so the absence of a return-format description is not a gap.

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%, so the baseline is 3; the description raises this by explaining the offense/contract-date semantics of as_of_date and expanding on what each check-mode value actually validates. It does not add detail for max_quotes or scan_limit, but those are already described adequately in the schema.

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 names a specific composite operation ('One-call cite-check of a draft opinion, memo, or brief') and enumerates the exact verifications. It also differentiates itself from the sibling detect_overruled_in_draft by noting that tool is the 'cheap treatment-only pass.'

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?

It explicitly routes treatment-only needs to detect_overruled_in_draft and tells the agent when per-authority lookup_authority calls are required instead of relying on a single as_of_date. The check list with default-all behavior also tells the agent how to narrow the call via the checks parameter.

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