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

With no annotations, the description carries the behavioral disclosure burden and does a good job: it reveals the legal rule applied, declares that treatises/law-review articles/practitioner opinions count as non-authority, and states it does not weigh. It could add whether the operation is read-only or how results are returned, but it is substantively transparent.

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 purpose statement is front-loaded, and each sentence contributes: legal rule, non-authority examples, non-weighing limitation, and parameter meanings. It is slightly more verbose than necessary, but no sentence is filler.

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

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

For a legal-domain classification tool with no annotations, the description conveys the key external context, parameter semantics, and an important limitation. The output schema covers return values, so that gap is acceptable. It does not mention edge cases or related sibling tools, which keeps it from a 5.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: the Args section defines text as 'The draft to analyse' and explains tax_year as checking each authority against that year. This is sufficient for both parameters, though it does not give format constraints or examples.

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

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

The description opens with a specific verb and resource: 'Classify a draft's citations as authority, or not, for penalty purposes.' It also narrows the scope to the substantial-authority standard. However, it does not explicitly differentiate the tool from siblings like verify_citations or resolve_citation; it only says it does not weigh, which is more behavioral than a sibling comparison.

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 states when it applies ('for penalty purposes', citing Treas. Reg. § 1.6662-4(d)(3)(iii)) and gives a clear exclusion: it classifies, it does not weigh. It does not explicitly point to an alternative tool for weighing or verification, so it stops short of full when/alternative guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the tool both retrieves a decision and performs a textual check, and it warns of the specific failure mode it catches (nearly right quotations). However, it does not describe the result format, matching behavior, or edge cases such as partial matches, though an output schema exists.

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 front-loaded with the core purpose and then provides context and parameter guidance. It is slightly wordy in the middle paragraph, but the rhetorical explanation about citations and quotations earns its place by preventing incorrect usage. Overall it is compact and no sentences are wasted.

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 two-parameter lookup/verification tool, the description is nearly complete. It explains when to use the tool, what each parameter means, and why the check matters. The main omission is clarifying that the quote parameter is optional and that calling with only a citation simply looks up the case; the schema shows the default but the description does not state this behavior.

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

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

Schema description coverage is 0%, so the description must explain both parameters, and it does so well. For citation, it gives a concrete example and identifies it as the case reference. For quote, it explains what to pass ('the words only'), how much is needed ('enough of them to be distinctive'), and warns that 'a handful is not enough to be sure of.' This meaningfully exceeds the bare 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 action: look up a court decision and check whether a proposed quotation appears in it. It clearly distinguishes this from siblings like resolve_citation (which presumably resolves a citation) and verify_citations (which likely verifies citation accuracy) by framing the tool as a quotation-integrity checker.

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

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

The description gives explicit when-to-use guidance: 'Use this before you attribute language to a case.' It also explains why the check is necessary: a resolvable citation does not guarantee the quoted words are in the opinion. It does not name alternative tools or state when not to use them, but the usage context is concrete and actionable.

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?

With no annotations, the description carries the behavioral burden. It clearly implies a read-only operation via 'Show' and transparently documents the default behavior for to_date ('current law if omitted'). It does not discuss edge cases or validation, but the output schema covers return-value details.

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

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

The description is compact and well-structured: a one-sentence purpose statement followed by a tight Args block. Every line earns its place, and the most important info is front-loaded.

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

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

All parameters are described with formats and defaults, the operation is clear, and the presence of an output schema covers return-value expectations. For a simple three-parameter comparison tool, nothing essential is missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does. It explains all three parameters with formats ('YYYY-MM-DD'), a concrete citation example ('§ 163(j)'), and the meaningful default for to_date. This adds substantial value over the bare 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: 'Show how a provision changed between two dates.' This clearly distinguishes it from siblings like get_irc_provision (current law) and search_tax_law (search), since the focus is temporal comparison of versions.

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

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

