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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is met; the description goes further by disclosing the finding taxonomy (in force, repealed, not found, not verified), the corpus last-checked date, and the important caveat that 'not found' is not proof of error.

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?

Front-loaded with purpose and the action trigger, and the trailing sentences each add real information rather than filler. It is slightly dense and reads as one long block, which costs a point on structure.

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 takes responsibility for the return value — a tally plus one finding per citation across four categories. Combined with the parameter and caveat guidance, an agent has everything needed to call and interpret 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 coverage is 0%, so the description must carry the load — it does define both parameters: text = the document and default_jur = the assumed jurisdiction with a concrete example ('ru'). It lacks any statement of accepted format or code set for default_jur, which keeps it from a 5.

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 — 'Check every legal citation in a text' — with explicit scope ('every ... in one call'). It is clearly distinguishable from siblings like lexatlas_verify and lexatlas_search, which are named for other purposes.

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?

Gives an explicit when: 'Call it on a draft (contract, memo, AI answer) before it is used,' plus a concrete alternative path — confirm 'not found' cases with lexatlas_search before calling them wrong. It also advises sending long documents in parts.

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