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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses substantial behavior: it returns current in-force wording, strips trailing paragraphs from citations, covers the entire Title 26 scope, and notes 'Keyless' access. These details meaningfully inform an agent about expectations and limitations, going well beyond what annotations 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?

The description is long but every sentence delivers unique value: core purpose, example queries, citation forgiveness, part-identification rule, coverage scope, and a concrete example call. It is front-loaded with the action and logically organized, with no fluff. The length is justified by the tool's complexity.

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 no output schema, the description appropriately explains return behavior ('Returns the exact regulatory wording', 'Pass a whole part ... to get a (large) section list'). It also covers scope, input flexibility, and usage examples. The tool's complexity is fully handled; an agent would know exactly what to expect and how to invoke it.

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

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

Even though the schema already describes 'citation' with 100% coverage, the description adds crucial semantics: it explains the dotted format, the rule for identifying the part ('the number BEFORE the first dot'), gives multiple examples, and clarifies that a bare part returns a list. This is far more than the schema provides and directly helps the agent construct valid inputs.

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: 'Get the full text of one Treasury Regulation / IRS regulation ... by its citation. Returns the exact regulatory wording currently in force.' It provides multiple example natural-language queries ('what does Treas. Reg. 1.170A say') that make the purpose unmistakable. Though it doesn't explicitly distinguish from sibling tax_search, the scope and behavior are so clearly defined that there's no 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 gives clear context for when to use the tool by listing query phrasings it answers and by explaining that a bare part returns a section list. However, it never mentions when NOT to use it or points to an alternative like tax_search for searching by keyword or topic. This is a clear context with no exclusions, matching a 4.

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