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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses 'No PACER cost' and the API call pricing for keyword search, which is valuable context. However, it does not mention other behavioral aspects like whether results are paginated, ordering, or potential failure modes, so it is decent but not exhaustive.

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: it starts with the core purpose, then explains inputs, output, cost, and examples. Every sentence earns its place, and the inclusion of concrete examples improves clarity without unnecessary verbosity.

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 complexity (7 parameters, no output schema), the description covers the key aspects: purpose, input types, the critical output (court_code + case_number), and cost behavior. It does not describe the full response structure or pagination details, but for a discovery tool, this is sufficient to invoke 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?

The schema covers 71% of parameters with descriptions, and the description adds examples for the query parameter (e.g., 'Sbarro', '1:14-bk') and clarifies query types. However, it adds no information about page_size, page_number, or other parameters beyond the schema, leaving some gaps that are not fully compensated.

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 starts with a specific verb 'Discover' and specifies the target ('federal court cases you don't have the court+number for yet'). It clearly states the resource and distinguishes the tool from siblings by emphasizing it provides court_code + case_number needed by all other tools, which is unique among the listed 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 states when to use this tool ('when you don't have the court+number yet') and notes the output is a prerequisite for other tools. A cost caveat for keyword search is also given, but it does not explicitly name an alternative tool for other scenarios, so it falls short of a perfect score.

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 carries the transparency burden. It discloses that the response includes a 'menu' object with 'modified' timestamps (null = never purchased), and explains cost behavior ('Free unless include_live_pacer=true'). It could add details about authentication or edge cases, but the core behavioral traits are covered.

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 three sentences, starts with the core purpose, and packs relevant details (metadata fields, menu timestamps, cost) without redundancy or fluff. Every sentence earns its place.

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?

There is no output schema, so the description must explain return values—it does, by listing metadata categories and the menu object with timestamp semantics. It also provides workflow context ('Always call this first'). It could mention error behavior or the full list of sub-resources, but for a read-only metadata hub, it is sufficiently 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?

