CourtListener

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the batch efficiency and the 100-citation cap, which is useful, but it does not disclose potential partial-failure behavior or error handling. This is acceptable given the annotation coverage and output schema, hence a 3.

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 only two sentences, front-loads the core purpose, and each sentence adds useful information: what it does, why it is beneficial, and the maximum input size. There is no redundancy or 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 is simple, has one well-described parameter, an output schema, and read-only/open-world annotations. The description establishes the batch nature, efficiency advantage, and limit, which is sufficient for a basic API tool. It does not explicitly explain what a 'lookup' returns, but the output schema covers that, so the description is nearly 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%: the citations parameter is already described as 'List of citations to look up (max 100)'. The description merely restates this limit and the plural nature, adding no substantive meaning beyond the schema. The baseline for high coverage is 3, and no extra semantics are provided.

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 a specific action ('Look up multiple legal citations in a single request'), identifies the resource (legal citations), and distinguishes itself from the singular citation_lookup_citation sibling by emphasizing the batch aspect. The purpose is immediately evident.

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 gives clear usage context: use this when you need to look up multiple citations, as it is more efficient than individual requests. It also states the 100-citation limit. However, it does not explicitly name the alternative singular tool or state when not to use this batch variant, 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?

The description adds meaningful behavioral detail beyond the annotations: it reveals the two-step process (citeurl parsing then optional CourtListener API query) and the optionality of the CourtListener call via the include_courtlistener parameter. This informs the agent about potential external calls and the tool's combined behavior, which is valuable given the readOnlyHint and openWorldHint annotations.

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 only two sentences, front-loaded with the core purpose, and each sentence adds value. It avoids redundancy with the schema and clearly communicates the tool's unique two-step nature without unnecessary prose.

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, the presence of a comprehensive output schema, and the annotations (readOnly, openWorld), the description sufficiently explains the tool's behavior. It covers the process, the optional external component, and the parameter inputs indirectly. No critical missing information for the agent 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 input schema already provides 100% coverage with descriptions for both parameters ('The citation to look up and analyze' and 'Whether to also perform CourtListener API lookup'). The tool description does not add further semantic detail beyond what the schema offers, so the baseline 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's function: 'Enhanced citation lookup combining citeurl parsing with CourtListener data.' It uses a specific verb (lookup) and specifies the resource (citations) and the two-step process. This distinguishes it from sibling tools like citation_parse_citation_with_citeurl (parsing only) and citation_lookup_citation (presumably simpler 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?

The description implies when to use this tool: when you need both citeurl validation and optional CourtListener enrichment. It explains the workflow ('first uses citeurl to parse and validate... then optionally queries...'). However, it does not explicitly name alternative tools or state when not to use this one, so it lacks the explicit exclusion seen in top-tier guidance.

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?

The description discloses that it uses citeurl, finds and parses all citations, and explicitly includes short-form citations like 'id.' references, adding behavior beyond the annotations. It does not contradict the readOnlyHint annotation, and the extra detail about short-form handling is valuable context.

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, consisting of two sentences that immediately state the purpose and a key capability. It is front-loaded with the main action and provides no superfluous 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?

Given the tool's simplicity (one parameter, output schema present, low complexity), the description is complete enough for an agent to understand its input and purpose. It does not need to explain return values because the output schema exists. The description covers the essential behavioral nuances.

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 already fully describes the single 'text' parameter with the description 'Text containing legal citations to extract'. The tool description adds little beyond that, merely repeating the notion of 'a block of text'. Since schema coverage is 100%, 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 uses a specific verb 'extract' with a clear resource 'legal citations from a block of text' and mentions the underlying parser 'citeurl'. It also includes the important detail that it handles both long-form and short-form citations, distinguishing it from sibling tools like citation_lookup_citation or citation_parse_citation_with_citeurl.

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 clearly indicates the primary use case: extracting all legal citations from a given text. It implies when to use this tool (when you need a full extraction) but does not explicitly mention alternatives or when not to use it. No exclusions are provided, so it earns a 4 rather than 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?

Annotations already provide readOnlyHint=true and openWorldHint=true, establishing a safe read operation. The description adds context about accepted citation formats but does not disclose additional behavioral traits such as error handling, rate limits, or potential multiple matches. It does not contradict annotations.

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 appropriately concise, with the main action front-loaded and a useful list of citation format examples. Every sentence contributes meaning 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 tool is simple with one parameter, strong annotations, and an output schema. The description sufficiently explains the purpose and input formats, making it complete for an agent to invoke correctly. No additional context is necessary for such a straightforward lookup operation.

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 parameters are well-documented. The description adds value by categorizing citation formats (U.S. Reporter, Federal Reporter, WestLaw, State reporter), going beyond the schema's simple examples. This helps the agent understand the variety of acceptable inputs.

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: 'Look up a legal citation to find the opinion it references in CourtListener.' This distinguishes it from sibling tools like batch lookups or citation extraction.

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 for single citation lookups by listing accepted formats, but it does not explicitly state when to use this tool versus alternatives like citation_batch_lookup_citations or citation_enhanced_citation_lookup. No exclusions or alternative tool references are provided.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe read operation. The description adds useful context beyond annotations: it uses the citeurl library, extracts tokens, normalizes citation text, and generates URLs conditionally ('if available'). It does not mention error behavior or rate limits, but given the annotation coverage, the added transparency is solid.

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, with a clear first sentence and a bulleted list of return values. There is minor redundancy ('Parse a legal citation' vs. 'parse legal citations'), but overall every sentence earns its place and information is front-loaded. It is appropriately sized for the tool's complexity.

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 simple two-parameter schema, strong annotations, and the presence of an output schema, the description provides a complete overview of purpose, method, and return values. It does not cover edge cases like invalid citations, but the schema and annotations already cover the main usage constraints. The description is sufficient for an agent to select and invoke the tool 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?

Schema coverage is 100%: both 'citation' and 'broad' have descriptions in the schema. The tool description does not add additional parameter-level meaning beyond what the schema already provides (e.g., examples for citation format). It does not elaborate on how 'broad' affects parsing, so the schema carries the semantic burden and the description adds minimal value here.

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+resource+method: 'Parse a legal citation using citeurl's advanced citation recognition.' It clearly distinguishes itself from sibling tools like citation_lookup_citation (which likely fetches metadata) and citation_verify_citation_format (which checks format) by focusing on token extraction and normalization. The return-value list reinforces the parsing scope.

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 for when to use the tool: when you need to parse a citation into structured tokens, normalized text, or a generated URL. However, it does not explicitly name alternatives or state when not to use this tool versus siblings like citation_extract_citations_from_text or citation_lookup_citation. The context is clear, but exclusionary guidance is absent.

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?

Annotations already indicate readOnlyHint=true, so the safety profile is covered. The description adds value by explaining the method (citeurl's templates) and the return type (format and detected issues), but does not disclose limitations, edge cases, or behavior on invalid input beyond 'detected issues'.

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, each earning its place: states the action, explains the method and accuracy, and describes the output. No redundancy or 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?

For a simple single-parameter verification tool with an output schema and read-only annotation, the description covers the essential aspects: purpose, method, and return. It could mention edge cases or normalizing behavior, but overall 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?

With 100% schema description coverage, the schema already fully documents the only parameter. The description adds no additional parameter semantics such as formats, examples, or constraints, which would elevate it beyond the baseline.

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 verifies citation format using citeurl's parsing, which is specific and action-oriented. It distinguishes from simple regex but does not explicitly contrast with sibling tools like citation_parse_citation_with_citeurl, though the verify-vs-parse distinction is inferable.

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 for accurate citation validation ('much more accurate than simple regex matching') but does not provide explicit when-to-use/when-not-to-use guidance or alternative tool comparisons. The context is present but not fully imperative.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lower burden. It adds the date-based snapshot context and the chain structure, but does not disclose additional behaviors like pagination, error handling, or data completeness. This is modest extra context beyond the annotations.

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?

A single, front-loaded sentence that clearly states the action and resource. Every word earns its place, and the hierarchy example adds useful context without bloat.

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 read-only tool with a well-populated schema and output schema, the description is sufficient. It explains the core purpose and date requirement, while parameter semantics are covered by the schema. A brief note on 'ancestry chain' and when to use part/section could enhance it, but the current level is adequate.

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 (date, part, title, section) having a clear description. The tool description adds no parameter-level detail, so the baseline 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 uses the specific verb 'Get' and clearly identifies the resource as the 'ancestry chain' for a CFR node on a date. The phrase 'title -> ... -> node' conveys the hierarchical nature and distinguishes it from sibling tools like structure or search.

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?

No explicit when-to-use or alternative guidance is provided. The context implies usage when the ancestry chain is needed, but it does not mention exclusions or contrast with similar tools such as ecfr_get_title_structure.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds the behavioral detail that results are grouped by date (daily histogram), but does not disclose edge cases, date range semantics, or output format. This adds some value beyond annotations but lacks richness.

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 a single, concise sentence that front-loads the main purpose. There is no redundancy or unnecessary detail, making it highly efficient for an agent to parse.

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 is simple with 2 params, full schema coverage, and an output schema present. The description sufficiently conveys the core function, though it could be improved by noting how the optional date affects the histogram. However, given the annotations and schema, it is complete enough for basic use.

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 both parameters ('query' and 'date') already described. The tool description does not add additional parameter semantics, but the schema fully documents them. 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 the tool's function: 'Get search result counts broken down by date (daily histogram).' It uses a specific verb and resource, and the 'daily histogram' qualifier distinguishes it from sibling tools like ecfr_get_search_count, which likely returns a single total count.

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 when a daily breakdown of search counts is needed, but it does not explicitly mention when to use this tool versus alternatives like ecfr_get_search_count or ecfr_get_title_search_counts. No exclusions or alternative guidance is provided.

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?

Annotations already declare readOnlyHint and openWorldHint. The description adds the behavioral context that counts are distributed across the CFR hierarchy, but does not explain how the distribution is structured, whether date affects results, or any other operational traits.

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?

One concise sentence that front-loads the core action and resource. No filler or redundant restatement of schema/annotations.

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?

With a full input schema and output schema present, plus read-only and open-world annotations, the description is sufficient to convey the tool's basic function. However, it could be more complete by noting how hierarchy distribution differs from sibling count tools.

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 covers 100% of parameters with descriptions for query and date. The description adds no new parameter-level detail beyond what the schema already provides.

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 and resource: 'Get search result counts distributed across the CFR hierarchy.' This clearly distinguishes it from sibling tools like ecfr_get_search_count (total counts) and ecfr_get_title_search_counts (title-level) by signaling a hierarchy-wide distribution.

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?

No explicit when-to-use or alternative tool references are provided. The hierarchy distribution wording implies a use case, but there is no guidance on when to choose this over get_search_count, get_title_search_counts, or get_daily_search_counts.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds little beyond the purpose: it does not disclose details like whether the count includes only sections or all matching entries, or any search behavior nuances. It does not contradict the annotations, and with annotations present, the description meets a baseline but does not enrich behavioral understanding.

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 a single, front-loaded sentence that directly states the tool's purpose. It contains no filler words or redundant information, achieving maximum conciseness and clarity in minimal space.

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 simplicity, the annotations (read-only, open world), full schema coverage, and presence of an output schema, the description is mostly complete. It correctly communicates the return type ('total number'). However, it could benefit from a note clarifying that this returns a count only, not search results, and from mentioning the optional filters, but these are already in the schema. Overall, it lacks only explicit usage context that would elevate it to a perfect score.

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 covers 100% of parameters with descriptions (e.g., query, date, title, agency_slugs). The description only mentions 'search query' implicitly via 'matching a search query', adding no extra meaning beyond the schema. Per the schema coverage baseline, a 3 is appropriate as 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 description clearly states the tool's function: 'Get the total number of CFR sections matching a search query.' It uses a specific verb ('get') and resource ('CFR sections'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like ecfr_get_search_summary or ecfr_get_daily_search_counts, so it lacks explicit sibling 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or alternative tools. For example, it does not clarify whether users should choose this over ecfr_get_search_summary or ecfr_get_daily_search_counts, leaving usage context entirely to the user.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the 'partial query' scoping but nothing else about behavior such as rate limits or how suggestions are generated. This is adequate but minimal.

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 a single, front-loaded sentence with no wasted words. It states the action and scope efficiently.

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 one-parameter read-only tool with an output schema, the description sufficiently explains the tool's purpose and input. It could add a bit more about what kind of suggestions are returned, but the output schema likely covers that, making it complete enough.

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% for the single query parameter, which already states 'Partial query to get suggestions for'. The tool description merely echoes this, adding no new meaning or syntax details, hence the baseline score.

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 'get' with a clear resource 'search-term suggestions' and scope 'partial CFR query'. It clearly distinguishes this from sibling tools like ecfr_get_search_count or ecfr_search_regulations by focusing on suggestions for incomplete queries.

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 its use case: when a user has a partial CFR query and needs suggestions. This provides clear context, though it does not explicitly mention alternatives or exclusionary conditions, so it stops 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds that it returns counts and metadata, which is mildly informative. However, it does not disclose any other behavioral traits such as aggregation behavior, date handling, or limitations, leaving the agent to infer from the name.

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 a single sentence that is front-loaded with the core action and resource. No unnecessary words or repetition, making it extremely concise and well-structured.

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 simplicity of the tool, the presence of a detailed input schema, annotations, and an output schema, the description is adequate. It covers the essential purpose, while structured fields fill in parameter and return details. A slight deduction for not clarifying how 'summary' differs from sibling count tools, but overall complete enough.

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 provides 100% coverage for all four parameters with clear descriptions (e.g., 'Full-text search query over the CFR', 'As-of date'). The description adds no extra parameter information beyond what is already in the schema, so the baseline 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 states a clear verb ('Get'), resource ('summary details'), and scope ('counts + metadata for a CFR search query'). It is specific but does not explicitly differentiate from sibling tools like ecfr_get_search_count or ecfr_get_daily_search_counts, which also involve counts.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or scenarios that would help an agent choose it over similar search-related tools.

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?

The description adds valuable behavioral context beyond the annotations: it discloses that fetching an entire large title can time out on the eCFR side, and that the result is available under 'content_xml'. This goes beyond the readOnlyHint/openWorldHint annotations and helps the agent anticipate performance and response structure.

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 concise sentences with no wasteful filler. The first sentence states the core purpose, the second gives usage guidance, and the third mentions a key caveat. Ideal front-loading and structure.

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 (9 params, output schema, annotations), the description is complete: it explains the main action, scoping requirements, timeout risk, and where the result is returned. The output schema handles return details, so no further elaboration is needed.

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 100% schema description coverage, the baseline is 3. The description adds meaning by explaining that 'part or section' are scoping parameters and should be used together or individually to limit the request. This reinforces and contextualizes the schema's parameter descriptions without fully duplicating them, earning a 4.

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: fetch raw source regulation XML for a CFR node on a given date. It uses a specific verb ('Fetch') and resource ('source regulation TEXT (XML)'), and the phrase 'for a CFR node' distinguishes it from sibling tools that return structure, search results, or citations.

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?

Explicit guidance is given: pass a part or section to scope the request, and avoid whole-title fetches due to timeouts. This tells the agent when and how to use the tool, including a strong recommendation to narrow scope. It effectively communicates the intended usage pattern.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the grouping-by-title behavior, which is useful but does not disclose response format, pagination, or date handling beyond what schema provides. No contradictions with annotations.

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?

A single, front-loaded sentence that states the essential function without waste. Every word contributes meaning, and the structure is immediately scannable.

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?

With a readOnlyHint, openWorldHint, and a full output schema (indicated by 'has output schema: true'), the description is sufficient for the tool's simplicity. It covers the core behavior and relies on schema for parameter details, leaving no critical gaps.

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 clear descriptions for 'query' and 'date'. The description does not add additional parameter meaning beyond what the schema already provides, so the baseline 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 uses a specific verb ('Get') and resource ('search result counts broken down by CFR title'), clearly distinguishing it from sibling tools like ecfr_get_search_count or ecfr_get_daily_search_counts. The scope is explicit and unambiguous.

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: use when you need search result counts grouped by CFR title. However, it does not explicitly state when not to use it or mention alternative tools, leaving the agent to infer from the name and siblings.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and dynamic data. The description adds that the full structure is returned for a specific date, but does not disclose potential large response sizes, pagination behavior, or other operational nuances beyond the annotations.

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 a single, front-loaded sentence with no wasted words. It immediately states the verb, resource, and scope, making it highly concise and readable.

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 simple read-only tool, the description is largely complete, especially with an output schema and annotations covering safety and open-world behavior. The only missing piece is explicit usage guidelines vs siblings, but for a straightforward retrieval tool this is not a significant gap.

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%, with both parameters described clearly: 'CFR title number (1-50)' and 'Snapshot date (YYYY-MM-DD)'. The description's 'title -> section' phrasing confirms the relationship but adds little beyond what the schema already provides.

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?

Description uses specific verb 'Get' and resource 'full hierarchical structure (title -> section)', clearly indicating the tool's function. It distinguishes itself from sibling tools like ecfr_get_source_xml (raw XML) and ecfr_get_ancestry (specific section ancestry) by focusing on the complete title-level structure.

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?

No explicit guidance is provided on when to use this tool versus alternatives. The description only implies a use case (retrieving the full structure) but does not mention when to prefer this over ecfr_get_ancestry or ecfr_get_source_xml, nor any 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to cover safety. It adds the meaningful detail that versions are 'issue dates,' but otherwise provides no additional behavioral context such as ordering, pagination, or limitations. This is acceptable but not rich.

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 a single, front-loaded sentence with no wasted words. It states the action, resource, and result type efficiently.

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 simplicity, the presence of annotations, and an output schema, the description fully communicates the core purpose and result (versions/issue dates). It does not explain potential caveats or use cases, but none are necessary for such a straightforward list operation.

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% (the 'title' parameter is fully documented as 'CFR title number (1-50)'), so the description does not need to repeat it. The description's phrase 'one CFR title' aligns with the parameter, but adds no new semantic detail beyond the 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 uses a specific verb ('List') and resource ('available content versions (issue dates) for one CFR title'), clearly distinguishing this from sibling tools like ecfr_list_titles or ecfr_get_title_structure. It immediately conveys what the tool returns.

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 when one needs content versions/issue dates for a CFR title, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions. It is adequate but lacks comparative guidance.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the output content (title/chapter references) but does not disclose behavioral traits like pagination, ordering, or potential limits. This is acceptable for a simple list tool but not exceptional.

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 a single sentence with no wasted words. It front-loads the verb 'List' and clearly states the scope and output, making it maximally concise and structured appropriately.

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 zero-parameter tool with an output schema, the description is complete: it states what is retrieved (all agencies) and what is returned (title/chapter references). No additional context is needed given the simple nature of the operation.

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 tool has zero parameters and the schema coverage is 100%, so the description needs no parameter explanations. Per instructions, a baseline of 4 is appropriate for a tool with no parameters; the description adds no extra parameter semantics but none are required.

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 (List), the resource (agencies in the CFR), and the output details (title/chapter references). This distinguishes it from sibling tools like ecfr_list_titles, which lists titles, and ecfr_get_title_structure, which retrieves structure.

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 when a user needs a list of agencies appearing in the CFR, but it does not explicitly state when to use this tool over alternatives or provide exclusions. With sibling tools like ecfr_list_titles existing, more explicit differentiation would improve the 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?

The annotations already declare readOnlyHint and openWorldHint, and the description is consistent with those. However, the description adds no extra behavioral context such as pagination, rate limits, or data completeness caveats beyond what the schema and annotations already provide.

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 a single, front-loaded sentence that clearly states the action and the optional filters. There is no redundant or unnecessary 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?

Given the tool's simplicity (read-only list with two optional, well-documented parameters) and the presence of an output schema, the description is adequate. However, it lacks explicit disambiguation from the sibling ecfr_list_corrections_by_title, which could lead to confusion.

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 full descriptions for both parameters, including types, defaults, and meaning. The description simply repeats the filter options without adding additional semantic detail, so the baseline of 3 applies due to 100% schema coverage.

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 lists CFR corrections with optional filters by title and effective date, using a specific verb and resource. However, it does not distinguish itself from the sibling tool ecfr_list_corrections_by_title, which appears to offer similar functionality.

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?

No guidance is provided on when to use this tool over the similar ecfr_list_corrections_by_title or other listing tools. The description only mentions optional filters but does not explain alternatives or 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, establishing the safe read-only nature. The description adds no further behavioral context beyond the operation itself (e.g., no mention of pagination, sorting, or what constitutes a correction). With annotations present, the bar is lower, but the description provides minimal added insight.

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 a single concise sentence, front-loaded with the action ('List all corrections') and scope ('for a single CFR title'). No wasted words or redundant 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?

Given the tool's simplicity (one parameter, output schema present, annotations provided), the description is sufficient for an agent to understand the core purpose. It could have added a note about response format, but with an output schema handling that, the description is adequately 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%, as the 'title' parameter is fully described in the input schema (CFR title number 1-50). The description does not add any new meaning beyond what the schema already provides, so the baseline score of 3 applies.

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+resource: 'List all corrections for a single CFR title.' It clearly distinguishes from sibling ecfr_list_all_corrections by emphasizing 'single CFR title,' making the scope explicit and unambiguous.

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 for one title's corrections, and the sibling list includes ecfr_list_all_corrections, suggesting a contrast. However, there is no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives, so it remains at an implied level.

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?

The annotations (readOnlyHint=true, openWorldHint=true) already indicate a read-only, open-world operation. The description adds that the tool returns dates and status, but this is also encoded in the output schema. No additional behavioral traits such as pagination or rate limits are disclosed.

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 a single, focused sentence that conveys the essential function without unnecessary words or repetition. It is well-structured and easy to parse.

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, parameterless list tool with annotations and an output schema, the description is complete. It clearly states what data is returned (dates and status) and there is no missing information needed to invoke the tool 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 tool has zero parameters, so the schema covers everything. The description adds no parameter information, but with an empty parameter list, the baseline of 4 applies.

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 lists all 50 CFR titles with their latest amendment dates and status. The verb 'List' and the specific resource 'all 50 CFR titles' make the purpose unambiguous, and it is distinct from sibling tools like ecfr_get_title_versions which target a single title.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the function statement.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds that it returns 'matching sections with hierarchy', giving useful context about the result shape. No contradictions with annotations.

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?

Single sentence that is front-loaded with the core operation and resource, then specifies the return value. No wasted words or redundant 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 are documented elsewhere. The 7 parameters are fully described in the schema. The only gap is the lack of usage guidance relative to siblings, but overall the description is adequate for a straightforward search 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 provides 100% coverage for all 7 parameters with clear descriptions (e.g., date, title, agency_slugs). The description adds no additional parameter semantics, so the baseline of 3 applies.

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 'Full-text search' and a clear resource 'federal regulations', with an explicit return type 'matching sections with hierarchy'. This distinguishes it from sibling search tools like search_opinions or ecfr_get_search_counts, which target different content or operations.

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?

Usage is implied: this tool is for full-text searching the CFR. However, there is no explicit guidance on when to prefer it over alternatives, nor any mention of exclusions or complementary tools like ecfr_get_search_counts or ecfr_list_titles.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds minimal behavioral context—only the fact that it retrieves information from CourtListener—but does not disclose error behavior, response scope, or any rate-limiting. No contradiction with annotations exists.

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 a single sentence with 9 words, front-loading the verb and resource. It contains no fluff or redundant phrases, earning it a top score for efficiency.

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?

With an output schema available to describe the return structure and annotations covering safety, the one-line description is sufficient for this simple single-parameter retrieval tool. It clearly states the resource and key constraint (by ID), leaving no major gaps for an agent to misuse it.

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 a full description of audio_id ('The audio recording ID to retrieve') and coverage is 100%, so the description's 'by ID' adds no semantic detail. The baseline score of 3 is appropriate given the schema handles parameter documentation.

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 the specific verb 'Get' with the resource 'oral argument audio information' and the scope 'by ID from CourtListener.' This clearly distinguishes it from sibling tools like get_opinion or search_audio.

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 no guidance on when to use this tool versus alternatives such as search_audio or other get_* tools. It does not mention exclusions or preferred contexts, leaving the agent to infer usage solely from the tool name and description.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and volatility profile. The description adds no behavioral context beyond what annotations provide—e.g., it does not mention result structure, pagination, or any special behavior. The only extra detail is the source name, which is not behaviorally informative.

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 a single, front-loaded sentence with no filler or redundancy. It delivers the essential information efficiently and 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?

The tool is simple (one parameter, output schema present, annotations cover safety), so the minimal description is mostly adequate. However, it lacks differentiation from get_opinion and does not explain what an opinion cluster is, which could leave an agent uncertain about selection. Given the low complexity, this is a mild gap.

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 the parameter `cluster_id` is documented inline as 'The opinion cluster ID to retrieve,' which matches the description's 'by ID'. The description adds no additional semantic detail beyond the schema, so the 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 the action ('Get'), the resource ('opinion cluster'), and the method ('by ID'), plus the source ('CourtListener'). It distinguishes itself from sibling tools by naming a unique resource, though it does not explain how an opinion cluster differs from an opinion or related entities.

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?

No guidance is provided on when to use this tool versus alternatives like get_opinion or get_docket. The description only states the mechanical action of retrieving by ID, with no context about use cases, prerequisites, or 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?

Annotations already provide readOnlyHint and openWorldHint, so the description doesn't need to restate safety. However, it adds no behavioral context beyond the schema, such as error handling, rate limits, or return format details. The phrase 'from CourtListener' is trivial and not behaviorally informative.

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 a single, clear sentence with no unnecessary words. It is entirely front-loaded and succinct.

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 one-parameter tool with full schema coverage, readOnlyHint, and an output schema, the description is sufficient for an agent to invoke it correctly. The only minor gap is the lack of usage guidance, but the tool's simplicity keeps it mostly 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%, and the parameter includes examples ('scotus', 'ca9'). The description's 'by ID' adds no semantic value beyond what the schema already provides, so 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 'Get court information by ID' clearly states the verb (get), resource (court information), and specificity (by ID). It is distinct from sibling 'get_' tools by naming the court resource, though it doesn't explicitly differentiate between similar retrieval 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?

No guidance is given on when to use this tool versus alternatives, such as search tools or other 'get_' tools. The description provides no context on use cases, exclusions, or alternatives.

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?

Annotations already declare this as read-only, so the description doesn't need to cover safety. However, it adds minimal behavioral context beyond the name, such as the source 'from CourtListener', but does not disclose error handling or response size.

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 a single, concise sentence with no wasted words. It front-loads the verb and resource, making it easy to parse.

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 low complexity (one parameter), full schema coverage, and an output schema, the description is sufficient to understand the tool's purpose and invocation. No additional context is needed.

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 provides full coverage of the single parameter (docket_id) with a clear description. The tool description adds no additional semantics beyond restating that the lookup is by ID, which is already in the 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 clearly states the action (Get), the target (specific court docket), and the method (by ID). This differentiates it from search_dockets and other get_* tools in the sibling list.

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?

No usage guidance is provided. The description does not mention when to use this tool versus alternatives like search_dockets, nor does it state any preconditions or exclusions. Usage is implied by the name and description.

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?

Annotations already provide readOnlyHint and openWorldHint, and the description does not contradict them. The description adds only the 'CourtListener' source, with no additional behavioral detail such as error handling or response format, but for a trivial read-only lookup this is minimally 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 a single, front-loaded sentence with no filler or redundant content. Every word contributes to communicating the operation and scope.

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?

This is a minimal one-parameter read-only lookup with full schema coverage, helpful annotations, and an output schema that can document return values. The description is complete enough for an agent to understand the tool's role and 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?

Schema description coverage is 100% and the single parameter opinion_id is already described as 'The opinion ID to retrieve.' The description's 'by ID' adds no new meaning beyond the schema, so it does not compensate beyond the schema baseline.

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 the specific verb 'Get' with a clear resource ('specific court opinion'), a clear identifier ('by ID'), and the data source ('from CourtListener'). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like search_opinions.

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 gives clear context: this is for retrieving one known opinion by its ID. It does not explicitly mention alternatives such as search_opinions for unknown IDs or get_cluster for related data, but the 'by ID' phrase strongly implies the appropriate use case.

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?

Annotations already convey that this is a safe read operation (readOnlyHint=true) and open-world (openWorldHint=true). The description adds no additional behavioral context such as error handling, authentication needs, or rate limits. This is an adequate baseline given the annotations.

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 a single, front-loaded sentence of 11 words. It includes the verb, resource, method, and source without any redundant or vague wording. Every word 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?

The tool is simple with one parameter, has an output schema, and clear annotations. The description tells the agent exactly what to expect and how to invoke it. Nothing important is missing for a single-entity retrieval 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 describes person_id as 'The person (judge) ID to retrieve', covering 100% of the parameter. The description's phrase 'judge or legal professional' adds a slight broadening beyond 'judge', but no syntax or format details are provided. Schema coverage is high, so 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 a specific verb 'Get', identifies the resource as 'judge or legal professional information', and specifies retrieval method 'by ID'. It is easily distinguishable from sibling tools like get_audio or search_people, which target different resources or use search instead of direct 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 phrase 'by ID' provides clear context that this tool is for direct lookup when an ID is known, implicitly contrasting with search-based tools like search_people. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a perfect 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description needs to add extra behavioral context. However, it does not disclose any additional traits such as pagination behavior, the nature of results (e.g., metadata, playback URLs), or any limitations (e.g., CourtListener-specific search syntax). The description adds no value beyond the annotations, so it falls short on transparency.

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 a single, focused sentence that immediately communicates the tool's core function. It is front-loaded and contains no filler or redundant information. This is an ideal level of conciseness for a simple search tool.

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 (9 parameters), the one-sentence description feels minimal. However, the presence of a comprehensive schema, annotations, and an output schema shifts the burden away from the description. Still, there is no mention of key features like filtering options or use cases, making the description adequate but not complete. It earns a 3 because it is functional but lacks the richness expected for a multi-parameter 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?

Schema description coverage is 100% with detailed parameter descriptions for all 9 fields. According to the rubric, this warrants a baseline of 3. The description does not add any supplementary parameter semantics beyond what the schema already provides, so it stays at baseline.

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: 'Search oral argument audio recordings in CourtListener.' It uses a specific verb ('search') and identifies the resource (oral argument audio recordings), which distinguishes it from sibling tools like search_opinions and search_dockets. The target resource is unambiguous and unique among the siblings.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or reference sibling tools such as search_opinions or get_audio. Users are left without a sense of the intended use case beyond the basic 'search audio recordings.'

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lower burden. The description adds the source context (PACER/CourtListener) but no additional behavioral traits such as pagination behavior, rate limits, or result completeness beyond what annotations provide. It does not contradict annotations.

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 a single, front-loaded sentence that conveys the core purpose without any unnecessary words. It is highly concise and well-structured, with no filler or redundant 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?

Given the complexity of 10 parameters and the presence of a detailed schema and output schema, the description is mostly adequate. It clearly identifies the search resource and source. However, it does not mention the relationship to 'search_dockets_with_documents' or any limitations regarding document text, which would be useful for a complete picture.

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 the parameters are already well-documented with descriptions for all 10 parameters. The tool description itself adds no parameter-specific meaning, but since the schema covers them fully, the baseline 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 searches federal cases/dockets from PACER in CourtListener, using a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'search_dockets_with_documents', which also searches dockets but with documents, leaving potential ambiguity about scope.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with other search tools like 'search_opinions' or 'search_dockets_with_documents'. The only implied usage is that it is for docket searches, but no explicit context is given.

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?

Annotations already signal read-only and open-world behavior. The description adds a non-obvious behavioral trait: at most three nested documents are returned, and more_docs indicates truncation, which is valuable beyond annotations. No contradiction.

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 short sentences, front-loaded with the core purpose, and the second sentence earns its place by disclosing the 'more_docs' flag behavior. 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 complex 10-parameter search tool, the schema covers all parameter semantics, annotations cover safety/open-world behavior, and an output schema exists for return values. The description adds the one missing element—the nested-document limit—making the combined specification sufficient.

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?

All 10 parameters are fully described in the input schema (100% coverage), so the description doesn't need to add parameter details. It doesn't add parameter-specific semantics beyond the schema, so baseline 3 applies.

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?

Description uses specific verb 'Search' and identifies resource 'federal cases (dockets)' with distinctive scope 'up to three nested documents,' which differentiates it from siblings like search_dockets and search_recap_documents. The key feature of nested document inclusion is front and center.

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?

Description implies the tool is for when you need dockets with associated documents and flags the three-document limit via more_docs. It doesn't explicitly name alternatives or exclusion criteria, so not a 5, but the context is clear enough for selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and result completeness. The description adds useful structural context with 'nested Opinion documents,' but does not disclose pagination behavior, API limits, or any other operational traits beyond annotations. The added value is modest.

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 a single concise sentence that front-loads the core action and resource. Every word contributes meaning, with no redundant phrases or 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?

With a detailed schema covering all parameters and an output schema present, the description does not need to explain return values. The description is sufficient for a search tool, though it could briefly mention full-text search semantics or CourtListener-specific behavior. Overall, it is complete enough given the structured 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?

All 11 parameters have descriptions in the schema, achieving 100% coverage. The tool description does not add extra meaning beyond the schema, so the baseline score of 3 applies.

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: 'Search case law opinion clusters with nested Opinion documents in CourtListener.' The verb 'search' plus the resource 'case law opinion clusters' provides a specific scope, and it distinguishes this from sibling search tools like search_dockets, search_audio, and search_people.

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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or alternatives, leaving the agent to infer usage solely from the tool name and sibling context. This is a gap for a search tool with many related options.

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?

Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral context beyond the basic search intent. It doesn't explain open-world matching, pagination behavior, or any special traits, so it adds minimal value over the annotations.

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 a single, front-loaded sentence with no unnecessary words. It earns every character and is perfectly concise.

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?

With a full output schema present and complete parameter descriptions, the brief description is largely sufficient for a simple search tool. The main gap is lack of guidance on query syntax and edge cases, but schema and annotations cover most needs.

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 the parameters are fully documented in the schema. The description adds no additional parameter-level meaning, 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 verb 'Search' and the resource 'judges and legal professionals' within the CourtListener database. This distinguishes it from sibling search tools like search_opinions and search_dockets.

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 use for finding people but provides no explicit guidance on when to use versus alternatives like get_person or other search tools. Context from sibling names helps, but there are no exclusions or comparison statements.

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?

The annotations already indicate this is a read-only, open-world operation. The description adds minimal behavioral context beyond that—it does not mention pagination, filtering capabilities, or response structure. No useful behavioral traits are disclosed beyond the purpose.

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 a single, front-loaded sentence with no filler or repetition. It communicates the essential purpose in a concise, easily parsed manner.

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 rich schema and output schema, the description only needs to provide high-level context, which it does. However, it lacks any guidance on when to use this tool, how it differs from related search tools, or hints about pagination behavior, leaving some gaps in 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?

The input schema provides 100% parameter descriptions, so the baseline is 3. The tool description adds no parameter-specific information, but the schema fully documents the query, filters, sort order, and pagination parameters.

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 identifies the tool's function: searching federal filing documents from PACER in the RECAP archive. This specific resource and scope distinguish it from sibling tools like search_opinions and search_dockets.

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 context by naming the RECAP archive, but it does not explicitly state when to prefer this tool over alternatives or provide any when-not guidance. No exclusions or alternative tool references are given.

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 behavioral disclosure burden. It discloses the return value structure (dictionary with status, system metrics, service information), implying a read-only check, but it does not address potential rate limits, authentication requirements, or whether it makes external network calls. The return description adds some value but lacks depth on side effects and operational 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?

Two concise sentences, front-loaded with the action ('Check the status'), and followed by a brief return-value summary. Every word earns its place; there is no fluff or repetition.

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 zero-parameter status tool with an output schema, the description adequately states purpose and return type. The return format (dictionary with status, system metrics, service information) gives sufficient context, and the presence of an output schema covers the specific fields. No additional complexity requires further explanation.

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 tool has zero parameters, and schema coverage is 100% (vacuously). The baseline of 4 applies for tools with no parameters; the description correctly omits parameter details since none exist. It does not need to add meaning beyond the 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 uses the specific verb 'Check' and resource 'status of the CourtListener MCP server,' clearly distinguishing this health-check tool from the many data retrieval and search sibling tools. It is immediately obvious what the tool does and how it differs from siblings.

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 context is clear: this is for checking server status. While it doesn't explicitly say when to use vs alternatives, there are no sibling tools with similar functionality, so the usage is unambiguous. It effectively implies that it should be used when server health or availability information is needed.

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