Server Quality Checklist

Tool Scores

• execute_toolA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only profile. The description adds context about its role as an indirection layer and the need to use discover_tools first, but does not disclose additional behaviors like error handling or return value forwarding. Given the annotations, a 3 is appropriate.

  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, front-loaded with the core function, followed by usage nuance. Every sentence provides distinct value: purpose, when to use, and comparison with alternatives. No redundancy or fluff.

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

  Completeness3/5

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

  The description adequately covers the primary use case and dependency on discover_tools. However, with no output schema, it does not mention what the tool returns (likely the result of the invoked tool) or potential error conditions. This is a minor gap given the tool's generic nature and the completeness of the schema and annotations.

  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 coverage is 100%, with both parameters (tool and args) described in the schema. The description mentions the arguments object but adds no extra semantic detail beyond what the schema provides. The baseline of 3 applies as the description neither enhances nor conflicts with 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 function: 'Run any tool from the catalog by name with an arguments object.' It distinguishes itself from specialist siblings by being a generic executor, and explicitly contrasts with discover_tools. This is a specific verb + resource with clear differentiation.

  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 gives explicit guidance: 'Use after discover_tools to reach specialist tools that are not advertised in tools/list.' It also notes that advertised tools can be called this way, but calling them directly is simpler, providing a clear alternative. This fully addresses when and why to use the tool.

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

• legal_analysisA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by stating that verify_citations 'flags fabricated or misdescribed authority' and that cite_check reports overruling status, which goes beyond simple annotations. It does not describe auth/rate-limit requirements, but that is not expected given the annotation coverage.

  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 a single, dense sentence that front-loads the main purpose and then efficiently enumerates all modes. While it is not as crisp as a two-sentence summary, it contains no redundant fluff and every clause adds specific information. The semicolon-linked structure makes it scannable.

  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?

  With no output schema and 16 parameters, the description does a good job of covering the tool's key behaviors and parameter groups across modes. It does not mention return formats or credential requirements, but it provides enough context for an agent to select and invoke the tool correctly in most cases. Slight deduction for not addressing the API key parameters or output shape.

  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 81%, so the baseline is 3. The description adds some meaning by mapping modes to parameters (e.g., 'mode=cite_check: case citation'), but it does not explain undocumented parameters like govinfoApiKey, congressApiKey, or courtlistenerToken. It provides moderate value but largely relies on the schema for parameter 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?

  The description starts with a specific verb+resource combination ('Verification and analysis over U.S. law') and then enumerates four distinct modes (verify_citations, cite_check, applicable_law, impact_map), each with a clear scope. This clearly distinguishes it from sibling tools like search_law or get_law_text, which are for retrieval rather than analysis.

  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 explicitly tells users when to use it ('run it on any AI-drafted legal text before relying on it') and explains each mode's purpose, providing clear context for selection. It does not explicitly name alternative tools for when not to use it, but the mode breakdown makes the intended use cases unambiguous.

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

• get_regulation_textA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare read-only/idempotent, so description adds value by explaining date-based behavior and that history/authorising statutes are included. It does not contradict annotations, and the added context goes 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.

  Conciseness5/5

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

  Two efficient sentences that front-load the core purpose, then give essential usage nuance. No redundant or filler content.

  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?

  For a read-only tool with rich schema and no output schema, the description covers the key scenarios (point-in-time, part metadata, history). It doesn't detail return format, but the annotation and schema fill most 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?

  Schema covers 100% of parameters with descriptions. The description adds a use-case hint for the date parameter and clarifies the section vs. part distinction, but does not significantly expand on parameter semantics 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 retrieves CFR section text or part-level metadata from eCFR, using a specific verb and resource. It also mentions included extras (amendment history, authorising statutes) and is distinct from siblings like get_law_text.

  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 explicit guidance: 'use this whenever the question concerns past conduct' due to potential differences from current text. While it doesn't name alternative tools, the when-to-use context is clear, and it distinguishes part-level from section retrieval.

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

