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

Annotations already establish a safe read-only, idempotent, closed-world operation, but the description adds substantial behavioral context: it reports where numbers appear, decides nothing about legal status, explains disputed and dispute_reason signals, clarifies applies_from: unknown, and explains metadata_only_units and instruction_only_units. These are meaningful output semantics 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 purpose is front-loaded, but the description is very dense and runs through many caveats in long, clause-heavy sentences. It also repeats the non-legal-advice idea twice, and could be more scannable without losing necessary 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 complex, output-heavy tool with an existing output schema, the description supplies important decision caveats and watch-window scope so an agent can interpret results correctly. It is nearly complete, though sibling-tool routing and any pagination or response-shape limits are not addressed.

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%, and the input schema already documents the sole identifier parameter as a CAS, EC, or CLP Index number with hyphens optional. The description repeats the hyphens allowance and mentions CAS/EC but adds no syntax, format, or validation detail beyond the schema, so the baseline of 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 states a specific verb and resource: 'Find the entries that print a CAS or EC number' in the newest versions and recorded changes. It is clear what the tool retrieves, but it does not explicitly distinguish itself from siblings such as find_provisions or list_disputed.

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 when-to-use guidance, no when-not-to-use guidance, and never names an alternative sibling tool. The hyphens note is parameter-level guidance, not usage routing.

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