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

Goes well past the annotations, which only say readOnly/idempotent/closed-world. It discloses output encoding per algorithm (hex, integer for crc32, self-describing salted string for password hashes), a hard rate limit of 200 calls/day for argon2id/bcrypt/scrypt, and that no API key or account is needed. The salted self-describing output note usefully warns that password-hash results are non-deterministic across calls.

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 the core verb and the algorithm set, then layers cost/rate-limit/legacy caveats — no filler sentences. It is a single dense run-on, and re-enumerating all thirteen algorithms is partly redundant with the enum, but every other clause carries a distinct decision-relevant fact.

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 only two parameters, no output schema, and annotations covering safety, the description is nearly complete: it explains return encodings and quota behavior that the schema cannot express. The only shortfalls are the undocumented input size ceiling and no pointer to verify_hash for the inverse operation.

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%, so baseline is 3 and the schema already documents the enum and the 200-call limit. The description still adds real meaning beyond the schema by mapping algorithm families to purposes and stating the output shape each returns, though it repeats the salt/rate-limit text verbatim and never mentions the 250,000-character input cap.

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?

"Hash text with MD5, SHA-1, ... BLAKE3" states a specific verb and resource, and the header line plus the algorithm list make it immediately distinguishable from verify_hash, which takes a digest rather than producing one. An agent knows exactly what this produces without opening the schema.

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?

Strong algorithmic selection guidance: sha256/sha3_256/blake2b/blake3 "for integrity checks", md5/sha1 "for systems that still expect them", and password hashes flagged as "meant for test data, since a real password should be hashed where it is used" — an explicit when-not. The gap is sibling routing: verify_hash is never named, so an agent holding a digest and a candidate input is not steered away from calling this tool.

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