The intended use case is implied by the description, but it never explicitly says when to prefer this tool over alternatives or when not to use it. The sibling list shows nearby tools, but the description itself does not provide routing guidance.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action and result (find definitions and scope) but does not disclose whether the operation is read-only, what happens if no definition is found, any authentication requirements, or the format of the output. This is a significant gap for a tool with no annotation support.

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 extremely concise, with the purpose stated in one sentence and the Args section providing minimal but sufficient parameter details. There is no fluff or redundant information; every word 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?

The tool is simple with only two parameters, and an output schema exists, so the description covers the core purpose and parameter meanings. However, it lacks usage guidance and behavioral details (e.g., read-only nature, error behavior), making it slightly incomplete for a tool with no annotations to fall back on.

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 description explains both parameters: 'term' with an example ('gross income') and 'limit' with a clear meaning ('Maximum number of definitions to return'). The schema only provides titles and a default, so the description adds meaningful semantic value that helps an agent understand how to fill in the arguments correctly.

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 action ('Find') and the resource ('where a term is defined, and what scope the definition has'), making it specific and distinct from sibling tools like search_tax_law, which imply broader searching. An agent can immediately understand what this tool does without ambiguity.

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 does not provide any guidance on when to use this tool versus alternatives such as search_tax_law or resolve_citation. It lacks explicit context about when this tool is appropriate and when it is not, leaving usage to inference only.

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?

With no annotations, the description is the only safety signal. 'List' clearly signals a read-only operation, and the incoming/outgoing contrast explains the tool's core behavior. It does not address invalid citations, access restrictions, or error behavior, but for a simple query tool 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.

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

The definition is one short purposeful sentence followed by two concise parameter entries. It front-loads the primary behavior and contains no filler, repetition, or irrelevant detail.

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 simple two-parameter tool with an output schema, the description covers both parameters and the core lookup semantics well. It is complete enough for an agent to select and invoke the tool correctly, though naming sibling alternatives would improve context further.

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

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

Schema description coverage is 0%, so the description fully compensates: it explains that citation is the provision to inspect and gives a concrete format example ('§ 1411'), and it enumerates the valid direction values ('outgoing', 'incoming', 'both'). This adds meaning well beyond the bare 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 first sentence states the exact operation ('List') and the object (what a provision cites and what cites it), making the tool's function unambiguous. It is distinct from siblings like resolve_citation or verify_citations because it targets the citation-graph relationship, not resolution or validation.

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 no explicit when-to-use guidance or named alternatives. An agent must infer from the wording that this is for bidirectional cross-reference lookup, but the description does not state when to prefer it over sibling tools like verify_citations or search_tax_law.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the tool returns official text, supports historical reads via as_of, includes subdivisions by default, and can truncate output with max_chars. These are meaningful behavioral details beyond the bare operation.

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

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

The description is compact and well-structured: a one-line purpose followed by a bullet-style argument list. Every sentence adds value, and the most important practical warning about as_of is included without unnecessary verbosity.

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?

All parameters are covered with clear semantics, the purpose is precise, and the output schema exists to describe return values. The description is complete enough for an agent to call the tool correctly, including handling of the important as_of edge case.

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

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

Schema coverage is 0%, so the description must fully explain the parameters, and it does. It gives citation format examples, defines include_children, explains max_chars truncation, and provides crucial as_of usage context. This is exemplary compensation for a schema with no descriptions.

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

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

The description states a specific verb and resource: 'Get the official text of an Internal Revenue Code provision.' This clearly distinguishes it from siblings like get_treasury_reg and search_tax_law, which target different legal materials or operations.

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 context for when the tool is appropriate, especially the as_of guidance that tax questions usually concern past years and current law is often wrong. It does not explicitly contrast this tool with alternatives, but the provided context is strong enough for an agent to select it appropriately.

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?

With no annotations, the description carries the burden and does disclose truncation (max_chars) and recursive child inclusion. It does not state what happens on invalid citations, whether the text is current/authoritative in a dynamic sense, or any other side effects; moderate transparency.

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?

