US federal rules taking effect

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds meaningful behavioral detail by enumerating exactly what the tool returns, including the verbatim Federal Register API quote, which goes beyond the annotations. No contradiction exists between the description and 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?

Two sentences with zero filler. The first sentence front-loads the purpose and full return contents; the second clarifies the identifier format and its cross-tool relevance. Every clause earns its place.

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

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

For a single-parameter, read-only tool with an output schema and safety annotations, the description is nearly complete: it covers input format, return fields, and source. The only minor gap is not stating behavior for a non-existent or malformed document number, but this is not critical given the simple operation and existing schema.

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

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

The schema already describes document_number with an example, so baseline is 3. The description adds value by explaining the format ('look like "2026-13685"') and how the parameter is obtained ('appear in every other tool's results'), which helps agents understand the parameter's provenance and expected format beyond the schema.

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

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

The description states a specific verb and resource: 'Get one rule by Federal Register document number.' It enumerates the exact fields returned (title, agency, effective date, DATES paragraph, CFR parts, publication date, link, verbatim quote), leaving no doubt about scope. This clearly distinguishes it from sibling list tools, which return multiple rules, and verify_quote, which has a different purpose.

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 notes that 'Document numbers ... appear in every other tool's results,' which clearly implies the intended workflow: obtain a document number from another tool, then call get_rule for the full record. It provides clear context but does not explicitly name alternatives or state when-not-to-use it, so it falls just short of a 5.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds useful context about the returned data (counts, earliest/latest dates, exact naming convention) and implies no side effects. This adds value beyond the annotations without contradicting them.

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

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

The description is three short sentences, front-loads the tool's purpose with a question-answer format, and then gives targeted usage guidance. No filler or redundancy.

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

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

Given the presence of an output schema and descriptive annotations, the description sufficiently covers purpose, output content, and when to use it relative to a sibling. Nothing essential is missing for an agent to invoke it correctly.

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

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

The schema fully describes the single optional parameter as a case-insensitive substring filter, achieving 100% coverage. The description does not add any further parameter-specific meaning, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool lists agencies with upcoming rules, returning counts and dates, and explicitly contrasts it with the sibling list_rules_taking_effect by emphasizing exact agency naming. This is a precise verb-resource pair with scope and differentiation.

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

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

It explicitly instructs when to call this tool: before filtering with list_rules_taking_effect, to obtain exact agency names. It names the alternative and provides a concrete use case (e.g., 'FAA' vs 'Federal Aviation Administration').

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

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

The readOnlyHint and destructiveHint already signal a safe read, and the description adds meaningful behavioral detail: it returns only published final rules, sorts by soonest effective date, includes a verbatim quote, and matches the part whole so "40 CFR 5" never pulls in 40 CFR 52-related rules. This goes beyond what annotations alone provide.

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

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

Three tight sentences move from user intent to input format to output behavior and edge-case matching. No filler or repetition of schema details; every sentence earns its place.

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

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

For a read-only listing tool with an output schema, the description covers what an agent needs to invoke it correctly: how to ask the question, what input is required, what ordering and content to expect, and how matching is scoped. No significant gap remains.

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

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

The schema already documents all three parameters at 100% coverage, and the description reinforces cfr_part with examples, the refusal rule for bare numbers, and the exact-match semantics. It adds context beyond the schema without needing to restate from/limit.

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 action and resource: get already-published final rules that amend a given CFR part. It also states the output ordering, the DATES paragraph, and the whole-part matching behavior, making the tool's scope unmistakable even before considering siblings.

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

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

The description gives concrete input examples ("49 CFR 192"), states the sort order, and warns that bare part numbers are refused. It does not explicitly contrast with list_rules_taking_effect or other siblings, but the amendment-focused wording makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail beyond annotations: it restricts to already-published final rules (not proposed), orders by effective date soonest first, and specifies returned fields including a verbatim quote. No auth or rate-limit details are added, but the read-only nature is already annotated.

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

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

The description is compact and front-loaded with the essential scope ('Lists already-published US federal final rules'), then gives ordering, optional filter, output details, and closes with a usage pointer. Every sentence earns its place; 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?

With the output schema present, the description covers the key behavioral aspects an agent needs: scope (final rules), date range semantics, ordering, optional agency filter, and the specific fields returned. It also warns against misuse (not topic search). This is complete for a read-only list tool with well-documented parameters.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters including formats, defaults, and matching behavior. The description adds minimal parameter information: it mentions the date range and optional agency filter, but these are already clear from the schema. Thus the baseline 3 is appropriate.

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

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

Description states a specific verb and resource: lists already-published US federal final rules by effective date range. It also explicitly distinguishes itself from topic search and frames the compliance-calendar use case, making it easy to differentiate from siblings like list_rules_amending_cfr_part.

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

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

The description includes an explicit use case ('what takes effect in Q4') and an exclusion ('not for searching the Federal Register by topic'), but does not name a specific alternative tool for topic search or CFR-part queries. The schema does point to list_agencies for agency names, but the main description lacks the explicit sibling comparison that would earn a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: the three possible verification outcomes and that, when the claim differs, it reports 'what the record says instead.' This is genuinely useful for an agent deciding whether the tool answers its question.

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 three sentences, front-loaded with the core action and examples of the claim types. The final sentence about effective dates is motivational context rather than strictly necessary for invoking the tool, but it does not waste much space or obscure the main guidance.

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

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

For a tool with only 3 parameters, 2 required, annotations covering safety, and an output schema present, the description plus schema is fully sufficient. It explains the tool's purpose, the kind of claims it handles, and the types of answers it returns, with no critical gap for an agent to select and call it correctly.

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

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

Schema description coverage is 100%, and the schema already documents each parameter with examples, including the optional `field` behavior. The description reinforces these ideas but does not add substantial meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Check a claim about a final rule ... against the Federal Register record.' It also explains the result taxonomy ('matches a stored value, appears only in the verbatim quote, or differs'), which clearly distinguishes this verification tool from the retrieval/list sibling tools.

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

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

The description gives clear usage context: use this when you have a claim about a rule's effective date, agency, or CFR parts and you want to verify it 'instead of trusting it.' It does not explicitly name alternatives or state when not to use it, but sibling tools are clearly different in purpose (retrieval vs. verification), so no exclusion is truly needed.

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