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

The description goes well beyond the annotations. It discloses that the tool returns parsed section-level XML side by side, warns about size limits for whole-part comparisons, and specifies the date range and validation constraints. This additional behavioral context (e.g., 'always returns', 'can exceed 100 KB per side') is valuable for the agent, and there is no contradiction with the readOnlyHint and destructiveHint 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 efficient: four sentences, front-loaded with the primary purpose, then usage context, constraints, and a warning. Each sentence adds necessary information without redundancy. It is concise yet thorough, making it easy for an agent to parse quickly.

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 and the existence of an output schema, the description covers the essential contextual details: what it returns, how to pass parameters, and key limitations. It does not explain the exact output structure (handled by schema) or the order of date_before vs date_after, but that is minor. Overall, it is sufficiently complete for an agent to call 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It explains section_id format ('like '15.305'', small section only) and date format and range, which are the core parameters. It does not elaborate on chapter or title_number, but these have defaults and are somewhat inferable from the CFR context. Thus, it adds meaningful semantics for the most critical parameters but not all.

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 compares the text of a CFR section at two different dates. It uses a specific verb ('Compare') and resource ('CFR section'), and the purpose is further clarified as understanding regulatory amendments. It distinguishes itself from siblings like get_version_history by focusing on text comparison rather than just version lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context ('Useful for understanding what changed in a regulatory amendment') and includes practical constraints (date format, range, up_to_date_as_of limit). However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of the highest level which requires explicit when/when-not 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 mark readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: it fetches the full section server-side, parses it, and returns only matching paragraphs. This clarifies the internal operation and return behavior beyond the annotation, though it does not address auth or rate limits (likely not needed for a read tool).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: it opens with the core purpose, adds a brief contextual note, then covers performance and parameter constraints. Every sentence adds value 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 straightforward: search a term in a known section. The description covers the operation, the size/performance caveat, and parameter constraints. With an output schema present, it does not need to describe return values. The only minor omission is the role of the 'date' parameter, but overall the description is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the required term ('must be at least 3 characters') and max_matches (default 20, max 100, with an example of common terms). The optional 'date' parameter is not described, which is a minor gap, but the other parameters receive useful clarification that the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search') and resource ('FAR 2.101 master definition section'), clearly distinguishing this tool from siblings like search_cfr or lookup_far_clause. It immediately communicates the tool's purpose: finding definitions of a term.

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 explains the context (FAR 2.101 contains definitions) but does not explicitly contrast with sibling tools or state when to prefer this over search_cfr or lookup_far_clause. It gives a performance caveat about the large section, but no direct usage guidance 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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it uses the search API with a specific filter, returns results most recently amended first, and caps at 10,000 results. It also notes the date format requirement. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear first sentence stating the purpose, followed by mechanism details, parameter guidance, and a practical use case. Every sentence adds value, and the most important information (what it does) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for an agent to call this tool correctly. It covers the purpose, the key parameter format, result ordering, result caps, and narrowing strategies. The output schema exists, so return values don't need to be described. The annotations cover safety. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the key parameter since_date (format YYYY-MM-DD) and mentions title/chapter/part filters for narrowing. It doesn't detail per_page, but the default of 100 is in the schema and the description's mention of the 10,000 cap provides context. This is strong compensation for a 0% coverage 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 tool's purpose: finding CFR sections modified since a given date. It specifies the verb ('Find'), the resource ('CFR sections'), and the key constraint ('modified since a given date'). It also distinguishes itself from siblings like search_cfr by describing the specific use case and filter mechanism.

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 explicitly explains when to use this tool: to find recent changes to CFR sections, with a common pattern example (FAR changes). It also provides guidance on narrowing results with title/chapter/part filters and notes the 10,000 result cap, which helps the agent decide when to add filters.

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 readOnlyHint and destructiveHint annotations already establish a safe read operation. The description adds useful behavioral context by specifying that the result is an ancestor chain from title down to the requested node. It does not contradict 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 compact and front-loaded, with the core action and hierarchy shape stated early. The final sentence about accepted types is somewhat redundant with the schema but not excessive.

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 description covers the return shape and intended use, and the output schema covers return values. However, with five optional-looking parameters and no required fields, it does not fully explain invocation constraints such as whether exactly one of part/section/appendix should be supplied or how date affects the ancestry path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only restates that part/section/appendix accept int or string, which is already visible in the schema. It does not explain the date or title_number parameters, nor clarify how many targets should be supplied.

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 the breadcrumb hierarchy path' for a section, part, or appendix. It clarifies the output shape ('title > chapter > subchapter > part > subpart > section') and distinguishes this ancestry lookup from the sibling structure/content tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: 'useful for understanding where a section sits in the CFR hierarchy and what regulation it belongs to.' However, it does not explicitly name alternative sibling tools or state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: default clean parsed text with headings/paragraphs/citations/tables/editorial notes, raw_xml behavior, date auto-resolution and lag warnings, automatic prefix stripping, and resolution of trailing paragraph cites. This goes far beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place, covering behavior, scoping, date caveats, title/chapter mapping, and input normalization. It is front-loaded with the core purpose and return format, then layers practical usage guidance.

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 high-complexity tool with 8 parameters and zero schema descriptions, the description is remarkably complete: it explains output contents, scoping strategies, date behavior, title/chapter semantics, DFARS clause usage, and parameter type flexibility. Because an output schema exists, return-value detail need not be repeated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden, and it delivers: every parameter (date, part, chapter, raw_xml, section, subpart, appendix, title_number) receives meaningful explanation, with concrete examples and type/coercion notes. It even covers edge cases like 'FAR 15.305' prefix stripping and '15.305(a)(2)' resolving to the base section.

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 opens with a specific verb and resource: 'Get the full text of a CFR section, subpart, part, or appendix.' It further differentiates itself as the 'primary workhorse for reading regulatory text,' which sets it apart from sibling search, structure, and listing tools. The scope is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear contextual guidance: use the narrowest scope to keep responses manageable, avoid chapter-level pulls, set raw_xml only when needed, and avoid today's date due to eCFR lag. It does not explicitly name sibling alternatives or say 'use search_cfr instead when...', so it stops short of a full when-not/alternatives treatment.

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 establish readOnlyHint and destructiveHint, so the description doesn't need to restate safety. It adds valuable behavioral context: the return format (identifiers, descriptions, byte sizes) and the limitation of section-level filtering. This goes beyond the annotations and helps an agent predict behavior, though it doesn't cover all edge cases like error handling for invalid combinations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: main function, return details, an important warning, common patterns, and type conventions. Every sentence adds value without redundancy, and the critical limitation is front-loaded. The length is justified by the density of actionable 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?

