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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the paid-call price and x402/Solana authentication model, an alternate HTTPS endpoint, the server-side libargon2 dependency that limits Argon2 support, and a privacy guarantee that passwords are never echoed or stored. None of this appears in structured fields, and nothing contradicts the annotations — hashing is a pure computation, so readOnlyHint=true is consistent.

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 three modes are front-loaded, followed by algorithm coverage, then cost and transport details. The algorithm enumerations are dense lists but each entry carries distinct information; a few items (e.g. repeating the input formats in both verify and identify) could be trimmed.

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?

There is no output schema, so the description must cover return values and only partially does: identify's output (algorithm, parameters, OWASP verdict, needsRehash) is described, but what hash and verify return — the hash string and the boolean match result — is left implicit. For a 9-parameter tool with zero required fields, the missing mode-parameter contracts are a real gap.

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 67%, and the description supplements the partially documented schema by mapping each algorithm enum value to its output format (bcrypt, Django PBKDF2, Linux shadow crypt, APR1/htpasswd) and noting the argon2 availability caveat. It does not clarify the mode-to-parameter relationship (that password/hash are conditionally required depending on mode), which matters because no parameter is marked required.

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 names three concrete operations (hash, verify, identify) and enumerates the exact algorithms each supports, which is far more specific than the name alone. It does not explicitly contrast itself with near-siblings such as password_strength or hash_encode, so the agent must infer the boundary even though the algorithm list makes it fairly obvious.

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?

Each mode is given an explicit use case: hash for seeding users, migrating auth systems, writing htpasswd files and auditing leaked formats; verify for checking a password against a stored hash; identify for assessing a hash against the OWASP cheat sheet with needsRehash. It stops short of naming alternatives (e.g. password_strength for choosing a new password) or stating when not to use it.

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