A one-line purpose followed by a terse Args block; every sentence adds information. No filler or repetition of the schema titles.

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 simple text-retrieval tool with an output schema, the description covers function and all parameters well. It is slightly incomplete in not relating itself to sibling citation tools or specifying behavior around max_chars truncation marks, but these are minor.

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

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

Schema coverage is 0%, so the description must explain all params. It gives concrete citation examples, explains include_children as recursive paragraph text, and defines max_chars as truncation length. This compensates well, though it doesn't detail default behavior or edge cases like an invalid citation.

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?

Clearly states the tool retrieves the official text of a Treasury Regulation, with citation examples that make the resource unambiguous. It doesn't explicitly distinguish itself from siblings such as get_irc_provision, but the resource type ('Treasury Regulation') is specific enough.

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 intended use is implied: call this when you need the official text of a Treasury Regulation. However, there is no explicit when-not-to-use guidance or mention of alternatives like resolve_citation or get_irc_provision.

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?

With no annotations, the description must carry the full behavioral disclosure. It only states it lists subdivisions, implying a read-only operation, but it does not mention side effects, error conditions, or any limitations. The agent is left to infer that it's safe and non-destructive, but no explicit disclosure is given.

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 concise: two sentences plus an Args block. It front-loads the purpose and gives an example, with no wasted words. Well-structured for quick parsing.

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 simple single-parameter tool with an output schema, the description covers the essential purpose and parameter. It lacks explicit guidance on when to use it versus siblings, but given the simplicity, it's adequate. The output schema likely handles return value details.

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

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

Schema coverage is 0%, so the description compensates well by explaining the citation parameter with a concrete example ('§ 163'). This adds meaningful guidance beyond the schema's bare 'Citation' field, clarifying the expected format.

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 verb 'List' and the resource 'a provision's subdivisions', which is specific and distinguishes it from fetching a full provision. However, it does not explicitly differentiate from sibling tools like get_irc_provision, so it's clear but not maximally distinct.

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 phrase 'so you can fetch the one you need' implies the tool is a precursor to fetching a specific subdivision, but it does not explicitly state when to use it versus alternatives or mention exclusions. Usage guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does explain the traversal behavior ('walks outward, nearest first') and the meaning of depth ('How many hops to follow') and warns about the transitive closure ('The transitive closure of the Code is the Code'), which hints at potential depth explosion. However, it does not mention the return format (citations vs. full text), pagination, or any edge cases like cycles. It is transparent about the core algorithm but lacks details on output and side effects.

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

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

The description is efficient: it states the purpose first, then the graph context, then the traversal behavior, and then the arguments. Every sentence adds value. It is front-loaded with the primary action and uses minimal words to convey the key concepts. 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?

The tool is moderately complex (graph traversal), but the description covers the purpose, parameters, and traversal order. An output schema exists (as signaled), so the return format may be documented there. The description does not mention edge cases like cycles or what happens if the citation is invalid, but for a tool with a clear use case and an output schema, the coverage is adequate. It is missing a note on what the output looks like, but the output schema likely covers that.

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

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

The schema has zero parameter descriptions (coverage 0%), so the description must fully explain each parameter. It does so clearly: citation (starting provision, with an example), depth (hops), and limit (max provisions). It also explains the relationship between depth and the graph. This fully compensates for the schema gap.

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

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

The description opens with a clear, specific verb and resource: 'List everything you must read to understand a provision.' It explains the graph metaphor and the outward traversal, and the example (§ 163(j)) makes the purpose concrete. This is distinct from siblings like get_cross_references, which likely returns direct references, while this tool computes the transitive closure. The purpose is unambiguous.

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

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

