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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered; the description goes beyond them by explaining that cases/plaintiffCases/defenseCases count every appearance while casesByYear, opposing firms, experts, motion practice, outcomes and the firm_juris_number filter are restricted to cases where the firm is the lead side. That is precisely the kind of nuance an agent would otherwise misread. It does not cover failure modes for an invalid juris_number, so not a 5.

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, no filler, with the content inventory front-loaded so the agent sees what comes back immediately. The second sentence is dense and clause-heavy ('the stats plaintiff_firm and defense_firm dimensions and the firm_juris_number filter'), which costs a little readability but every clause carries information.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile; the description adds the one thing structured fields cannot express, why a firm's totals differ across surfaces. Missing only edge-case behavior (unknown juris_number), which keeps it from a 5.

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% and both parameters carry their own descriptions, including the unusual 'purpose' parameter being log-only and never returned. The description adds no syntax or format detail for juris_number itself and only indirectly explains why scoping matters. Baseline 3 applies when the schema does the heavy lifting.

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 first sentence enumerates exactly what the tool returns for a single law firm: attorneys, opposing firms, experts, motion practice, and case outcomes. Combined with the required juris_number it is clearly a single-firm profile getter, distinguishable from the sibling search_firms (which supplies the identifier). It stops short of an explicit verb like 'retrieve a law firm profile by juris number', which is why it is not a 5.

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?

The description implies usage through the data-semantics caveat (case counts vs. lead-firm-only figures), but never states when to call this instead of search_firms or the stats family. The only explicit workflow hint, 'Firm juris number from search_firms', lives in the schema rather than the description. An agent can infer the search-then-fetch flow but must do the inferring.

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