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

Annotations only cover safety (readOnlyHint, idempotentHint, destructiveHint false). The description adds substantial behavioral detail beyond that: what the output contains (distinct propositions each with own treatment flag and counts), the meaning of a null passage, the proposition parameter's return fields (proposition_match, proposition_note), and the quotation-mark convention for pasted text.

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 front-loaded with the core question and purpose, but the final three sentences about quotation marks, verify_quote, and check_brief are tangential workflow instructions that inflate length. Most sentences carry useful detail, but the structure could be tighter and more scannable.

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?

With no output schema, the description must explain return values; it does so for propositions, treatment flags, passage, and proposition_match/proposition_note. It covers the main use case and key outputs, but omits max_propositions behavior and the full response shape. Adequate for a read-only lookup tool whose annotations already cover safety.

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 baseline is 3. The description goes beyond the schema for the 'proposition' parameter by explaining it is 'your use of the case' and triggers proposition_match/proposition_note. It also clarifies 'passage' as an output field, though citation, case_name, cluster_id, and max_propositions receive no additional elaboration.

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 ('Returns') and resource ('distinct legal propositions courts cite the case for') plus key attributes (headnote-grade, own treatment flag and counts). The phrase 'A case can be good law on one proposition and overruled on another' clearly distinguishes this tool's proposition-level granularity from sibling get_treatment, which likely gives case-level treatment.

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?

Explicitly says when to use it: 'Use before citing a case for a specific point, and to find the strongest proposition to cite it for.' It also cross-references verify_quote and check_brief for adjacent workflow steps. However, it does not name a when-not scenario or an alternative tool that performs the same job.

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