Server Quality Checklist

Tool Scores

• find_far_definitionA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark it as read-only and non-destructive. The description adds valuable behavioral context: it fetches the full section server-side, parses it, and returns only matching paragraphs, noting that common terms may yield many results. It also mentions the large file size (~109KB XML), which helps set performance expectations.

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

  Conciseness4/5

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

  The description is two paragraphs with no unnecessary words. The first paragraph states the core purpose, and the second paragraph adds important usage notes. It is well-structured and front-loaded, though slightly longer than strictly necessary.

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

  Completeness4/5

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

  Given the tool's complexity (large XML, server-side parsing, multiple parameters) and the presence of an output schema, the description covers most essential aspects: what it does, how it works, key constraints, and parameter details. It does not describe return format, but the output schema likely handles that. Overall, it provides sufficient context for an agent to use it correctly.

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

  Parameters4/5

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

  With 0% schema description coverage, the description must compensate. It clarifies that 'term' must be at least 3 characters and explains 'max_matches' default (20) and maximum (100). However, the 'date' parameter is not described, leaving its purpose unclear. The added constraints and defaults are helpful, but incomplete coverage for date prevents a higher score.

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

  Purpose5/5

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

  The description clearly states the tool searches for a term's definition within a specific, well-known source (FAR 2.101). It uses a specific verb ('search') and resource ('FAR 2.101 definitions'), and explains the behavior of fetching the full section and returning matching paragraphs. This sets it apart from sibling tools like 'lookup_far_clause' or 'search_cfr' which serve different purposes.

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

  Usage Guidelines3/5

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

  The description indicates the tool is for finding definitions in FAR 2.101 and mentions constraints such as term length and max_matches caps. However, it does not provide explicit guidance on when NOT to use it or suggest alternatives among the sibling tools, leaving the agent to infer use cases.

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

• find_recent_changesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details beyond that: it uses the search API with last_modified_on_or_after, returns items most recently amended first, and caps at 10,000 results. No contradictions.

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

  Conciseness5/5

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

  Four tight paragraphs, each carrying distinct information: purpose, method, constraints, and a usage pattern. No filler or repetition; the most important detail is front-loaded in the first sentence.

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

  Completeness4/5

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

  Given read-only annotations, an output schema, and 5 parameters, the description covers the key operational constraints: date format, result cap, filtering, and intended use. It could add pagination details or per_page semantics, but overall the agent has enough to select and invoke it correctly.

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

  Parameters3/5

  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 since_date format and that title/chapter/part can narrow results, but does not clarify per_page behavior or the default title=48, leaving some parameters underspecified.

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

  Purpose5/5

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

  The description states a specific verb ('find') and resource ('CFR sections modified since a date'), with clear scope. It distinguishes itself from siblings by focusing on recent modifications and sorted recency, unlike search_cfr or get_version_history.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use the tool: checking for regulatory updates affecting acquisitions. It advises narrowing with title/chapter/part filters when needed, but does not explicitly name alternative 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.

• get_ancestryA
  4.2/5.0
  Behavior4/5

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

  The description discloses that it returns ancestors in a specific order and notes that part/section/appendix accept int or string, which adds useful behavioral context beyond the readOnlyHint/destructiveHint annotations. It does not discuss potential edge cases (e.g., conflicting inputs) or response size, but given the annotations, this is sufficient.

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

  Conciseness5/5

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

  The description is three sentences with no fluff. It front-loads the purpose, gives the return format, and adds usage context, all efficiently. Every sentence adds value, making it highly concise.

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

  Completeness4/5

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

  Considering the tool has five optional parameters and an output schema, the description explains the main output (ancestor path) and type handling for three parameters. However, it omits details about date and title_number, which may be inferred but are not explicitly covered. Given the complexity, the description is mostly complete but has minor gaps.

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

  Parameters3/5

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

  With 0% schema description coverage, the description must compensate. It mentions that part/section/appendix accept both integer and string, but leaves date and title_number unexplained. This provides partial guidance but does not fully cover all five parameters, so the semantics are incomplete.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Get the breadcrumb hierarchy path') and specifies the target resources (section, part, or appendix). It also outlines the returned hierarchy format (title > chapter > subchapter > part > subpart > section), which distinguishes it from sibling tools like get_cfr_structure that likely return broader structural data.

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

  Usage Guidelines4/5

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

  The description provides a clear use case ('Understanding where a section sits in the CFR hierarchy and what regulation it belongs to') but does not explicitly contrast with alternative tools such as get_cfr_structure or get_cfr_content. The intended context is clear, though explicit exclusions are absent.

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

