cyberchef_rsa_attack

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

Beyond the annotations (readOnly, idempotent, non-destructive), the definition discloses real execution behavior: the attacks parameter warns that the full run 'costs up to 35 seconds of wall clock' because the four time-budgeted searches run sequentially on unbreakable keys. It also surfaces the outcome semantics — decrypting a supplied ciphertext when a key is recovered — and the epistemic limitation of negative results. The readOnlyHint is consistent since the tool only computes from its inputs and never mutates external state.

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?

Three sentences, with the core action and resource front-loaded and the negative-result caveat and decryption capability each earning their place. The first sentence is long because it enumerates all seven attacks with parenthetical explanations that partly duplicate the schema's attacks parameter, a minor redundancy that prevents a 5.

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 7-parameter crypto tool with no output schema, the definition covers inputs fully (rich schema), the attack space, wall-clock expectations, and outcome semantics (private key recovery, ciphertext decryption). The main gap is that no return-value shape is described, which the absence of an output schema leaves entirely to the agent to discover on first invocation.

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% with detailed per-parameter descriptions, so the baseline is 3. The main description adds semantics beyond the schema by glossing each attack's vulnerability — 'Fermat (primes too close)', 'Wiener (private exponent too small)', 'Pollard's p-1 (a prime whose predecessor is smooth)' — and the attacks parameter contributes operational meaning through sequential-timing and cost guidance. That genuine added value lifts it to a 4.

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 states specific verbs — 'Test', 'recover', 'Decrypts' — against a concrete resource (an RSA public key) and enumerates the seven distinct attack modes (trial division, Fermat, shared factors, Wiener, Pollard's rho, Pollard's p-1, small-e). This makes the tool's scope unmistakable and distinguishes it from crypto-adjacent siblings like cyberchef_rsa_multi_key and cyberchef_hash_crack without needing to open their schemas.

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?

The description gives clear when-to-use context: probe a key for generation flaws that make it breakable. It also frames the interpretive limits explicitly — a negative result is 'evidence the key is not weak in these specific ways, and not that it is strong' — and the attacks parameter advises naming specific attacks when the client has a shorter per-call timeout. It stops short of naming alternative tools or explicit when-not-to-use conditions, which keeps it at a 4.

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