• legal_researchA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable behavioral context: it is a multi-step chain, combines multiple source types, and reports every step's outcome even when nothing is found. This goes beyond the structured annotations and helps the agent set expectations.

  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?

  Two sentences, front-loaded with the main behavior and key differentiation. Every clause earns its place: 'multi-step', 'combines sources', 'reports every step's outcome', and the task example. No waste.

  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?

  For a complex 8-parameter tool with no output schema, the description gives the essential behavior ('multi-step chain', 'reports every step's outcome') and directs the user to the task parameter. But it doesn't mention authentication parameters or what the returned research report contains beyond step outcomes. Still, given the schema's rich task descriptions, it's reasonably complete.

  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 coverage is 63% and each parameter has a detailed description, especially 'task' with a full enum explanation. The description highlights 'task' as the primary control but doesn't add meaning for undocumented parameters like the API keys. It provides some orientation but largely relies on 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 states a specific verb ('Run a multi-step legal research chain') and resource ('statute, regulation and case-law lookups'), clearly distinguishing it from single-lookup siblings like search_law or get_law_text. It also explains the unique value of combining sources and reporting all outcomes.

  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?

  It gives clear guidance on using the 'task' parameter to select research shape, with an explicit example for document_review. It implies this tool is for multi-step research but doesn't explicitly state when to prefer it over simpler alternatives, so it loses a point.

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

• regulatory_radarA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful context by revealing the underlying algorithm: reading the Authority note, finding statute amendments, comparing with rule revisions, and flagging changes. It does not, however, disclose output format or external API dependencies, which would strengthen transparency further.

  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 filler: the first states the purpose, the second details the process, and the third gives use cases. It is front-loaded and every sentence earns its place.

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

  Completeness4/5

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

  The description is quite complete for a read-only analysis tool: it covers purpose, method, and use cases, and annotations cover safety semantics. However, since there is no output schema, the description only hints at the result ('flags any statute') without specifying the output format. It could also be clearer about the dependency on external data (e.g., govinfo API), though that is implied by openWorldHint and the API key parameter.

  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 80% (4 of 5 parameters have descriptions), so the baseline is 3. The description provides overall context that helps interpret part/title/citation but adds no parameter-specific detail beyond the schema. The undocumented govinfoApiKey remains unexplained, but with high schema coverage the description need not compensate heavily.

  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 specific purpose: checking whether a CFR part has fallen behind its authorizing statutes. It explains the analytical process (reads Authority note, compares amendment dates, flags changes) and thus distinguishes itself from generic legal research siblings like search_law or get_law_text.

  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?

  It explicitly states when to use it: 'Use for compliance review and for spotting rules that may no longer match their authority.' This provides clear context. However, it does not mention when not to use it or name alternative tools, so it lacks explicit exclusions.

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

• search_decisionsA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover safety (readOnly, openWorld, idempotent, non-destructive). The description adds context about the corpus size (9M+ opinions) and the output contract (citations, cite counts, IDs for get_decision_text), going beyond the structured data without contradiction. It does not discuss rate limits or auth, but the annotations lower the bar.

  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 sentences, each earning its place: scope, accepted inputs, domain restriction tip, and output. It is front-loaded with the verb and resource, contains no fluff, and is appropriately sized for the tool's complexity.

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

  Completeness5/5

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

  Given the detailed schema covering all parameters and annotations covering behavior, the description completes the picture by explaining the query types, domain restriction, and return value relationship to get_decision_text. No output schema exists, so the explicit mention of return values is sufficient. This is complete for an agent to select and invoke the tool.

  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 coverage is 100% with detailed descriptions for all 9 parameters, so the baseline is 3. The description mentions query input types and the domain parameter, adding some semantic nuance beyond the schema, but not significantly. The schema already documents these well.

  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 with a specific verb and resource: 'Search U.S. court decisions (CourtListener, 9M+ opinions across federal and state courts).' It also lists accepted input types and mentions returning IDs for get_decision_text, which distinguishes it from sibling search tools like search_regulations.

  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?

  It gives clear usage context by specifying what inputs work ('case name, reporter citation, docket number, or issue keywords') and how to restrict court level with 'Use domain to restrict the court tier.' However, it does not explicitly name alternatives or exclusion criteria, so it lacks full when-to-use vs. when-not-to-use guidance.

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

• get_decision_textA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond this: it separates majority/concurring/dissent opinions and compacts long opinions by default, requiring full=true for complete text. This helps an agent understand the tool's output behavior and default settings.

  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 two sentences, front-loaded with the primary purpose, and immediately followed by key behavioral notes. Every sentence contributes substance, with 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.

  Completeness4/5

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

  The description covers the core functionality and important defaults, but it omits how the tool behaves when multiple identifier types are provided, and does not explicitly state that at least one identifier is required despite no required params in the schema. This creates a minor gap for an agent constructing a valid request.

  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 100%, so the baseline is 3. The description adds value by clarifying the behavior of 'full' (compacted by default) and the meaning of 'opinionType' (separating opinions), which goes slightly beyond the schema's phrasing. However, it does not provide additional details on identifier precedence.

  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 uses a specific verb ('Retrieve') and resource ('full text of a court decision'), and lists multiple lookup methods (citation, CourtListener id, case name). This clearly distinguishes it from sibling tools like get_law_text and get_regulation_text, which handle statutes and regulations.

  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 clearly establishes this tool is for retrieving court decision text, but it does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to infer the tool's scope, but explicit exclusions are missing.

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

• search_lawA
  4.4/5.0
  Behavior4/5

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

  Annotations already convey read-only, open-world, idempotent, and non-destructive behavior. The description adds value by disclosing the specific return fields (citation, section heading, identifiers) and the role in the get_law_text workflow, which annotation hints do not cover.

  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 two sentences, front-loaded with the core function and free of redundancy. Every sentence contributes either to purpose, accepted inputs, output, or usage guidance.

  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?

  Even with no output schema, the description states what is returned and how it enables get_law_text, covering the main workflow. It omits details like result list limit or error behavior, but those are secondary for a search tool and the overall context (sibling tools) clarifies boundaries.

  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 coverage is 100%, so all four parameters are described in the input schema. The description mostly restates the query parameter's acceptable forms (citation, popular name, free text) without adding new detail, so it neither enhances nor detracts from the schema's baseline.

  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 'Search' and the resource 'federal statutes (U.S. Code)', which distinguishes it from siblings like search_regulations and search_decisions. It also specifies outputs (citation, heading, identifiers) and the intended downstream tool (get_law_text), making purpose unmistakable.

  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?

  Explicitly directs 'Use this first when you need a statutory basis', providing when-to-use guidance. It also describes the relationship to get_law_text by returning the identifiers that tool needs, effectively mapping the workflow and implying alternatives (e.g., get_law_text after search).

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

• search_regulationsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar for transparency is lower. The description adds valuable context by noting the dual behavior of searching CFR and also surfacing recent Federal Register documents affecting the matched part.

  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 two sentences, front-loaded with the core function and usage context. Every sentence serves a purpose without wasted words, making it highly concise and well-structured.

  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 has 5 parameters with full schema coverage and no output schema, the description provides sufficient context for selecting and invoking the tool. It explains the main capabilities and usage domains, though it could explicitly describe the return structure (e.g., a list of CFR sections plus FR documents) to be fully complete.

  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 100%, so the baseline is 3. The description does not add meaning beyond what the parameter descriptions already provide (e.g., query accepts citation or keyword, includeFederalRegister controls FR results). It aligns with the schema but does not compensate beyond it.

  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 federal regulations (CFR) by citation or keyword and surfaces related Federal Register rulemaking. It uses a specific verb and resource, and explicitly differentiates from search_law by noting statutes live there.

  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 use cases: agency requirements, permits, thresholds, and compliance obligations. It also gives an exclusion and alternative: statutes live in search_law. This directly guides the agent on when to choose this tool over a sibling.

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

• discover_toolsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable context about behavior beyond those: it returns matches with parameters, enabling invocation via execute_tool, and it surfaces 'specialist tools that are not advertised in tools/list.' This clarifies the operational scope without contradicting 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 two sentences, front-loaded with the core action, and includes all essential information (what it searches, what it returns, and when to use it). No wasted words.

  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 meta-tool that searches a catalog, the description fully covers the agent's needs: it states what the tool does, what it returns ('each match with its parameters'), and when to invoke it. With no output schema, the return value description is sufficient for the agent to decide to use execute_tool afterward.

  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 100%, and parameter descriptions in the schema already explain query, showSchema, and includeExposed. The tool description adds no additional parameter-level detail beyond what the schema provides, so it meets the baseline but does not exceed it.

  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: 'Search the full tool catalog, including specialist tools that are not advertised in tools/list.' It uses a specific verb ('Search') and resource ('tool catalog'), and distinguishes itself from sibling tools by highlighting its role as a discovery mechanism for unlisted tools, which is unique among the provided siblings.

  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 gives explicit guidance: 'Call this when none of the listed tools fits.' This directly tells the agent when to use it, and implies that it is the fallback for unlisted capabilities. It also references tools/list and execute_tool, providing clear context for workflow integration.

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

• get_law_textA
  4.6/5.0
  Behavior5/5

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

  Annotations already indicate a safe read-only, idempotent operation. The description adds valuable behavioral context by disclosing that the tool reports edition and currency to prevent mistaken reliance on superseded text, and by explaining the default elision behavior when full=false. No contradiction 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.

  Conciseness5/5

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

  Three well-structured sentences, each conveying distinct information: purpose, input modes, and behavioral caveats. No filler or redundancy.

  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?

  With 5 parameters and no output schema, the description covers input modes, the full flag, and the edition/currency reporting, giving an agent enough to invoke correctly. It does not describe the exact response shape, but for a retrieval tool with strong annotations, this is sufficient.

  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?

  The schema provides descriptions for all five parameters (100% coverage), so the baseline is 3. The description adds the relationship that a citation is an alternative to title+section, clarifying parameter usage beyond the individual schema descriptions. This justifies a small increase.

  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 the operative text of a U.S. Code section, using a specific verb and resource. It distinguishes itself from sibling tools like get_regulation_text and get_decision_text by explicitly scoping to U.S. Code.

  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 explains the two input modes (citation string or title+section) and instructs when to set full=true. It does not explicitly state when not to use this tool (e.g., for regulations or decisions), but the sibling names and the specificity of the description make this implicit.

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