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

Annotations only cover the safety profile (read-only, idempotent, non-destructive, open-world). The description adds substantial non-annotation context: a 2020-11-06 snapshot with data_as_of and a staleness warning, deliberate exclusion of case-law annotations, later_acts returned as an unmerged labelled overlay, sessions_checked naming covered sessions, and keyless access.

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?

Purpose and accepted citation formats are front-loaded, and the return-shape details follow in a logical order. It is dense and somewhat long (the all-caps sourcing block and the lengthy later_acts explanation could be tightened), but each sentence carries information an agent needs.

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 carries the full return-value burden and does so: catchline, operative text, History line, legislative notes, later_acts, sessions_checked, and data_as_of. Nothing needed to call or interpret the result 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 100% for the single citation parameter, so the baseline is 3. The description earns above baseline by enumerating accepted natural forms ('5-10-101', 'Ark. Code Ann. 5-10-101', 'ACA § 5-10-101'), which tells the agent normalization is handled rather than requiring an exact canonical string.

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?

States a specific verb and resource — 'Get the TEXT of a section of the Arkansas Code (Ark. Code Ann.) by citation' — and reinforces it with concrete citations like "5-10-101". The citation-input framing cleanly separates it from the sibling ar_search, which retrieves by query rather than by exact cite.

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?

Explicitly names the use cases: '"what does ACA 5-10-101 say"' and checking an Arkansas statute for post-2020 amendments. It gives clear context but never names or excludes an alternative (e.g., ar_search), so there is no explicit when-not guidance.

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