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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety needs no restatement; the description instead adds the substantive scope limit that only format is validated, not registration status. What is still undisclosed is the result shape (a boolean pass/fail versus a list of failed rules) for a tool with no output schema.

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?

Two sentences with no filler: the validation rule comes first and the scope caveat second. Both are front-loaded information an agent needs before calling.

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 input side and the boundary of the check are fully covered, and annotations carry the safety profile. However, with no output schema, the description leaves the agent guessing what an unsuccessful check looks like (false, an error, or a reason string), which matters for a validation tool whose entire value is its verdict.

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?

Only one parameter and schema coverage is 100%, with the schema already stating 'The LEI, 20 characters.' The description's mention of MOD 97-10 adds interpretive value but is a restatement of the length constraint rather than new parameter guidance, so the baseline 3 applies.

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 that a Legal Entity Identifier (LEI, ISO 17442) is well formed') and pins down the exact rule applied (20 characters, MOD 97-10 check digits). An agent can immediately tell this apart from the identifier checkers in the sibling set (cusip_checker, isin_checker, iban_checker) because the identifier standard is named explicitly.

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?

Provides an explicit when-not boundary: 'Does not confirm the LEI is registered; GLEIF's search does,' and names the alternative that handles that case. This routes the agent away from a false expectation that a pass means the entity exists.

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