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

Annotations already cover the read-only/open-world safety profile, and the description goes well beyond them: return payload keys ('changes', 'identical'), the size-based omission behavior (texts_omitted), the changes_only bypass, date format constraints, snapshot availability variance, and the up_to_date_as_of ceiling. This is substantial disclosure 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?

Front-loaded with purpose, then return shape, then constraints — a sensible ordering where the 'short answer' framing for changes_only is a nice compression. It runs long across several short paragraphs, and a couple of constraint sentences could be tightened, but nothing is pure 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 6-param, 3-required comparison tool with an output schema, the description supplies everything an agent needs that the schema does not: date semantics, sizing caution, omission behavior, and discoverability path. Even though the output schema covers return shapes, the added operational caveats make this feel complete rather than redundant.

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, and it does for the important ones: date format (YYYY-MM-DD), what changes_only=True does, and the size/type constraint on section_id ('15.305', not a whole part). It does not explain the chapter parameter or the significance of title_number (defaulting to 48), leaving two of six params undocumented.

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?

Opens with a specific verb+resource+scope: 'Compare the text of a CFR section at two different dates.' It immediately differentiates from siblings by framing the task as amendment diffing rather than retrieval, and it names get_version_history as the companion tool for date discovery.

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?

States the use case ('understanding what changed in a regulatory amendment'), names the alternative tool for finding dates ('Use get_version_history to discover dates'), and gives exclusions/limits ('pass a small section_id like 15.305, not a whole part'). An agent knows when to pick this and what not to do with it.

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 it read-only, non-destructive, and open-world, and the description adds substantial behavior beyond them: normalization rules (case, hyphens, spacing, plurals, trailing 'means'), the two result kinds, the fallback chain with did_you_mean, and the truncation flag. This is far more than the structured fields 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?

Dense but front-loaded, leading with the purpose and then the matching and fallback behavior. Every sentence carries information, though the matching-rules sentence is long and a little list-heavy.

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?

Even though an output schema exists, the description defines the meaningful return shape (kind='definition' vs 'mention', defined_elsewhere, did_you_mean, truncated) and the fallback semantics an agent needs to interpret results. Complete for this 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 coverage is 0%, so the description must carry the load; it defines term's 3-character minimum and max_matches' default (20) and cap (100), plus the interaction between max_matches and truncation. The third parameter, date, is never mentioned, leaving one 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?