The description provides a clear context for use: 'Before asserting what § 163(j)(1) means, read what it points at.' This implies the tool is for gathering reading material before making assertions. However, it does not explicitly contrast with alternatives like get_cross_references or get_irc_provision, nor does it state when NOT to use it. The usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It does disclose the core read-only behavior: parsing a citation and checking existence. However, it does not mention behavior on malformed citations, whether existence is checked against current law, or exactly what 'exists' means for a provision. The basic predicate is clear, but edge cases are not addressed.

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 short, front-loaded with the main purpose, and contains no filler. The Args section cleanly documents the single parameter with an example. Every sentence contributes value.

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 one-parameter validation tool, the description is largely complete: the parameter is explained with an example, the behavior is clear, and an output schema exists so the return shape need not be described. It could be more complete with error expectations, but nothing essential for basic invocation is missing.

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

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

The input schema only says 'citation' is a string with 0% schema description coverage. The description compensates by labeling the argument as 'The citation to check' and providing a concrete format example, '§ 162(z)'. This gives an agent useful semantic information beyond the schema, though it does not fully enumerate accepted citation formats.

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 operation: 'Parse a citation and say whether the provision it names actually exists.' This names a specific verb, resource, and outcome, making the tool's core purpose understandable. It does not explicitly differentiate itself from sibling tools like verify_citations, so it stops short of a 5.

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

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

The description provides no guidance about when to use this tool instead of alternatives such as get_irc_provision, verify_citations, or check_case. There are no conditions, exclusions, or routing hints; only a parameter example is given.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool searches the text of the Code and regulations terms and that a limit can be applied, but it does not describe result ordering, whether matches are snippets or full provisions, error behavior for invalid source values, or any other side effects. This is thinner than expected for an unannotated tool.

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

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

The description is compact and front-loaded with the core purpose, followed immediately by a concise Args block. Every line adds useful information, and there is no redundant restatement of the schema or irrelevant detail.

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 simple search tool with an output schema present alert and all parameters documented in the description, the core invocation guidance is complete. The main gaps are behavioral detail—such as result ranking or error handling—and explicit alternative routing, but those are partially covered by the output schema and the tool's obvious search intent.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining all three parameters: query as words or a phrase with an example, source as 'irc', 'reg', or 'all', and limit as maximum number of results. This adds meaning that the bare input schema does not provide, especially for the source parameter, which has no enum in the schema.

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

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

The description states a specific verb ('Search') and a clearly bounded resource ('the text of the Code and the regulations'). This distinguishes it from sibling tools like get_irc_provision, get_treasury_reg, and resolve_citation, which are for targeted retrieval or citation resolution rather than free-form full-text search. The purpose is immediately recognizable.

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 implies when to use this tool: when you need to find text in the Code or regulations by keyword or phrase. However, it does not explicitly state when to prefer this tool over alternatives such as resolve_citation or find_definition, and it gives no 'when not to use' guidance. The usage context is inferable but not stated.

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?

With no annotations, the description carries the behavioral burden. It discloses that the tool checks all citations and quotations, reports error-severity findings, and can flag provisions that did not govern a given tax year. There is slight ambiguity about whether 'fix' implies mutation, but the read-only 'check' framing is strong.

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 purpose is front-loaded and each sentence earns its place. The Args section is compact, and the guidance about tax_year is useful rather than redundant.

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 two-parameter tool with an output schema, this description is largely complete. It covers purpose, usage timing, and both parameters. The phrase 'official sources' is somewhat vague, and more detail about the return format would help, but the output schema mitigates that gap.

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

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

Schema description coverage is 0%, so the description must define the parameters, and it does. text is described as 'Markdown or plain text', and tax_year is given meaningful semantics: flag non-governing provisions and pass it whenever a specific year is in question.

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?

Describes a specific action ('Check every citation and quotation') against a specific resource ('official sources'), which clearly distinguishes it from sibling search, retrieval, and resolution tools. The purpose is immediately obvious and actionable.

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

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

States when to use it ('on your own draft before you finish') and gives condition-dependent guidance for tax_year. It does not explicitly name alternatives or exclusions, but the usage context is clear enough.

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