Schema description coverage is 100%, with each parameter well-documented (court_code examples, long-form case_number, PACER cost note). The description does not offer unique parameter meaning beyond the schema; the cost note duplicates the schema's include_live_pacer description. Baseline 3 is appropriate.

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 clearly states 'Get all metadata for a known case' and enumerates specific contents (title, chapter, judge, dates, assets, liabilities) and sub-resource links. It distinguishes itself from sibling tools like get_dockets and get_claims by positioning itself as the umbrella resource-fetching tool.

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 instruction 'Always call this first after finding a case' provides explicit when-to-use guidance. It implies the tool precedes sub-resource fetches, but it does not explicitly name alternatives or exclusion criteria like 'for dockets use get_dockets instead,' so it falls just short of a 5.

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 burden. It transparently implies a read operation and mentions filtering capabilities, but omits significant behavioral details like live PACER refresh costs (include_live_pacer), pagination, and default sorting 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 three concise sentences, front-loaded with the core function, followed by use case and filtering capabilities. Every sentence earns its place with no redundancy.

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 13 parameters and no output schema, the description gives a good overview of purpose, return content, and filter types, but misses critical context like pagination, sorting options, and the live PACER refresh behavior. This leaves gaps for correct invocation.

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 only 46%, so the description must compensate. It adds meaning by explaining output fields (amounts, claim types) and citing 'keyword search and date/number range filtering', but does not clarify individual parameters such as sort_order, sort_column, number_from/to, or page_size.

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 clearly states 'Get the bankruptcy claims register' and specifies the content (amounts, claim type, creditor names, filing dates). It distinguishes the tool as focused on claims, but does not explicitly differentiate from sibling tools like get_creditors.

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 provides clear usage context by stating 'Essential for Chapter 11 analysis and creditor research.' It does not mention exclusions or alternatives, such as when to use get_creditors instead.

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 does clarify an important nuance: the creditor list includes creditors even if they did not file a claim. However, it doesn't explicitly state that this is a read-only operation or mention cost implications for live PACER refresh, though the schema does cover the latter.

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 two sentences long, front-loaded with the core purpose and immediately followed by a differentiation from a sibling tool. There is zero redundancy; every phrase adds value.

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 straightforward retrieval tool, the description is well-rounded: it defines the data source, inclusion criteria, and relationship to get_claims. The absence of an output schema is mitigated by the clear 'list' indication. Minor omissions like pagination details are not critical, given the tool's simplicity.

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 all parameters are already well-documented in the schema. The main description adds no parameter-specific information, so the baseline score of 3 is appropriate.

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 verb ('Get') and resource ('creditor list'), then clearly defines the scope: all creditors scheduled in Schedules D/E/F, whether or not they filed a proof of claim. It also explicitly contrasts itself with the sibling tool get_claims, making the tool's purpose unmistakable.

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 directly names get_claims as an alternative and explains the key distinction (scheduled creditors vs. filed proofs of claim). This gives explicit when-to-use guidance. Additionally, the schema parameter descriptions recommend using list_courts and find_cases when unsure, providing further orientation.

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 discloses that filings are in chronological order, the header content, filtering support, and cost behavior. However, it omits details on pagination, sorting options (beyond default), and the behavioral implications of include_documents or other parameters, leaving gaps in fully predicting tool 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 concise at three sentences, front-loaded with the primary purpose and immediately followed by essential details on content, filters, and cost. Every sentence earns its place without redundant or fluff language.

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 complexity (13 parameters, no output schema, no annotations), the description provides a solid high-level overview but is not fully complete. It lacks explicit guidance on pagination, sorting behavior, and the exact output structure beyond mentions of header fields and document info. The schema fills some gaps, but the description alone is insufficient for a fully informed invocation.

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 description adds meaning beyond the schema by summarizing the filter capabilities (keyword search, date/number ranges) and cost implications of include_live_pacer. However, with schema description coverage at 54%, the description only partially compensates for undocumented parameters like page_size, sort_order, and docket_number_from, not detailing their exact usage or interplay.

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 clearly states the tool's function with a specific verb and resource: 'Get the docket sheet for a case'. It distinguishes itself from sibling tools like get_case (case details) and get_document (individual documents) by specifying the docket sheet content, including filings, dates, descriptions, and attached document info.

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 provides clear context on when to use the tool (for obtaining a docket sheet) and notes filtering capabilities like keyword search and date/number ranges. It also hints at cost implications with 'Free unless include_live_pacer=true'. However, it does not explicitly state when not to use it or name alternative tools, lacking explicit exclusions.

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 fully carries the burden of behavioral disclosure. It clearly explains the caching mechanism, the conditional branches (cached vs. not cached, purchase true/false), and what is returned in each scenario. The cost implications of purchase=true and the 'no cost' cached case are transparent, leaving no major behavioral surprises.

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 compact yet comprehensive. It front-loads the core purpose, then uses a conditional structure to explain behaviors without redundancy. Every sentence contributes necessary context, making it efficient and well-organized.

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 absence of an output schema, the description appropriately explains what the tool returns in each possible branch (cached, purchase=true, purchase=false). It also offers context on obtaining docket_seq and the part parameter, making it complete for a tool of this moderate complexity.

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 already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by clarifying the format of docket_seq (e.g., '42.00000'), emphasizing that part defaults to 1 (main doc), and reiterating the purchase default. This extra context goes beyond the schema but does not fully restructure parameter semantics.

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 starts with a specific verb+resource: 'Get a PDF attached to a docket entry.' It clearly distinguishes itself from sibling tools like get_case (which retrieves case-level info) and get_dockets (which lists docket entries). The purpose is unambiguous and accurately reflects the tool's function.

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 provides clear context on when to use the tool: when you need a specific PDF from a docket entry. It explains the default behavior (purchase=false) and how to change it, and notes that docket_seq comes from docket entries. However, it does not explicitly mention alternatives or when NOT to use this tool, though the guidance is substantive enough to be above a basic 3.

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 burden. It discloses key behaviors: password is not returned on check, validate tests without storing, and delete removes stored credentials. It also implies side effects for set/delete. While it does not cover failure modes or return formats, it provides meaningful behavioral transparency beyond the 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 compact and well-structured. It opens with a one-sentence purpose, then efficiently lists actions in a readable arrow format. Every sentence provides necessary information without redundant filler.

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 tool has four distinct actions with different behaviors, and the description covers each sufficiently. It omits explicit return values or error handling, which would be helpful given no output schema, but the core usage and semantics are clear. The prerequisite note about include_live_pacer=true adds important context.

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 75%, and the description adds significant meaning to the action enum by mapping each value to its effect. It also clarifies that pacer_user and pacer_pass are needed for set/validate, matching the schema. However, the 'validate' boolean parameter is not mentioned in the description, though the schema already describes it.

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 clearly states the tool's purpose: 'Check or update PACER credentials stored in CourtAPI.' It specifies the resource (PACER credentials) and the verb (check/update), and enumerates four distinct actions with their behaviors. This distinguishes it from sibling tools that handle case data retrieval.

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 provides clear contextual usage: 'PACER credentials are required before any include_live_pacer=true call.' This tells the agent when the tool is needed. It does not explicitly mention alternatives or when not to use it, but the prerequisite context serves as a clear guideline.

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. It discloses the optional include_attorneys behavior and specifies the attorney data returned (firm name, contact info, bar number). It does not mention potential side effects, but as a 'get' tool, the read-only nature is clear. The scope ('all parties') and optional behavior are sufficiently transparent.

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 two sentences, front-loaded with the main purpose, and includes relevant use cases without any wasted words. Every sentence earns its place.

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 moderate complexity and lack of an output schema, the description covers the main behavioral aspects: party scope, optional attorneys, and use cases. It does not enumerate return fields for parties themselves, but the party types are listed, making it sufficiently complete for a list-type tool.

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 already provides 100% coverage with detailed descriptions for court_code and case_number, including examples and formatting guidance. The description adds no additional parameter semantics beyond what the schema states, so the baseline score of 3 is appropriate.

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 clearly states the tool 'Get all parties in a case' with specific party types (debtors, creditors, plaintiffs, defendants, trustees) and optionally attorneys. It distinguishes itself from siblings like get_creditors by covering all parties, and from get_case by focusing on party lists.

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 lists concrete use cases ('conflicts checks, service lists, and identifying who is involved'), providing clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a full 5.

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?