The description covers the tool's main purpose, return structure, key limitation, and typical usage patterns. It lacks detail on some parameters (date, subchapter) and error behavior, but the information provided is sufficient for an agent to use the tool correctly in most cases. The output schema also helps, so the description doesn't need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain parameter semantics. It provides examples for chapter, part, and subpart, and notes that part/subpart/chapter/appendix accept int or string. However, it does not explain the date, subchapter, or title_number parameters beyond the default value. The given examples are useful but leave significant gaps for a multi-parameter tool.

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 'Get the hierarchical table of contents for a CFR title or subset,' which clearly states the verb, resource, and scope. It then specifies the output as a nested tree of titles, chapters, parts, subparts, and sections. This unambiguously differentiates it from sibling tools like get_cfr_content or search_cfr.

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 explicit usage guidance, including an IMPORTANT warning about section-level filtering not being supported (returns 400) and recommending to use part or subpart then walk the children. It also lists common patterns with concrete examples (chapter='1' for FAR, part='15', subpart='15.3'), making it clear when and how to call this tool.

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

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

Annotations already establish the tool as readable and non-destructive, and the description adds concrete behavioral detail: the returned fields list and caps, plus limit-based and since_year filtering. It doesn't cover pagination or explicit max behavior beyond the limit cap, but that's appropriate for a simple read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: action, return value, use case, then parameter guidance. The empirical Title 48 correction count earns its place by making the since_year advice concrete and actionable.

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 output schema exists and the tool is read-only, the description covers return contents, usage context, and the two configurable parameters meaningfully. Title_number is implicit, but adding a direct one-line explanation would make the already self-contained description fully explicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the semantic weight. It explains limit's default and max and since_year's filtering behavior, and while title_number is not mentioned by name, the opening line's 'CFR title' makes its meaning clear enough.

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?

States 'Get editorial corrections for a CFR title,' identifying a specific verb, resource, and scope. The description explains it returns a list of corrections and frames its use case around checking whether a section's text has been corrected, distinguishing it from sibling tools like get_version_history or find_recent_changes.

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 a clear use case: checking whether a section's current text has been corrected since its last amendment, and recommends using such to focus recent corrections. It does not mention explicit alternatives or when not to use the tool, so it stops short of full 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?

