corpus

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

With no annotations, the description carries full behavioral burden and does so well. It discloses the truncation behavior, the metadata.truncated flag, and the citation rule about never presenting author-draft page numbers as journal pin cites. It also lists exact return fields, giving the agent a clear model of the tool's behavior.

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 well-structured and front-loaded with the primary action, followed by necessary return-field details, truncation caveats, and an Args section. Every sentence adds useful information without redundancy or fluff.

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?

The output schema covers return value structure, so the description need not restate that. The description adds essential context beyond the schema: truncation behavior, paging via fetch_document, and the citation-note caveat. For a single-parameter, read-style retrieval tool, this is fully complete.

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?

The input schema provides only the type 'string' with no description, and schema coverage is 0%. The description compensates by explaining that id is 'The document id from a search result,' which is the key semantic meaning needed to call the tool correctly. It could add more about expected format, but the source of the id is the critical information and it is present.

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 states a specific verb ('Retrieve') and resource ('full text of an Engelberg Center publication') and clarifies that the id must come from search. It also distinguishes itself from fetch_document, which handles truncated documents, and from search, which produces the id.

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?

It clearly indicates when to use this tool: after obtaining an id from search, to retrieve the full text. It also provides an explicit alternative for long documents: use fetch_document to page through truncated casebooks. It does not explicitly mention list_documents, but the context is sufficient for an agent to choose correctly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the paging mechanism (max_chunks per call, start_chunk offset, total_chunks and next_start_chunk in the response) and the metadata (including version and citation_note). It does not mention error handling or authentication, but for a read-only retrieval tool this is a strong disclosure of the key behaviors an agent needs to correctly manage long documents.

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 well-organized and efficient. It leads with the core purpose, then usage context, then paging, then return content, and finally parameter explanations in a clean list. Every sentence adds necessary information without repetition or filler. The structure makes it easy for an agent to scan and extract the important details.

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?

Given the tool's moderate complexity (paging, metadata, multiple parameters) and the existence of an output schema, the description covers all the essential aspects: how to start, how to continue reading via next_start_chunk, the nature of the returned data, and parameter semantics. It even includes guidance on citing drafts. Nothing an agent needs to successfully use this tool 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?

The input schema has zero parameter descriptions (schema coverage is 0%), so the description must compensate. It does so thoroughly in the Args section, explaining document_id (source and usage), start_chunk (zero-based offset and default), and max_chunks (default and maximum). This goes beyond the schema's bare defaults, giving the agent the semantic meaning needed to invoke the tool correctly.

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 specific action and resource: 'Retrieve the text of a specific Engelberg Center publication by document ID.' This clearly distinguishes fetch_document from its siblings: search() locates documents and list_documents() enumerates them, while this tool fetches content for a known ID. The purpose is unambiguous and differentiated.

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 states when to use the tool: 'Use after a search() call to get more context around a relevant chunk, or to read a paper in page order.' It also references the sibling list_documents() as a source of document_id, giving the agent a clear mental model of the workflow. No exclusions are needed because the tool has a focused role.

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

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

With no annotations, the description does the heavy lifting: it discloses partial/case-insensitive matching, defines the director pool, explains the cited_case_matches semantics, and gives concrete example values. This is rich behavioral context that goes well beyond the bare schema.

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 fairly long but well organized: purpose, domain context, use cases, examples, then Args. All content contributes, with only a minor redundancy in the publication-type enumerations keeping it from being perfectly tight.

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 tool with no required parameters and an output schema, the definition covers the core invocation needs thoroughly. The one material gap is the ambiguous set of accepted publication_type values; otherwise an agent can call this tool correctly from the description alone.

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 0%, so the description must explain each parameter, and it largely does: matching rules, examples, and allowed type names. The only blemish is that the publication_type argument lists four categories while the prose earlier had mentioned five, leaving it unclear whether Reports and Briefs & Testimony are valid filter values.

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 states a clear verb and resource: 'List publications from the Engelberg Center on Innovation Law & Policy at NYU Law,' and enumerates the three filter dimensions. This immediately distinguishes it from the sibling tools (search, fetch, fetch_document), which are not listing tools.

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?

It explicitly says to use this tool to browse available sources before searching, to find all work by an author, or to find publications discussing a case. This covers most selection situations, though it never names the search/fetch siblings or says when NOT to use this tool.

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

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.