Even without annotations, the description discloses key behaviors: it returns ~200 courts, supports type-based filtering, and provides common court code examples. It doesn't describe pagination or authentication requirements, but for a simple list operation, the added context is adequate.

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 three short, purposeful sentences. It front-loads the core purpose, gives a usage trigger, and provides immediately actionable examples—no filler or redundancy.

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 simple list tool with two optional parameters and no output schema, the description covers purpose, usage trigger, result scale, filtering, and sample values. It is self-sufficient and unlikely to leave an agent guessing.

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 descriptions already fully cover both 'test' and 'type' parameters (100% coverage). The description adds little beyond restating 'use type to filter' and providing examples, so it stays at the baseline for schema-covered params.

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 begins with a specific verb and resource: 'List all PACER courts with their court codes.' It clearly distinguishes this tool from siblings like get_case or find_cases by focusing on court metadata lookup.

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 states when to call the tool: 'Call this when you need a court_code and don't know it.' It also directs filtering via 'use type to filter,' though it doesn't mention specific alternatives or exclusions. The when-condition is clear and useful.

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 full burden. It discloses important behavioral traits: costs PACER credits, returns up to ~50 per page, and pagination via search_id+page. It could add more about error handling or authentication, but covers the most critical operational aspects.

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?

Three sentences cover purpose, differentiation, cost, page size, pagination, and use cases—no filler. Information is front-loaded and every sentence earns its place.

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 18-parameter tool with no output schema and no annotations, the description provides purpose, alternatives, cost, pagination, and use cases. It does not describe the return structure beyond page count, but the schema handles parameter specifics. Slight gap on prerequisites like PACER credentials, but acceptable.

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 89%, so parameters are already well-documented. The description reinforces the search_id+page pagination relationship but does not add significant meaning beyond the schema. It hints at party name usage but leaves parameter details to schema.

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 explicitly states the tool searches PACER's National Case Locator across all federal courts, providing a specific verb and resource. It also distinguishes from sibling find_cases by noting it is 'more comprehensive' for party name searches, establishing clear differentiation.

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 gives explicit use cases: 'finding a person's cases across all courts, SSN lookups, cross-court party searches.' It also tells the agent when not to use it by contrasting with find_cases, so the agent can select correctly.

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