While annotations already mark the tool as read-only and non-destructive, the description adds crucial behavioral details: the data lag (1-2 business days), the resulting 404 error on versioner endpoints with today's date, and the ValueError on reserved titles. This goes beyond the structured annotations and gives the agent essential knowledge to sequence calls correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long, but every portion serves distinct purposes: the warning highlights a critical usage timing, the title mapping gives practical examples, and the error note sets expectations. The layout is clear, starting with the main purpose, then the caution, then defaults/exceptions. Some redundancy exists but overall it remains focused and front-loaded with the most important safety note.

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) and has an output schema; the description covers all that an agent needs before the call: when to use, what default to rely on, which titles are meaningful, and what exceptions to expect. It does not attempt to describe the return structure (unnecessary due to the output schema) but still completes the contextual picture of why this tool exists and how to safely call 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 the integer type and default, but no further meaning. The description compensates by clarifying the default is title 48, listing other common titles, and implicitly stating that valid titles are 1-50 via the error condition. This is valuable semantic grounding for an otherwise bare schema, though the description does not explicitly duplicate the parameter name 'title_number'.

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 the tool's specific action: 'Get the most recent available date for a CFR title.' This clearly distinguishes it from siblings like get_version_history or find_recent_changes which focus on changes or versions. It also explicitly mentions the fallback usage as a pre-call for other endpoints.

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 explicit when-to-use instructions: 'Call this first to get the safe date, then pass it to other tools' for avoiding 404 errors. It includes a concrete warning about eCFR lag and explains partial error behavior with reserved titles, effectively instructing the agent on the proper invocation context. It also provides default and common titles to manage expectations.

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 destructiveHint=false, so the safe-read profile is covered. The description adds genuine behavioral value: the January 2017 coverage limit, the semantics of the 'substantive' field, and the fact that pre-2017 changes are not tracked. These go beyond the structured data and meaningfully shape an agent's expectations.

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?

Five short sentences, each pulling weight: purpose, return shape, key-field semantics, coverage limitation, and parameter flexibility. The material facts are front-loaded and the structure is scannable, with only slight redundancy (the January 2017 point is stated twice).

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 an output schema and annotations covering safety, the description covers the essential behavioral facts: target selection, return orientation, the key field's meaning, and date-range coverage. The only notable hole is the parameter-interaction semantics described above, which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does clarify that part/subpart/section accept int or string, and that the three identify the target CFR element. However, it does not explain how the parameters interact (e.g., whether they are mutually exclusive, whether a combination is allowed, or what title_number selects) — a real gap at 0% 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 states a specific verb and resource ('Get the version history of a CFR section, subpart, or part') and expands on what is returned (dates, amendment info, substantive-vs-editorial flag). It is clearly distinguishable from siblings like get_cfr_content, get_cfr_structure, get_corrections, and compare_versions by its focus on historical versions.

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 context is implied rather than explicit: an agent can infer 'use this when you need the version history of a CFR element,' but the description never names alternatives or gives when-not-to-use guidance. It does add a concrete constraint (history only back to January 2017), which helps scope expectations, but it does not route to compare_versions or find_recent_changes as 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 mark the tool as readOnly and non-destructive; the description goes well beyond this by explaining that summary_only strips children and most cfr_references, merges child-owned references into the parent row, and changes payload size from ~100 KB to ~20 KB. The DFARS example clarifies a subtle consequence of that merging, which is exactly the kind of behavioral nuance an agent needs.

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 five sentences with the core action and return information first, followed by a concrete use case and then parameter details. Each sentence adds distinct value with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema and only one optional boolean parameter; the description covers the tool's purpose, return fields, the summary mode's data implications, and how to opt out. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only gives the parameter a title and default, with no descriptive text. The description fully explains summary_only: it strips children and most cfr_references, merges child-owned references into the parent row, and setting False returns the full raw payload. This thoroughly compensates for the 0% schema description 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 opens with a specific verb ('List'), a clear resource ('all agencies'), and a scope ('with their CFR title and chapter references'), more specific than the tool name alone. It further states the return fields (agency names, slugs, CFR titles/chapters), making it easy to distinguish from siblings like get_cfr_content or list_sections_in_part.

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 line 'Useful for finding which chapter corresponds to an agency's FAR supplement' gives a concrete scenario for selecting this tool, which is clear usage guidance. It does not explicitly name alternative tools or say when not to use it, 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 the tool read-only and non-destructive, so the bar is lower. The description adds that it returns a flat list of sections and clarifies chapter defaults, but it does not disclose details about pagination, error behavior, or open-world data changes.

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 succinct and front-loaded. Every sentence earns its place: purpose, output shape, usage hint, and parameter guidance. No filler is present.

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 listing tool with an output schema and protective annotations, the description provides enough to call it successfully with part_number and chapter. The main gap is the unexplained 'date' and 'title_number' parameters, though their defaults reduce immediate risk.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must carry parameter meaning. It explains that chapter='1' is FAR and chapter='2' is DFARS, and that part_number accepts int or string, but date and title_number are left undocumented, requiring agent inference.

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 action and resource: 'List all sections in a FAR/DFARS part with their headings.' It adds that the result is a flat list extracted from the structure tree, which helps separate it from sibling tools like get_cfr_structure, though it does not name an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to use the tool: 'Useful for understanding the scope of a FAR part before drilling into specific sections.' It also explains the chapter parameter for FAR vs DFARS, but does not mention when not to use it or suggest an alternative tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it auto-resolves the latest date and returns 'parsed clean text with heading, paragraphs, and citations.' It also explains the chapter parameter for DFARS vs FAR. 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?

