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

With readOnlyHint/openWorldHint already provided, the description adds substantial non-obvious behavior: it searches for a single substitution or transposition, reports ambiguous fixes, refuses IBANs with unknown country-code lengths, and clarifies that a passing checksum is not proof of existence. None of this contradicts the annotations.

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 core behavior is front-loaded, and the detailed error-handling and ambiguity reporting are essential given the tool's complexity. The 'WHY DELEGATE THIS' and ownership sentences are purposeful but the ownership/URL line is the closest thing to non-essential, preventing a 5.

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?

Despite lacking an output schema, the description conveys what the agent should expect back ('which character to fix', ambiguity reports) and covers refusal behavior and format-selection constraints. For a tool with six formats and modular arithmetic, this is enough for correct selection and invocation.

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?

The schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaningful extra semantics for 'format' by explaining that a bare digit string is ambiguous, that the format must be named, and that IBAN length handling is registry-based. It does not add much beyond the schema for 'input', hence 4 rather than 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?

The description opens with a specific action ('Checks the check digit') and names the exact resource and formats (IBAN, ISBN-10/13, EAN-13, UPC-A, Luhn). It also distinguishes the tool by stating it localises a fixable error rather than only reporting failure, so an agent can tell it apart from any generic validator.

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 'WHY DELEGATE THIS' section makes the intended use case explicit: offload checksum arithmetic and error-localisation when a model would otherwise 'fumble silently' or pattern-match a plausible answer. It does not name sibling alternatives, and the sibling list contains no overlapping tools, but it stops short of enumerating when-not-to-use conditions.

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