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

Beyond the readOnly/idempotent annotations, the description discloses concrete behavior: results are newest first, capped at 25 per call, and pagination uses next_cursor. This is useful operational context that the annotations do not provide, though it stops short of describing errors or the exact return envelope.

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 tightly written sentences deliver the core query semantics, a concrete example, ordering behavior, and pagination guidance. No filler or redundancy; the most important information is front-loaded.

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 three-parameter read-only search tool, the description covers the essential usage: what to search, how results are ordered, the per-call cap, and how to paginate. Minor gaps include explicit limit semantics and alternative-tool routing, but nothing critical prevents an agent from calling it correctly.

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?

With 0% schema description coverage, the description carries the burden of explaining the query parameter, and it does so thoroughly with examples and a docket-number format caveat. It also implies the cursor parameter via 'paginate with next_cursor,' but the limit parameter is only indirectly addressed by 'at most 25 per call.'

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 uses a specific verb ('Search'), a clear resource ('public cases'), and defines the accepted input forms (caption words, 'A v. B', or a federal docket number with office prefix). It is clearly distinguishable from sibling get_* tools, which retrieve specific records rather than performing searches.

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 makes it clear this is the search entry point for public cases and specifies what query formats are valid. It does not explicitly name alternatives or say when not to use it, but the search-vs-fetch distinction is strongly implied by the wording and sibling names.

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