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

No annotations are provided, so the description carries the full behavioral burden and it delivers comprehensively: it discloses the return structure (bluebook_citation, citation, version, locator, url), explains the subtle version/locator semantics (published vs author_draft, printed_page vs pdf_page vs draft_pdf_page), and warns the agent to copy citations verbatim and never present draft pages as journal pin cites. This is high-value behavioral context an agent would otherwise not know.

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 sentence earns its place: the author/subject list enables accurate matching, the usage guidance is front-loaded, and the detailed return-format explanation is necessary because citation correctness is the tool's core value. Structure is logical (scope → when-to-use → alternatives → returns → args) with each block clearly delineated.

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 search tool with subtle citation semantics, the description is complete: it covers the corpus scope, selection criteria, the distinguishing sibling (list_documents vs fetch/fetch_document, which are clearly different functions), and the full return object including how to present sources (URL alongside citation). Nothing an agent needs to invoke it correctly is missing.

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 0%, so the description must compensate, but the Args section merely restates the schema ('query: Natural language search query') without adding construction guidance such as including author names, case names, or doctrine keywords. The usage section implicitly conveys what makes a good query, but the parameter itself is not explicitly elaborated on.

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?

Names a specific verb (Search) and a precisely bounded resource: the published research corpus of the Engelberg Center, listing the exact authors and subject areas. The generic name 'search' is disambiguated by naming the corpus, and the description points to list_documents as the sibling for case-decision lookups, so an agent can tell this tool apart without opening schemas.

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?

Gives explicit when-to-use instructions ('ALWAYS search this corpus when a question names one of these authors or involves IP law doctrine...'), a when-not-to-use note (use alongside web search rather than instead of it), and names the exact alternative (list_documents(cites_case=...)) for a specific scenario. Nothing is left to inference.

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