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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the fields returned (doctrine naming, followed_by/questioned_by from citing opinions, example sentences, statutes, state liveness spans, mined propositions), the default budget (3 issues, 5 statutes, ~12,000 chars, issues_omitted counting the rest), and the query-length parsing rule. It does not contradict annotations, but much of this is answer-format description rather than tool behavior, keeping it at a solid 3.

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 routing rule is front-loaded well and earns its place, but the long parenthetical about followed_by/questioned_by, stalled spans and per-passage flags is dense, run-on, and mixes output-format exposition into the description. It is over-long for an entry-point tool and buries the critical routing guidance amid answer-shape detail.

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, high-stakes legal-research entry tool with no output schema, the description conveys what the answer contains, how the default budget and issues_omitted work, and how query shape changes interpretation. The main missing piece is an explicit note on the reliability caveat for followed_by/questioned_by (which it gestures at) and any latency expectation, but nothing essential to calling it correctly is absent.

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%, so the schema already documents q, state, detail and max_issues in detail, including the 2-6 word naming convention and the default/max values. The description adds interpretive value for q (the >8 substantive word proposition rule, and that propositions are matched and returned first) and for state (it is keyed per state, so strongly recommended), but detail and max_issues only restate schema content. Baseline 3 is appropriate.

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 description opens with a concrete routing rule ("ENTRY BY ISSUE... Use this FIRST when the question arrives as facts or an issue rather than a case name") and gives three literal example queries. It distinguishes itself sharply from siblings by naming find_authority and search_cases and the exact input shapes that route to each.

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?

Explicit when-to-use (facts or issue rather than case name), when to route elsewhere (proposition/quoted language -> find_authority, party name/statute/keywords -> search_cases), plus an automatic behavior boundary: a q longer than 8 substantive words is treated as a proposition. This covers when, when-not, and alternatives.

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