pentest_ctf_hash_crack

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

With no annotations at all, the description carries the full disclosure burden, and "(offline)" plus "built-in + provided wordlist" are genuine behavioral facts: no external hash-lookup service is contacted and a default dictionary exists. However it omits material behavior for a cracker — whether the algorithm is auto-detected from the hash length, what happens on a miss (empty result vs error), and whether an oversized wordlist or input causes a timeout or truncation.

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?

A single well-formed sentence with the algorithms and the wordlist mechanism front-loaded and no filler. It is arguably too terse rather than too long; nothing in it is wasted.

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 tool with no annotations, no output schema, and zero schema parameter descriptions, the definition should cover input format and the shape of a success or failure result, and it covers neither. An agent can guess the intent but not how to format `value` or interpret a returned empty value.

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 0% and neither parameter has a description, but the phrase "built-in + provided wordlist" usefully explains that `wordlist` is optional and falls back to a bundled list, matching its nullable default. The required `value` parameter gets no explanation — its expected form (raw hex, prefixed, salted) is left entirely to inference.

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 pairs a specific verb ("Crack") with a concrete resource (MD5/SHA1/SHA256/SHA512 hashes) and names the mechanism (wordlist attack). It implicitly separates itself from pentest_ctf_hash_identify, since this tool recovers plaintext rather than classifying an unknown hash, but it never says so 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?

There is no when-to-use or when-not-to-use guidance, and the closest sibling (pentest_ctf_hash_identify) is not referenced even though identifying the algorithm is the natural prerequisite to cracking. The parenthetical "(offline)" hints at the execution model but does not tell the agent when this tool is the right choice over other CTF tools.

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