States a specific verb (find) plus resource (a term's definition in FAR 2.101) and scopes it to the FAR's main definitions section. It is clearly distinguishable from siblings like lookup_far_clause or search_cfr, which serve different retrieval needs.

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

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

Gives clear context for use, including the fallback path when 2.101 lacks the term (chapter 1 then chapter 2), and shows example inputs. It does not explicitly compare itself to a sibling search tool, but the intended usage is unambiguous.

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 carry the safety profile (readOnly, non-destructive), yet the description adds substantial behavior: removal vs amendment vs re-issue semantics, substantive=false for no-text-change, duplicate rows for twice-changed sections, summary counts, and pagination limits (per_page max 5000, total_pages). This is rich disclosure 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?

Front-loaded with purpose and change semantics, then parameters, then the common pattern – a sensible order. It is slightly padded by the line-break formatting and the redundant 'summary counts each kind' / 'appears twice' sentences, but nearly every line carries load.

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 present the description needn't define return shape, and it still explains the meaningful fields (summary, total_pages) at the business-logic level. Combined with full parameter documentation, an agent has everything needed to invoke and interpret results.

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

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

Schema coverage is 0%, so the description carries the full burden and does so: since_date format (YYYY-MM-DD), title default 48, chapter mapping (1=FAR, 2=DFARS, 99=CAS), part, per_page default/max, and page. Every one of the six parameters gains meaning not present 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?

States a specific verb+resource (+scope): 'Find CFR sections changed since a given date, removals included,' and immediately distinguishes itself via version-history semantics. An agent can tell this apart from get_version_history or compare_versions without opening a schema.

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 a concrete usage context ('find FAR changes since a specific date to check for regulatory updates') and the default filters that make that pattern work. It does not explicitly name which sibling to use instead (e.g., get_version_history for a single section), so it is clear context without 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the response indicates which date it describes, which is genuinely useful, but says nothing about permissions, rate limits, or failure modes for nodes that don't exist.

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 short paragraphs, front-loaded with the core purpose before the return shape and parameter notes. Minor redundancy between the first sentence and the second, which both restate the ancestry concept.

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 needn't be spelled out, and the description covers the main node parameters. However, for a 6-parameter tool with zero schema descriptions, the omission of title_number and any date-format detail leaves the definition partially incomplete.

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% across 6 parameters, so the description carries the full burden. It usefully states that part/subpart/section/appendix accept int or string and ties date to the response, but leaves title_number (default 48), required-ness, and the date parameter's format entirely undocumented.

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 names a specific verb (Get) and resource (ancestry/breadcrumb path) and enumerates the input node types (section, part, appendix). It clearly describes the returned hierarchy shape, but does not distinguish itself from siblings like get_cfr_structure 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?

It gives an implied use case ('useful for understanding where a section sits in the CFR hierarchy'), which is clear context, but there is no explicit when-to-use-vs-alternative guidance and no exclusions relative to get_cfr_structure or get_cfr_content.

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 safety is covered. The description adds crucial context: eCFR lags 1-2 business days, default returns parsed text with specific markers, pagination behavior for >60k characters, and chapter size warnings. This goes well beyond 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?

Front-loaded with the core purpose, then structured with bullet-point examples for each scope parameter. Every sentence earns its place by providing actionable detail. Despite length, it is information-dense and well-organized.

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

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

Has an output schema, so return format is partly covered, but the description supplements with parsing details, marker explanations (e.g., '[fn N]', pending_amendments), and pagination behavior. Covers all complexity for a 9-parameter tool with no required params.

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 documents all readable parameters: section, subpart, part, chapter, appendix, raw_xml, date, page, title_number. It provides syntax examples, explains auto-resolution, and warns against today's date. This is comprehensive.

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 a specific verb (Get) and resource (full text of a CFR section, subpart, part, or appendix). It differentiates from siblings by calling itself 'the primary workhorse for reading regulatory text', contrasting with search_cfr or get_cfr_structure for discovery.

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

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

Explicitly names when to use each scope (section for a single section, subpart for a subpart, part for an entire part, chapter for >1MB, appendices). It warns against using today's date due to eCFR lag and advises narrowest scope. This is rich practical 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 cover safety (readOnly, non-destructive, open world), yet the description still adds real behavioral detail: the 400 on section-level filtering, depth's replacement of deeper levels with 'children_omitted', automatic truncation of oversized trees with a 'note' field, and the Title 48 subchapter-needs-chapter constraint. These are failure modes an agent cannot infer from 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?

Front-loaded with the purpose and the critical limitation, then organized under a 'Common patterns' header. Slightly long and the parenthetical byte-size aside is nearly filler, but every block conveys distinct usable 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?

For a read-only tool with 8 optional selectors and an output schema handling return values, the description covers selection logic, depth/truncation behavior, and edge cases well. The only meaningful omission is guidance on the date parameter, which determines whether the agent queries get_latest_date first.

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% across 8 parameters, so the description carries the load and mostly does: depth semantics, subchapter/chapter coupling, int-or-string acceptance for part/subpart/chapter/appendix, and worked examples for each selector. It leaves the date parameter's meaning (which point-in-time to request, versus get_latest_date) and why title_number defaults to 48 unexplained.

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 a specific verb and resource ('Get the hierarchical table of contents for a CFR title or subset') and immediately differentiates itself from the sibling that overlaps most, list_sections_in_part, for getting sections of a single part. An agent can select this over the other 12 siblings without opening a schema.

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 exclusions ('Does NOT support section-level filtering (returns 400). Use part or subpart'), a named alternative for the narrowing case, and four concrete invocation patterns covering part, subpart, chapter+depth, and appendix. This is about as prescriptive as usage guidance gets.

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 readOnly/safe, but the description adds valuable context: the sort order, the truncation flag, the default/max limits, and the approximate data volume ('~280 corrections since 2005'). It does not mention auth or rate limits, but for a read-only tool this is solid added 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?

It is front-loaded with purpose and behavior, then parameters. It is slightly long but every sentence earns its place except perhaps the redundant restatement of sorting behavior.

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 present, the description needn't detail return values, and it covers purpose, filtering semantics, sort order, limits, truncation, and data scale. An agent can invoke it correctly without further info.

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 parameter meaning. It explains section/part/chapter semantics (hierarchical filtering), since_year (year >= threshold), limit (default 50, max 1000), and truncated, compensating well for the missing schema descriptions, though title_number's default of 48 is left implicit.

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 ('Get editorial corrections for a CFR title') and the sorting behavior ('newest first'), which distinguishes it from siblings 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?

It gives clear context for use ('checking whether a section's current text has been corrected since its last amendment') but does not explicitly name alternatives or state when not to use it versus siblings like get_version_history.

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 readOnly/openWorld/non-destructive, and the description adds real behavioral context beyond them: full read of every eCFR page (Part 52's 2,264 versions), versions grouped by section oldest-first, the meaning of the 'substantive' and 'removed' flags, pagination defaults, and the realistic failure mode (a missing old snapshot yields an availability error). This is unusually thorough disclosure 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?

Front-loaded with purpose and return shape, then params, then semantics and caveats in short paragraphs. Dense and useful overall, though slightly long and mildly repetitive around the availability/2017-baseline caveat.

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?

Covers the hard parts an agent needs—the return shape, flag semantics, pagination, and the pre-2017 snapshot availability trap. Since an output schema exists it need not describe returns, and the only substantive omission is the undocumented title_number parameter.

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 the params and mostly does: date formats for since_date/until_date, per_page default/max, page, and that part/subpart/section accept int or string. It never mentions title_number (default 48) nor whether part/subpart/section are mutually exclusive, leaving a gap in an otherwise strong pass.

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?

Opens with a precise verb+resource+scope: 'Get the version history of a CFR section, subpart, or part.' It also names the sibling to use instead for a related need (compare_versions), so an agent can place it among the 13 siblings without opening a schema.

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?

Clear routing advice: 'To see what actually changed, use compare_versions on the dates,' plus guidance on when since_date/until_date and pagination matter and when a 2017-01-01 baseline implies no change. No explicit when-not-to-use statement, but the conditions are well covered.

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 readOnlyHint/openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: pagination semantics ('page and total_pages say where you are; page=2 gets the rest'), the 680-entry scale warning, and the exact meaning of detail's received_on field. No auth or rate-limit detail, hence not a 5.

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?

Front-loaded with the core action and return shape, then layered with parameter guidance. Dense but all sentences carry information; the parenthetical examples (2 CFR 200 Appendix I-XII, 52/252/552) earn their space. Slightly long for the payload.

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-value explanations are technically optional, yet the description still clarifies what an agent needs to paginate and interpret entries. The only substantive hole is the undocumented `date` parameter, which for a versioned regulatory lookup is a real 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 description coverage is 0%, so the description carries the full burden and does explain part_number type flexibility, chapter optionality with FAR/DFARS/GSAR examples, subpart ('52.2'), page, detail, and the title_number default of 48. However, the `date` parameter is never mentioned, leaving one of seven params with no semantics anywhere.

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?

Opens with a specific verb+resource+scope: 'List all sections and appendices in a CFR part with their headings.' It names concrete return artifacts (sections, subparts, type='appendix', reserved=true) and contrasts against the sibling that reads content ('before reading specific sections'), so an agent can distinguish it from get_cfr_content without opening schemas.

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

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

Gives clear usage context ('seeing the scope of a part before reading specific sections') and routes a nuance to a sibling: detail=True's received_on is explicitly not amendment dates, and get_version_history is named as the right tool for those. It stops short of explicit when-not-to-use or prerequisites.

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 readOnly/openWorld/destructive, but the description adds real behavioral value: auto-resolution of the latest date, parsed output contents (headings, paragraphs, tables, notes vs clause text), and a concrete pagination rule ('clause longer than about 60,000 characters comes in pages: use page=2'). The only gap is rate/limit or freshness caveats, which are minor here.

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?

Front-loads the one-line purpose, then groups format handling, resolution behavior, output shape, and examples. It is a bit long, and the 'Common FAR sections' list and 'see get_cfr_content' pointer stretch it, but every block is scannable and earns its place for selection.

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 single-lookup tool with an output schema, the description covers selection, identifier formats, pagination, and result composition. The remaining gap is the lack of explicit routing against its closest siblings (search_cfr, get_cfr_content, find_far_definition).

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 load and does so well: it demonstrates section_id formats and tolerated prefixes/en-dashes/trailing cites, and derives chapter from the number. page is explained via the pagination rule. date is only described as auto-resolving the latest available date, leaving its override semantics slightly vague.

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 a specific verb and resource ('look up the current text of a FAR, DFARS or FAR supplement section or clause') and names the sibling it defers to ('see get_cfr_content'). An agent can distinguish it from search_cfr and find_far_definition without opening any schema.

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?

Explains the calling context clearly: pass a section identifier, chapter is optional because it derives from the number, and it lists common sections to guide selection. It stops short of explicit when-not-to-use guidance versus search_cfr or find_far_definition, so it is context-clear but not exclusionary.

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?

Despite readOnly/destructive/openWorld annotations already covering safety, the description adds substantial non-obvious behavior: the current_only version-history filtering, dropping superseded/removed hits with dates, the 'up to 10 parts per page checked' limit and unchecked markers, and the 10,000 result cap. This is exactly the behavioral context annotations can't 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?

Front-loaded with purpose and return shape, then organized by parameter group. Information density is high and nearly every sentence carries a distinct fact, though the multi-line current_only explanation is somewhat verbose relative to the rest.

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 13-param search tool, the description covers filtering, ordering, pagination, date filtering, result caps, and version-history edge cases. With an output schema present it needn't restate return fields, yet it still flags the current_check structure, leaving nothing essential for correct invocation 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?

With 0% schema description coverage across 13 parameters, the description carries the full burden and does so: order's five enumerable values, agency_slugs format and list-acceptance, YYYY-MM-DD format for last_modified_after/before, per_page 1-5000 (default 20), page pagination, current_only default semantics, and the title-dependency of chapter/part/subpart/section filters.

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?

Starts with a specific verb+resource: 'Full-text search across the Code of Federal Regulations,' and immediately clarifies the return shape (sections with excerpts, headings, scores, hierarchy). An agent can distinguish it from siblings like get_cfr_content or get_cfr_structure without opening the schema.

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

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

Gives concrete usage guidance: use hierarchy filters to narrow when hitting the 10,000 cap, use list_agencies() to find valid agency slugs, and explains the title-assumption fallback. It lacks explicit when-not-to-use / sibling-alternative routing, so it falls 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.