The description is efficiently front-loaded with the purpose and then provides structured examples. The list of common sections is a bit extra but still useful for an agent. It is appropriately sized, each sentence earns its place, and the format is clear with line breaks and bullet-like enumeration.

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 intermediate complexity (multiple chapters, date handling, structured output), the description covers most inputs and outputs, especially since an output schema exists. However, it omits explanation of the date parameter and does not mention error behavior (e.g., what happens if the section is not found). The presence of an output schema lowers the burden for return-value details, but the missing date parameter leaves a notable hole.

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 has 0% description coverage, so the description must compensate for all parameters. It thoroughly explains section_id with examples and chapter with a default and DFARS example. However, the 'date' parameter is completely unexplained; while the description mentions 'auto-resolves the latest available date,' it never clarifies how a provided date interacts with that behavior. For a tool with three parameters and zero schema documentation, leaving one unexplained is a significant gap.

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: 'look up the current text of a FAR or DFARS clause.' It specifies the resource (FAR/DFARS) and provides concrete examples ('15.305', '52.212-4'), making it easy for an agent to understand what this tool does and distinguish it from broader content-retrieval tools like 'get_cfr_content'.

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 labels the tool as a 'Convenience tool' and gives typical section IDs, implying it is for quick clause lookups. However, it does not explicitly state when to prefer this over siblings like 'find_far_definition' or 'search_cfr', nor does it mention any conditions where it should not be used. The guidance is implicit rather than explicit.

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 substantial behavioral context beyond the read-only annotations: the critical current_only behavior and historical-version duplication, the 10,000-result cap, the meaning of each order option, and how agency_slugs and date filters behave. This is exactly the kind of non-obvious tool behavior an agent needs to invoke it safely and correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, front-loading the core purpose and return format before the critical current_only warning and parameter details. A few points duplicate schema defaults, such as current_only defaulting to true and per_page defaulting to 20, but the redundancy is minor given the importance and the lack of schema-level descriptions.

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 search tool with 13 parameters and no schema descriptions, this description is complete: it covers the key edge cases (historical versions, result caps, ordering, agency slugs, date filtering, pagination), describes the return shape, and works with the read-only annotations and output schema to give an agent everything needed to call 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 0%, so the description must carry the burden of parameter documentation, and it largely does. It explains order values, current_only, agency_slugs format, last_modified date format, per_page range, pagination via page, and hierarchy narrowing via title/chapter/part. Section and subpart parameters are not explicitly described, but their names and the hierarchy context make them understandable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and resource: 'Full-text search across the Code of Federal Regulations.' It also states what is returned — matching sections with excerpts, headings, scores, and hierarchy — which clearly distinguishes this from content-retrieval siblings like get_cfr_content and list_sections_in_part.

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 detailed, practical guidance for when to adjust parameters: use current_only to avoid historical duplicates, use hierarchy filters when hitting the 10,000 cap, and use last_modified dates for finding recent regulatory changes. It does not explicitly contrast this tool with alternative search/lookup siblings, but the context for using parameters is clear and actionable.

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