cyberchef_hash_statistics

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses valuable operational constraints: it reads structure only, never cracks hashes, and performs no network access. These are exactly the behavioral traits that affect whether an agent should select this over hash_crack or other network-capable tools, and they align with 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?

Four sentences, each doing distinct work: output scope, sibling differentiation, input format, and safety/network behavior. The most load-bearing claim (set-level analysis) is front-loaded and there is no filler or tautology.

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 two-parameter tool with complete schema descriptions and strong annotations, the description is sufficient even without an output schema: it names every output dimension the agent should expect (formats/proportions, shared accounts, locked/passwordless status, weakest link). It also covers the input contract clearly and states the tool's hard limits.

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 the baseline is 3. The description restates the input format ('bare hashes one per line or user:hash records including /etc/shadow') but adds no parameter-specific detail beyond what the schema already documents; the reveal_shared parameter is fully explained in the schema with privacy guidance.

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 verb and resource: 'Analyse a set of password hashes as a SET', then enumerates concrete outputs (format proportions, shared accounts, locked/passwordless entries, weakest algorithm). It also distinguishes itself from hash_identify by noting corpus-level questions cannot be produced by looping single-hash identification.

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?

It explicitly defines when the tool is appropriate: questions that are properties of the corpus rather than of any single hash. It names hash_identify as the alternative that cannot answer these questions, and the final sentence rules out misuse by saying it never cracks anything and never reaches the network.

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