• get_version_historyA
  4.2/5.0
  Behavior4/5

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

  With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it explains the output fields (including the key 'substantive' field), the date range limitation, and the accepted input types. This goes beyond the annotations and helps the agent understand what to expect without contradicting the read-only nature.

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

  Conciseness5/5

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

  The description is well-structured and concise: first sentence states the core purpose, second paragraph explains the key field, third mentions the date limitation and parameter types. Every sentence adds meaningful information with no fluff or redundancy, making it easy to scan.

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

  Completeness4/5

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

  Given the output schema exists, the description does not need to detail return format. It covers the critical 'substantive' field, the date limitation, and input types. However, it does not explain how to specify which CFR part/section/subpart is being queried (e.g., whether all are optional but at least one is needed). This is a minor gap but not fatal, as the sibling tools like get_cfr_structure provide context.

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

  Parameters3/5

  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. It does mention that part/subpart/section accept int or string, which is useful. However, it does not explain which parameter is required (if any), how they interact, or the meaning of title_number (default 48). The tool is for a specific CFR citation but lacks guidance on constructing a valid query, leaving ambiguity.

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

  Purpose5/5

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

  The description clearly states the tool retrieves version history for a CFR section, subpart, or part. It identifies the returned data (dates, amendment info, substantive/editorial change) and explicitly explains the 'substantive' field, distinguishing this tool from siblings like compare_versions (which compares specific versions) and get_latest_date (which only returns a date).

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

  Usage Guidelines4/5

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

  The description provides clear context: it states the history only goes back to January 2017, implying when not to use it (for pre-2017 changes it won't be helpful). It also explains that the 'substantive' field indicates regulatory changes. However, it does not explicitly name alternative tools or state when to choose this over similar ones like find_recent_changes, though the scope difference is implicitly clear.

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

• list_sections_in_partA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds behavioral detail: "Returns a flat list of sections extracted from the structure tree," which clarifies the extraction method and result format. It also explains the chapter semantics and part_number type. This adds value beyond 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.

  Conciseness5/5

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

  The description is four concise sentences, each adding meaningful information: function, return type, usage context, and parameter type hints. There is no fluff or redundancy. It is front-loaded with the primary action and efficiently expands with necessary details.

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

  Completeness4/5

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

  The tool is a simple read-only listing operation with an output schema present (though not shown, the signal indicates it exists). The description covers the key aspects: what it lists, how it behaves (flat list from structure tree), and clarifies the most important parameter (chapter). Given the simplicity and the existence of an output schema, the description is sufficiently complete, though it could mention sorting or limits if any exist.

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

  Parameters3/5

  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 for parameter clarity. It explains chapter (default '1' for FAR, '2' for DFARS) and states part_number accepts int or string. However, it does not address the 'date' or 'title_number' parameters at all. With 4 parameters and only partial explanation, the description leaves room for ambiguity, though it covers the most important ones.

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

  Purpose5/5

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

  The description clearly states the verb and resource: "List all sections in a FAR/DFARS part with their headings." It specifies the scope (FAR/DFARS part) and output (flat list of sections), which distinguishes it from siblings like get_cfr_structure (tree structure) and get_cfr_content (content retrieval). This is a specific and unambiguous purpose.

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

  Usage Guidelines4/5

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

  The description provides context: "Useful for understanding the scope of a FAR part before drilling into specific sections." It also clarifies the chapter parameter: "Default chapter='1' (FAR). Use chapter='2' for DFARS." This gives actionable guidance on when to use it, though it doesn't explicitly name alternative tools or state when not to use it. Good but not exhaustive.

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

• get_cfr_structureA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by warning about the 400 error for section-level filtering and clarifies that part/subpart/chapter/appendix accept int or string (matching schema). It also describes the return structure (nested tree with identifiers, descriptions, byte sizes). This goes beyond annotations, though it does not mention potential output size or performance limits.

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

  Conciseness4/5

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

  The description is well-organized with a clear opening sentence, a highlighted warning, and a bullet-like list of common patterns. It front-loads the core purpose and adds essential details without redundancy. Though slightly verbose, every sentence contributes value; it earns its length.

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

  Completeness5/5

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

  Given the output schema exists, the description need not explain return values. It covers the hierarchical levels returned, parameter constraints (int/string), common usage, and the critical limitation. It also handles the optional title_number (default 48) implicitly through examples. For a read-only structure tool, this is complete and fully actionable.

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

  Parameters3/5

  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 types for part, subpart, chapter, and appendix ('accept int or string') and provides usage examples, but it omits date, subchapter, and title_number. While the schema already specifies types, the description adds patterns for a subset, leaving other parameters undocumented. This is only partial compensation.

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

  Purpose5/5

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

  The description clearly states the tool's function: returning the hierarchical table of contents for a CFR title or subset. It specifies the resource (CFR titles/chapters/parts/etc.) and distinguishes it from siblings like get_cfr_content (content vs structure) and list_sections_in_part (specific listing vs tree). The verb 'Get' and the explicit scope make purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance with common patterns (chapter='1' for FAR, chapter='2' for DFARS, part='15', subpart='15.3') and a clear when-not-to-use note: section-level filtering is not supported and returns a 400 error. It advises to use part or subpart then walk children to find sections, which is actionable and prevents misuse.

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

• get_correctionsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the returned data (CFR references, corrective actions, error dates, FR citations) and the effect of parameters (limit caps, since_year filters). No contradictions. It does not describe authentication or rate limits, but given the read-only nature, this is acceptable.

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

  Conciseness5/5

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

  The description is short, with a clear lead sentence, a bullet-point-like list of returned fields, a use case, and parameter details. Every sentence adds value, and no redundant information is present.

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

  Completeness5/5

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

  Given the tool's simplicity (3 parameters, read-only retrieval) and the presence of an output schema, the description covers all essential aspects: what the tool does, what it returns, parameter behavior, and a concrete example. No critical information is missing.

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

  Parameters4/5

  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 'limit' (default 50, max 1000) and 'since_year' (filters to year >= year, with an example for Title 48). 'title_number' is implicitly covered by the main purpose phrase. The description adds meaningful context beyond the schema's bare field names and defaults.

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

  Purpose5/5

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

  The description clearly states the verb ('Get') and the resource ('editorial corrections for a CFR title'). It lists the returned fields, making the purpose specific. The tool is distinct from siblings like compare_versions or get_cfr_content, which are about different operations.

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

  Usage Guidelines4/5

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

  The description provides a use case ('checking whether a section's current text has been corrected since its last amendment') and explains parameter filters (limit, since_year). However, it does not explicitly mention when not to use this tool or list alternative tools for similar tasks, leaving some room for ambiguity.

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

• compare_versionsA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds important behavior: always returns section-level XML, indicates size limits, and describes return format (parsed text side by side). It could add more on error cases (e.g., what happens if dates invalid), but given annotations, this is solid. 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.

  Conciseness5/5

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

  Well-structured: opening sentence states core purpose, then usage guidance, then a warning about size. Each sentence adds value, no fluff. Front-loaded with the verb and resource. Appropriate length for a compare tool with important constraints.

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

  Completeness5/5

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

  Given the tool has an output schema and annotations, the description covers the essential usage constraints, date formatting, size limit, and the nature of the return (parsed text side by side). It's complete for a read-only comparison tool with clear input requirements. Potential gaps like exact output structure are covered by the output schema.

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

  Parameters4/5

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

  Schema coverage is 0%, but description explicitly explains date format (YYYY-MM-DD), the meaning of section_id (small section like '15.305', not whole part), and the date range constraints. It clarifies title_number default? Not directly, but 'title' context is implied. The description compensates well for missing schema descriptions, adding meaning beyond bare parameter names. It doesn't mention 'chapter' parameter, but the focus on section_id and dates is the main semantics.

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

  Purpose5/5

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

  Description clearly states it compares text of a CFR section at two dates, with specific scope (section-level, not whole part), and differentiates from siblings like get_version_history or get_cfr_content by emphasizing side-by-side text comparison for diffing. The resource (CFR section) and verb (compare) are specific, and it notes the diff use case.

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

  Usage Guidelines5/5

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

  Explicit guidance: when to use (understanding regulatory changes), constraints (dates in YYYY-MM-DD, within tracking range, within up_to_date_as_of), size caveat (small section_id, whole-part can exceed 100KB). Also implies when not to use (whole-part comparisons), though no explicit alternatives named from siblings. Still strong context for selection.

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

• lookup_far_clauseA
  4.7/5.0
  Behavior4/5

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

  The description adds value beyond the annotations by specifying that the tool 'auto-resolves the latest available date' and 'returns parsed clean text with heading, paragraphs, and citations.' While the readOnlyHint and destructiveHint annotations are present, the description enriches the agent's understanding of the exact return format, which is helpful for setting expectations on output. It doesn't contradict the non-mutating nature of the tool, but misses a tiny bit of context on potential rate limits or errors for a truly perfect score.

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

  Conciseness5/5

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

  The description is extremely well-structured and efficient. It uses a clear hierarchy: a one-line summary, followed by a usage example, a brief note on scope, a list of common examples, and a return description. Every sentence teaches the agent something new without being verbose or redundant.

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

  Completeness5/5

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

  For a lookup tool with a rich output schema, the description is complete. It covers what the tool does, how to use it, and what it returns. It correctly assumes the agent doesn't need to know about mutation or side effects given the read-only nature, and it provides just enough context to avoid conflating this with the 12 sibling tools. The presence of the output schema means it doesn't need to over-explain return values, striking the right balance.

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

  Parameters4/5

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

  With 0% schema description coverage, the description bears the full burden of explaining parameters. It does an excellent job with the key ones: 'section_id' is explained with examples, 'chapter' has full semantics described (default '1' for FAR, '2' for DFARS). However, the 'date' parameter is never explicitly mentioned. While the 'auto-resolves the latest available date' line hints at its purpose, the description doesn't name the parameter when explaining this feature, leaving a small gap.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to look up the current text of a FAR or DFARS clause. It provides concrete examples of section identifiers and identifies the tool name in the description, effectively distinguishing it from the many sibling tools like get_cfr_content or search_cfr. It's a specific, action-oriented verb ('look up') tied to a clear resource ('FAR or DFARS clause').

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

  Usage Guidelines5/5

  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 get clean, parsed text of a specific clause) and provides the key usage context: how to switch between FAR and DFARS with the 'chapter' parameter, and that it auto-resolves the latest date. It effectively communicates the main differentiation from siblings like search_cfr (search) or get_cfr_structure (structure), though it doesn't say 'use X instead', it's clear from the examples and the 'Convenience tool' label that this is for quick, direct lookups.

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

• search_cfrA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnly/destructive annotations, it discloses the critical current_only default behavior and the consequence of disabling it (duplicated historical versions), the 10,000-result cap, ordering options, date format expectations, and pagination limits. This is substantial behavioral context with 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.

  Conciseness5/5

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

  The description is organized with a leading summary, a CRITICAL callout, then grouped parameter guidance. Every sentence adds operational value and there is no filler or repetition of schema details.

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

  Completeness5/5

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

  For a 13-parameter, full-text search tool, the description covers the main use case, return shape, dangerous default, pagination, ordering, agency filtering, and date filtering. Since the output schema exists, the description does not need to enumerate return fields, and it is complete enough to guide correct invocation.

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

  Parameters4/5

  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 current_only, order, agency_slugs, last_modified_after/before, per_page, page, and hierarchy filters, but it omits explicit discussion of section and subpart parameters, leaving a small gap.

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

  Purpose5/5

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

  The description opens with a specific verb-resource pairing: 'Full-text search across the Code of Federal Regulations.' It clarifies what is returned (matching sections with excerpts, headings, scores, and hierarchy), distinguishing it from sibling content-retrieval and structure tools.

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

  Usage Guidelines4/5

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

  The description gives actionable context: the current_only warning for in-effect vs historical text, narrowing with hierarchy filters when hitting the 10,000 cap, and date filters for recent regulatory changes. It also points to list_agencies() for finding slugs, but it does not explicitly state when not to use search versus browsing/content tools.

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

• list_agenciesA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral transparency by explaining the summary_only parameter's effect on response size and content, including how child agency references are merged in summary mode. This goes beyond the annotations, providing users with critical knowledge about response behavior and payload size, which is entirely consistent with the read-only annotation.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the main purpose, then explains the parameter and use case. Every sentence earns its place: purpose, output, usage example, and parameter details. It is detailed without being verbose, covering all necessary information in a concise, readable format.

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

  Completeness5/5

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

  Given the tool's simplicity (one optional boolean parameter), the presence of an output schema, and read-only annotations, the description is complete. It states what the tool returns (agency names, slugs, chapter references) and explains the sole parameter's behavior. No critical gaps remain; the output schema covers return structure, and the description covers all un-schema'd semantics.

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

  Parameters5/5

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

  The single parameter summary_only has zero description coverage in the schema, but the tool description thoroughly explains its semantics: 'summary_only (default True) strips the 'children' and most of 'cfr_references' to keep the response compact (~20 KB vs ~100 KB)' and details the merging behavior. This fully compensates for the schema's lack of description, giving the agent precise understanding of the parameter's effect.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'List all agencies with their CFR title and chapter references.' This uses a specific verb (List) and resource (agencies), and specifies the output (agency names, slugs, and chapter references). It uniquely distinguishes itself from sibling tools that focus on sections, content, or corrections, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: 'Useful for finding which chapter corresponds to an agency's FAR supplement.' This gives concrete guidance on when to use the tool. However, it does not explicitly mention when not to use it or reference alternative tools. Since it's a simple listing tool and siblings are clearly different, the guidance is adequate but not exhaustive.

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

• get_cfr_contentA
  5/5.0
  Behavior5/5

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

  The description goes well beyond the readOnlyHint/destructiveHint annotations by detailing return behavior: default parsed clean text, inclusion of tables and editorial_notes, raw_xml toggle, size caveats, and automatic stripping of common prefix mistakes. It also warns about eCFR date lag and potential 404s, providing valuable operational context.

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

  Conciseness5/5

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

  The description is well-structured and dense with practical information. Each block (purpose, usage notes, chapter mapping, common mistakes) earns its place. The use of bullet-like examples and clear warnings makes it easy to parse, despite being longer than average, because it covers complex variable options.

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

  Completeness5/5

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

  The description explains return content, parameter selection, date handling, common input variations, and title-specific context (Title 48 FAR/DFARS). Combined with the output schema and annotations, this gives an agent all necessary context to invoke the tool correctly and avoid pitfalls, making the description effectively self-sufficient.

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

  Parameters5/5

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

  With schema description coverage at 0%, the description compensates thoroughly. Every scoping parameter (section, subpart, part, chapter, appendix) has examples and size guidance. It also explains date behavior, raw_xml semantics, title_number default, and type flexibility (int/string). This is model guidance that the bare schema cannot provide.

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

  Purpose5/5

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

  The description clearly identifies the tool's function: retrieving full text of CFR sections, subparts, parts, or appendixes. It goes beyond mere naming by explaining output types (parsed clean text, raw XML) and specific resource scopes, distinguishing it effectively from sibling tools like search or structure listing.

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

  Usage Guidelines5/5

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

  Provides explicit guidance on when to use the tool ('primary workhorse for reading regulatory text'), how to scope requests ('narrowest scope possible'), what to avoid (chapters >1 MB, using today's date), and concrete examples for each parameter. It also explains date auto-resolution and common input normalization, making it clear how to get successful results.

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

• get_latest_dateA
  5/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true. The description adds critical behavior: eCFR lags behind the Federal Register, and using today's date causes 404 errors. It also discloses that the tool raises ValueError for reserved titles (1-50). This adds value 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.

  Conciseness5/5

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

  The description is concise with three short paragraphs, each earning its place: purpose, critical usage, title specifics. No unnecessary information. Front-loaded with the action.

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

  Completeness5/5

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

  Given the tool's simplicity (one optional parameter, output schema exists), the description covers all essential aspects: purpose, usage pattern, critical timing, error cases, and title guidance. An agent can correctly select and invoke this tool.

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

  Parameters5/5

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

  With 0% schema description coverage, the description fully compensates. It explains the default title 48 (FAR system) and lists common titles with context. It also notes that reserved titles raise errors. This adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get the most recent available date for a CFR title.' It specifies the action (get) and the resource (latest date for CFR title), and distinguishes itself from siblings by positioning it as a preliminary step for other tools.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use the tool: 'Call this first to get the safe date, then pass it to other tools.' It warns about the lag (1-2 business days) and the consequence of not using it (404 errors). It also provides default and common title numbers, guiding usage.

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