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

Goes well beyond the annotations by disclosing input normalization (hyphens and spaces ignored), a transformation behavior (ISBN-10 to ISBN-13 conversion), and the billing model including free failures and the first 25 calls. It also explains why repeated calls cost money, which reconciles with idempotentHint=false in a way raw annotations cannot. It does not describe the shape of the response (validity flag, normalized ISBN), which is the one gap.

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 is front-loaded, followed by usage context, an example, and then commercial terms. Every sentence contributes, though the final sentence packs read-only reassurance, per-call charging, and repeat-call semantics into one dense line.

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 one-parameter, no-output-schema tool, the description covers accepted input forms, normalization, conversion behavior, and cost, which is most of what an agent needs. What it lacks is any indication of what a response contains — e.g. whether an invalid checksum returns false versus an error.

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 describes the single parameter only as "The ISBN," so the description carries real weight: it specifies that both ISBN-10 and ISBN-13 are accepted, that hyphens and spaces are ignored, and supplies a concrete example (0-306-40615-2). That is meaningful clarification beyond the schema's near-empty text.

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: validate an ISBN-10 or ISBN-13 check digit, plus the side benefit of converting valid ISBN-10s to ISBN-13. This clearly separates it from sibling validators like validate_luhn, validate_iban, and bic_validate, which operate on entirely different identifiers.

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?

"Use before cataloguing or ordering books" gives a concrete trigger context, and the tool's domain makes the alternative tools obvious. It stops short of naming an explicit alternative or stating when-not-to-use, so it lands just under a 5.

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