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

Annotations mark this as destructive and potentially open-world, but the description itself adds no behavioral context beyond 'execute.' It does not mention whether output is returned synchronously, whether recipes can trigger external side effects, or what operational consequences the destructiveHint refers to. Since it adds no insight beyond the annotations, it under-delivers for an execution tool.

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 description is only two short sentences with no wasted words. It front-loads the main action and follows with a brief usage hint. Nothing repeats the schema, and every sentence earns its place.

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 output schema, potentially destructive behavior, and broad execution capabilities, this description is too thin. It does not describe return values, error behavior, execution limits, or how it differs from related tools like cyberchef_recipe_execute. The schema covers inputs well, but not the execution context an agent needs.

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 description coverage is 100%, and the schema already documents the input and recipe parameters, including the recipe's op/args shape and a pointer to cyberchef_describe_operation. The tool description adds no parameter-level detail, so it earns the baseline score of 3 rather than being penalized for a schema gap.

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 clearly states a concrete action and resource: it executes a CyberChef recipe. It also adds a usage scope by mentioning 'complex chains of operations.' However, it does not explicitly distinguish this from sibling tools like cyberchef_recipe_execute, which may also sound recipe-related, so it is not fully differentiated.

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 phrase 'Use this for complex chains of operations' provides a clear, explicit when-to-use context. It stops short of naming exclusions or alternatives such as cyberchef_magic or cyberchef_recipe_execute, so there is no when-not-to-use guidance.

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

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

Annotations already indicate destructive=true and readOnly=false, so the description does not need to restate that this is a mutating batch operation. It adds 'supports partial success,' which is useful, but does not explain failure semantics, side effects, ordering guarantees, or what happens to partially completed batches.

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 description is a single, tight sentence that front-loads the core purpose and includes the key nuance of partial success. Every part earns its place with no filler.

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, yet the description does not explain what the tool returns, how results are reported, how failures are surfaced, or how partial success manifests. For a batch execution tool with destructive potential, an agent needs more behavioral context to invoke it correctly and interpret results.

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?

Input schema coverage is 100%, and both properties have descriptions. The description mentions parallel/sequential mode, but the schema already documents the enum and default, so the description adds minimal new meaning beyond the structured data.

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 clearly states the tool executes multiple CyberChef operations in batch and identifies the two execution modes. It is specific enough to distinguish from most sibling tools that handle single operations, though it does not explicitly contrast with recipe_execute or bake.

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 phrase 'execute multiple operations in batch' implies this tool is for grouping operations rather than calling them one at a time, but it gives no explicit guidance on when to choose this over alternatives such as recipe_execute, nor does it mention any exclusions or prerequisites.

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

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

Description contradicts annotations: 'Clear' is a mutating action, but readOnlyHint is true. While idempotentHint and destructiveHint align with a cache-clear operation, the readOnly contradiction is significant and confusing for an agent deciding whether this tool is safe to invoke.

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 description is a single, front-loaded sentence with no filler or redundant information. It states the action and target in the fewest possible words.

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 zero-parameter operation, a one-line description is a minimum viable definition. However, it does not explain what 'operation result cache' is, what consequences clearing it has, or how it relates to cyberchef_cache_stats, and the readOnlyHint contradiction leaves the overall context inconsistent.

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?

There are zero parameters, so the empty input schema is fully self-explanatory. The description does not need to add parameter-level detail; baseline 4 applies.

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 uses a specific verb ('Clear') and a specific resource ('the operation result cache'), making the tool's action immediately clear. It also naturally distinguishes this tool from the sibling cyberchef_cache_stats: one clears, the other reports stats.

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 no guidance on when to clear the cache versus inspecting it with cyberchef_cache_stats, nor does it mention any prerequisites or side effects. Usage context is only implied by the verb 'Clear'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description is consistent with them. It adds the list of reported metrics but does not disclose extra behavioral details such as whether statistics are cumulative or reset by cache_clear.

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 description is a single efficient sentence with no filler; every word contributes to meaning and the key scoping phrase 'cache statistics' is front-loaded.

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 zero-parameter read-only utility the description is nearly complete, listing the essential output fields. It falls slightly short of 5 because it does not clarify units or semantics for 'size,' which could mean bytes, entries, or another measure.

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?

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter semantics are needed.

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 uses a specific verb ('Get') and resource ('cache statistics') and enumerates the exact metrics returned (hits, misses, size, items). This clearly distinguishes it from siblings like cyberchef_cache_clear (mutation) and cyberchef_worker_stats (different resource).

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?

No guidance is given about when to prefer this tool over alternatives or when not to use it. While the name and read-only annotations imply it is for inspection, the description does not state exclusions or mention cache_clear/worker_stats as alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is established. The description adds that results include counts and examples and that this is a discovery entry point, but it does not disclose additional behavioral constraints beyond those. No contradiction with 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?

Two short sentences: the first states exactly what the tool does, and the second provides the recommended usage flow. Every word earns its place with no redundancy.

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 zero-parameter, read-only discovery tool with an output schema, the description is complete. It tells the agent what the tool returns, why to use it, and what to do next.

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?

The tool has zero parameters, so there is nothing for the description to document. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing parameter details.

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 uses a specific verb and resource: it lists CyberChef's operation categories with counts and examples. It also explicitly differentiates itself from cyberchef_list_operations by framing this as the starting point for server-wide exploration.

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 gives explicit when-to-use guidance ('Start here to browse what this server can do') and names the next tool to use (cyberchef_list_operations). This makes the navigation path clear for an agent.

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

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

Beyond the readOnly/idempotent annotations, the description explains that every link is verified cryptographically and that matching names/key identifiers are only metadata, warning about substituted certificates. It also lists the distinct break conditions, adding meaningful behavioral detail that an agent could not infer from annotations or schema.

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 purposeful, front-loaded sentences: purpose and failure modes, a cryptographic verification caveat, and a disambiguation from related operations. No filler or redundant restatement of the tool name.

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 complex X.509 tool with no output schema, the description covers inputs, break-reporting behavior, cryptographic verification, and the single-certificate alternative. It stops short of specifying the exact success/error output shape, but enough is present for an agent to invoke it correctly.

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 description coverage is 100%, so the schema already documents input, as_of, and expiry_warning_days. The description reinforces the chain-ordering concept but does not add material parameter-level detail beyond the schema; the baseline of 3 applies.

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: 'Order a PEM bundle of X.509 certificates into a chain and report where it breaks.' It enumerates concrete failure modes and closes by contrasting itself with the other X.509 operations, so an agent can distinguish this chaining tool from single-certificate parsers.

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 makes the intended input context explicit: a PEM bundle in any order, such as fullchain.pem. The final sentence signals that this tool is for relating multiple certificates, while the other X.509 operations parse one certificate, giving implied when-to-use guidance, though it does not name the alternative tools directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that this is a pure encode/decode transform and that disputed conventions are exposed as parameters, which is useful but does not go into output format, error behavior, or operational edge cases.

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 description is two front-loaded sentences with no filler. The first sentence delivers the cipher list and scope; the second gives one concise rationale for the large parameter surface. Every clause earns its place.

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 high-complexity tool with 13 parameters, the description stays appropriately high-level while the schema's 100% coverage carries invocation details. It supplies key selection context: which ciphers, the tap-code equivalence, and the convention-parameter principle. An explicit output contract would be the only notable addition, but for encode/decode transforms the return shape is largely inferable.

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 description coverage is 100% and every parameter already has a detailed description, so the baseline of 3 applies. The description's statement that every contested convention is a parameter is a useful design principle but adds no concrete parameter-level meaning beyond the schema.

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 a specific verb ('encode and decode') and a concrete resource set ('Playfair, the Polybius square, ADFGVX and Baudot/ITA2'), and explicitly frames the tool as covering ciphers CyberChef lacks. The parenthetical about tap code being a Polybius square prevents a common mis-selection. This clearly distinguishes the tool from sibling operations.

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 clearly scopes use to the four listed classical ciphers and tells the agent these are ciphers CyberChef has no native operation for, which establishes when this tool is the right choice. It does not name a specific sibling tool as an alternative or list exclusion cases, but the selection context is strong enough to guide an agent.

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

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

Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral detail on top: it infers structure from byte AND bit variance, reports where repeated blocks sit, and emits the XOR of nonce-reused bodies. This goes well beyond the safety profile provided by 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?

The description is a single dense paragraph with no filler. The core purpose is front-loaded, each subsequent sentence describes a distinct capability, and the closing assumption is a necessary constraint. Every sentence earns its place.

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?

Given the tool's analytical complexity and the absence of an output schema, the description gives high-level but useful output expectations: field groupings, block locations, and an XOR result. It does not specify the exact return shape or how the three analyses are organized in the response, so a small gap remains for an agent that needs to interpret results precisely.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining what the analyses actually do (field grouping, block position reporting, XOR evidence), and it enriches the samples parameter with the fixed-length or left-aligned assumption. It does not tie these details to specific parameter names, but it still adds useful context.

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: 'Compute statistics ACROSS a set of samples.' It then enumerates the concrete analyses performed (field inference, repeated-block detection, nonce reuse), which clearly distinguishes this tool from single-input recipe/bake siblings. The contrast with Fork makes the purpose and scope unmistakable.

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 explicitly states when to use this tool instead of a recipe: 'what a recipe cannot express, since Fork runs each branch separately and nothing combines them.' It also provides a key exclusion condition with 'Assumes fixed-length or left-aligned samples,' telling the agent when the tool is not appropriate.

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

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

Annotations already mark the tool read-only and non-destructive; the description adds substantial behavioral detail beyond that: XOR cancels the key in two-ciphertext mode, periodicity modulo key_length is a stronger filter than printability, and full key recovery requires a crib at least as long as the key. No contradiction with 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?

The description is dense but efficient: three sentences front-load the core behavior, then explain the two modes and the key_length refinement. No filler or redundant restating of the tool name.

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?

The description covers the core algorithm, mode selection, key_length behavior, and key-recovery requirements. The only notable gap is the lack of an explicit output-shape description, such as how offsets and recovered key bytes are formatted, and no output schema exists to fill that 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 100%, so the baseline is 3. The description adds meaning by explaining that ciphertext_b is only for the shared-key mode, key_length applies in single-ciphertext mode, and periodicity filtering is stronger than printable_only. This goes beyond the schema without repeating it.

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 a specific technique and resource: dragging a guessed plaintext crib along XOR ciphertext and reporting ranked matching offsets. It also clearly distinguishes the two operating modes (two ciphertexts vs one), so an agent can tell it apart from generic CyberChef operations.

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 explicit mode-selection guidance: with two ciphertexts under the same key, use it to recover the other plaintext span; with one ciphertext, use it for key-byte recovery, and supply key_length to strengthen filtering. It does not explicitly name alternative sibling tools, but the specialized purpose and conditions are clear.

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

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

Beyond the readOnly/idempotent annotations, it discloses a non-obvious parsing trap: 'hex input is interpreted as both big- and little-endian, because a register dump is usually reversed relative to memory.' It also states the interop guarantee with pwntools' cyclic/cyclic_find, which an agent could not infer from the schema or 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?

Three sentences with no filler: purpose, compatibility, and a concrete usage scenario. The most important scoping information is front-loaded in the first sentence, and every sentence earns its place.

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?

Despite having 6 parameters and no output schema, the description covers the core generate/find workflows, explains the compatibility contract, and warns about the endianness subtlety. Remaining details (defaults, bounds, enum values) are fully documented in the schema, so nothing an agent needs to invoke this correctly is missing.

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 per-parameter descriptions, defaults, and enums, so the baseline is 3. The description adds workflow wiring — mapping fragment bytes from a register dump and mode=find to the overflow offset — and the dual-endianness interpretation that modifies how `fragment` is parsed. These add meaning beyond the schema fields.

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 precise verb+resource statement: 'Generate a De Bruijn (cyclic) pattern, or find the offset of a fragment within one,' covering both modes explicitly. The pwntools compatibility mention further differentiates it from every sibling, none of which reference cyclic patterns or overflow offset finding.

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 gives an explicit when-to-use instruction: 'Use mode=find with the bytes recovered from a crashed register to get the overflow offset,' tying the tool to a concrete exploit-development workflow. It does not name explicit alternatives or when-not-to-use conditions, but no sibling overlaps with this functionality, so the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond that by specifying the semantic scope ('current session') and the precise output content (triggered deprecation warnings and v2.0.0 preparation status). No contradictions with 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?

Two focused sentences, each earning its place: the first states the core function and scope, the second details what information the statistics include. There is no redundant or filler language.

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 zero-parameter, read-only stats tool with no output schema, the description is fully adequate: it states what the tool does, its scope, and the substance of the result. Combined with the rich annotations (read-only, idempotent, non-destructive), nothing essential is missing.

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?

The tool has zero parameters and the input schema is empty, so schema description coverage is 100%. Per the baseline rule for tools with no parameters, a score of 4 is appropriate; there are no parameter semantics for the description to clarify.

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 uses a specific verb ('Get') and precise resource ('statistics on deprecated API usage'), and further clarifies what is included: 'which deprecation warnings have been triggered and v2.0.0 preparation status.' This clearly distinguishes it from sibling stats tools like cyberchef_cache_stats or cyberchef_worker_stats, which focus on different domains.

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 a clear context: use it when you need deprecation statistics or v2.0.0 preparation status in the current session. It does not explicitly mention alternatives or when-not-to-use, but the specificity of the scope ('current session', 'deprecated API usage') makes the intended use obvious.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying what information the tool returns (schema, defaults, types) and why it matters for baking operations. This goes beyond simply restating 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?

The description is two concise sentences with no filler. The core value proposition is front-loaded, and the practical usage note immediately follows, making it easy for an agent to parse and act on.

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?

Given the low complexity, high schema coverage, and read-only annotations, the description is largely complete. It states the input, the output content, and the usage context, though it does not mention error behavior for unknown operation names—a minor 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?

The schema already documents the operations parameter with examples and types, so description-level parameter explanation is not critical. The description reinforces that one or more operation names are accepted and that this is for new operations, but it does not add significant semantic detail beyond the schema.

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 clearly states the tool's function: it returns the full argument schema, defaults, and types for one or more operations. It also distinguishes itself from cyberchef_bake by positioning this as a required prerequisite step, making its purpose unambiguous.

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 explicitly tells the agent when to use this tool: before calling cyberchef_bake with a new operation. It does not enumerate alternatives or exclusions, but the workflow context is clear enough to guide correct usage.

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

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

The description goes well beyond the readOnlyHint/idempotentHint annotations by disclosing that up to TWO candidates may be returned, why low-S normalization makes that common, and that a wrong curve produces a plausible but unverifiable number. It also clarifies the operation is deterministic algebra, not a search, which is non-obvious behavioral context.

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 description is dense but every sentence earns its place: purpose, formula, output ambiguity, scope contrast, and exclusion of biased-nonce attacks. It is front-loaded with the core purpose and remains tightly structured despite covering subtle cryptographic behavior.

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?

Even without an output schema, the description tells the agent what to expect (up to two candidates), why ambiguity can occur, what inputs are required conceptually, and what failure modes exist (wrong curve, biased nonces). This is complete enough for correct invocation and interpretation for a specialized cryptographic tool.

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?

The input schema already documents every parameter thoroughly (curve enum, signature formats, hash width rationale), so parameter-level detail is well covered. The description adds mathematical meaning by giving the exact formulas involving z1, z2, s1, s2, and r, and notes that only the curve's order n is used—value beyond the schema's field-level descriptions.

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?

States a specific verb ('Recover'), a precise resource ('ECDSA private key'), and the exact attack condition ('two signatures that reused a nonce, detected by a shared r'). It also distinguishes itself from single-signature ECDSA operations and from search-based approaches, so an agent can separate it from siblings 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?

Explicitly defines when to use the tool: when two signatures share an r, and when not to use it: biased nonces require a lattice and are not implemented. It also contrasts this tool against the four single-signature ECDSA operations, giving clear routing logic against sibling tools.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail on top: the exact Lyda-Hamrock conjunction thresholds, the second chi-squared/serial-correlation axis, and an explicit caveat that the report states what a high number does and does not establish.

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 description is dense but every sentence earns its place: purpose, comparison to the naive alternative, methodology, and interpretative limits. The most important capability is front-loaded in the first sentence.

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?

The description provides strong context for a read-only scan with six parameters and no output schema: what it scans for, the algorithm, and the caveat about interpretation. It leaves the exact return structure somewhat implicit, but the schema covers all inputs and the core behavior is clear.

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 description coverage is 100%, so the parameters are already well documented. The description adds conceptual context about thresholds and windows but does not need to repeat per-parameter details; the baseline of 3 is appropriate.

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 first sentence states a specific verb and resource: find WHERE entropy is high in a file, returning contiguous regions above a threshold with offsets. It clearly distinguishes the tool from CyberChef's generic Entropy curve by naming what is missing there (fixed 256-byte bin, no threshold, no region output).

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 context for when this tool adds value: locating high-entropy regions and separating compressed data from encrypted data. It contrasts with CyberChef's Entropy curve and says it goes beyond a simple 'whether' answer, but it stops short of an explicit, structured when-to-use/when-not-to-use guide with named sibling tools.

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

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

Annotations only declare readOnly and idempotent hints; the description adds meaningful runtime behavior: a 20-second bound, about 24 million candidates, a built-in common-password list, cheap mutations, and a deliberate refusal path for memory-hard KDFs so an empty result won't be misread as a strong password. There is no contradiction 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?

Every sentence earns its place: purpose, workflow placement, exclusions, input expectations, and time bound. The most decision-relevant information is front-loaded, and the description remains compact despite covering several distinct behaviors.

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?

All invocation-critical details are present: supported algorithms, wordlist handling, mutation toggle, common-password behavior, time bound, and anti-pattern refusal. A small gap is the lack of an output/return description (e.g., what is returned when no candidate matches within the time bound), and there is no output schema to fill that 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 description coverage is 100%, and the schema already explains hashes, wordlist ordering, algorithm auto-inference, mutations, and include_common. The description adds some framing around the wordlist and mutations but does not need to compensate for missing parameter documentation, so the high-coverage baseline of 3 applies.

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 opening sentence names the verb (Recover), the resource (plaintext behind a fast unsalted hash), and the exact hash families (MD5, SHA-1, SHA-256/384/512, NTLM). It also distinguishes it from sibling hash_identify by framing this as the follow-up question, so an agent can tell at a glance what this tool does and how it relates to nearby tools.

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 explicitly says this follows hash_identify, scopes usage to fast unsalted hashes, and names algorithms it deliberately avoids (bcrypt, scrypt, Argon2, yescrypt, crypt(3)) with the rationale. This gives both when-to-use and when-not-to-use guidance without requiring the agent to inspect sibling descriptions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile needs no repetition. The description adds genuine behavioral context beyond annotations: the length-based fallback for bare digests, multiple matches (one report 'for each match'), and why structure-based identification is required for non-hex hashes. No annotation contradiction.

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, each earning its place: purpose plus outputs, fallback behavior, then routing guidance. The core purpose is front-loaded before the format list, and the when-to-use advice is saved for last. No filler or repetition of schema/annotation content.

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 low-complexity tool (1 required parameter, no output schema, read-only/idempotent annotations), the description covers what the tool returns (hashcat mode, John format), edge-case behavior (bare digests), and when to invoke it. With no output schema present, the description adequately conveys the return shape. Nothing an agent needs to call it correctly is missing.

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% ('The hash, one per call. Whitespace is trimmed.'), so the baseline is 3. The description adds semantic meaning by specifying the input type (a password hash, not arbitrary data) and implying that bare hex digests are also accepted via the fallback, which helps an agent judge what to pass. This pushes it above baseline.

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 a specific verb and resource — 'Identify a password hash by its structure' — and enumerates concrete output artifacts (hashcat mode, John format name) plus supported formats. It differentiates itself from siblings like cyberchef_hash_crack and cyberchef_timestamp_identify by scoping to structure-based identification rather than cracking or timestamp detection.

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?

Explicitly states when to use it ('Use this before trying to crack something') and names the alternative it replaces (CyberChef's Analyse hash operation), explaining that the alternative misreads bcrypt, sha512crypt and argon2 as 'Invalid hash'. This is concrete routing guidance an agent can act on without inspecting siblings.

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

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.

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: the exact check categories (algorithm bypass variants including case/Unicode escapes, empty signature, ECDSA psychic signature CVE-2022-21449, quickstart secrets, standard claims). Most valuably, it discloses the confidence semantics — headers like jku, jwk, x5u, kid are 'reported as present, never as confirmed' — which prevents the agent from over-interpreting findings.

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 description is front-loaded with the core purpose in the first sentence, then builds purpose → differentiation → check checklist → caveat in logical order. Every sentence carries load-bearing information, though the second sentence is dense and could be tightened into a shorter aside without losing the usage guidance.

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 no output schema, the description carries the burden of conveying what the tool reports, and it delivers: it enumerates the check categories, explains the scope limitation ('from the token alone'), and specifies the confidence granularity of findings. It does not describe the exact report/return structure, but for a scanner of this complexity the behavior is well-specified.

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 raises it by contextualizing the secrets parameter as the 'built-in quickstart list' that the checks exercise, connecting the schema's 'configuration check, not a cracking run' framing to the described behavior. The now_seconds parameter's default behavior is fully documented in the schema, so no description compensation is needed.

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 opening sentence names a specific verb, resource, and scope: 'Report everything wrong with a JWT that can be established from the token alone.' It then explicitly differentiates itself from JWT Verify by explaining that signature validity is 'a different question.' An agent can tell exactly what this tool does and how it differs from related operations 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?

The description explicitly names the alternative ('JWT Verify') and gives the condition that selects it: someone wanting to know whether a signature is valid under a supplied key should not use this tool, because 'alg: none has no signature to verify and one signed with secret verifies perfectly.' The secrets parameter also routes wordlist cracking to 'hashcat mode 16500,' providing a clear when-not-to-use signal.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that results are one-line summaries and that deeper argument details are intentionally deferred to another tool, which shapes agent expectations beyond 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?

Two sentences with no fluff: the first states the operation and output, the second routes to the relevant sibling. The most important scoping information is front-loaded.

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 simple read-only listing tool with one documented parameter and an output schema, the description covers what an agent needs to select and invoke it correctly. It also names the natural follow-up tool for richer detail.

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 description coverage is 100% and the single 'category' parameter is already documented with examples. The description adds minimal semantic value beyond restating the category concept, so it appropriately relies on the schema.

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?

States a specific verb ('List'), a resource ('operations'), and a scoping dimension ('in one category') plus the output format (one-line summary). It also differentiates from cyberchef_describe_operation by explicitly directing full argument schema lookups there.

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 usage context: use this tool for category-scoped operation lists with summaries. It names the alternative tool for a different need ('Use cyberchef_describe_operation for full argument schemas'), effectively telling the agent when not to use this tool.

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

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

The description reveals that matching operations will actually be run and their results analyzed, which is useful behavioral context beyond the readOnly/idempotent annotations. The text is truncated at 'the result will be ana...', so the full behavior is not visible; this limits the transparency score.

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 opening sentence is informative, but the text is poorly formatted with run-together content like 'it.OptionsDepth:' and appears truncated. It is not excessively long, but the structure is messy enough to reduce clarity.

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 no output schema, the description should say more about what Magic returns—such as suggested recipes, confidence levels, or decoded output—but it only says it 'suggests which operations.' The parameter docs are strong, yet the missing output expectations and truncated description leave a moderate 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 description coverage is 100%, and each parameter already has rich, behavior-oriented documentation such as cost growth, 100-byte limits, and language count trade-offs. The tool description adds little beyond what the schema already provides, so baseline 3 is appropriate.

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 a specific purpose: detect properties of the input data and suggest operations to make sense of it. This clearly identifies the tool's function, though it does not explicitly differentiate it from sibling detection tools like cyberchef_entropy_scan or cyberchef_hash_identify.

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?

Usage context is implied rather than explicit: an agent can infer this is for unknown-format input that needs automatic analysis. However, there is no direct guidance about when to prefer Magic over alternatives like baking a known recipe or using a more targeted identifier.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds that it returns compatibility issues and can transform recipes, but it does not clarify whether 'transform' returns a converted recipe or persists changes, which is ambiguous given readOnlyHint=true. This is not a direct contradiction, but it misses an opportunity to remove confusion.

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 description is a single, efficient sentence that front-loads the core purpose and packs both operational modes without wasted words.

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 full schema coverage and safety annotations, the description is mostly sufficient, but the absence of an output schema and the ambiguity around whether transformation modifies state leave an agent without a complete picture of the result or effect. More detail on the issue format or the read-only nature of the transform would be needed for a higher score.

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 description coverage is 100%, and the schema already documents the mode enum and the recipe parameter. The description adds no concrete parameter-format details beyond what the schema provides, so the baseline of 3 is appropriate.

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 a specific action ('Analyze... for v2.0.0 compatibility'), identifies the resource ('recipes and configurations'), and clearly distinguishes this tool from siblings like cyberchef_deprecation_stats or cyberchef_recipe_validate by its migration focus. The optional transform behavior is also explicitly named.

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 clearly frames when to use this tool: when checking or migrating recipes/configurations to v2.0.0. It does not explicitly name alternatives or state when not to use it, so it misses the top score, but the context is unambiguous.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds useful behavioral detail by listing the exact evidence reported (printable ratio, English word hits, chi-squared, index of coincidence) and the verdict-plus-reason output, going beyond what the annotations alone convey.

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 description is front-loaded with the core purpose, then delivers a compact list of reported evidence and a practical use case. Every sentence contributes either purpose, output clarity, or usage guidance, with no filler.

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?

Given no output schema, the description sufficiently covers return content by naming the evidence fields and the verdict/reason. It also provides the key context for when this tool is useful, while the schema and annotations cover parameter constraints and safety. Nothing essential for selecting or invoking the tool is missing.

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 description coverage is 100%, so the schema already explains that 'input' is the candidate and 'language' selects the English model. The description reinforces the notion of a candidate and mentions English, but adds no parameter-level detail beyond what the schema provides; baseline 3 is appropriate.

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?

States a specific action ('Decide whether a candidate is plaintext') and a concrete resource/output (verdict plus deciding evidence). It also distinguishes itself from CyberChef operations by explaining that they expose statistics, not the verdict, which differentiates it from siblings like cyberchef_entropy_scan.

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?

Gives clear context: it is the stopping condition when peeling layers off unknown data by hand, and positions the tool as the judgement an automatic-decoding search needs. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful context that the information is 'current' and includes concurrent operations and data sizes, but it does not describe the output shape or any refresh/accuracy behavior. With annotations carrying the main burden, this is acceptable but not rich.

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 description is one tight, front-loaded sentence: 'Get current resource quota information' immediately conveys the action and subject, and 'including concurrent operations and data sizes' adds valuable scope without unnecessary words.

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 no-parameter, read-only info tool, the description plus annotations are nearly sufficient for an agent to call it correctly. The only notable gaps are the lack of explicit usage guidance relative to similar stats tools and the absence of any indication about return format, but the tool is simple enough that these are minor rather than blocking.

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?

The tool has no parameters and the schema is empty, so there is nothing for the description to clarify. Schema description coverage is effectively 100%, and the baseline for zero-parameter tools applies. The description adds no parameter-specific meaning, but none is needed.

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 a specific action ('Get'), a distinct resource ('resource quota information'), and the content scope ('concurrent operations and data sizes'). It clearly identifies what the tool does and separates it from cache/stats/worker sibling tools by naming the quota resource.

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 only implies when to use this tool: when current quota information is needed. It does not explicitly say when to prefer it over related tools like worker_stats or cache_stats, nor does it mention any exclusions. For a zero-parameter read tool this is minimally adequate but leaves the agent to infer context.

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

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

The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) establish that this is a non-idempotent write that does not destroy data, and the description's 'Create' verb is consistent with that. However, beyond confirming the write, the description discloses no behavioral context: it does not say what happens on duplicate names, whether the recipe is persisted server-side, whether operations are validated at creation time, or what the agent should expect in return. With idempotentHint=false, duplicate-handling behavior is especially relevant and is left entirely unaddressed.

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 description is a single seven-word sentence with the verb front-loaded and zero filler. It is efficiently structured and immediately readable. However, it is arguably thinner than the tool's complexity warrants, which slightly undercuts the conciseness.

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?

This is a mutation tool with 6 parameters, nested objects, no output schema, and 39 siblings including 9 recipe-* tools, yet the description provides only one sentence. With no output schema, the agent cannot infer the return value or success indicators, and the description does not cover them. Missing context around duplicate handling, validation behavior, and relationship to recipe_validate/recipe_test/recipe_import leaves the description incomplete for correct 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 description coverage is 83%, above the 80% threshold, so the schema carries most of the parameter documentation (name, tags, author, operations, description all have descriptions). The description's 'multiple operations' merely echoes the schema's 'List of operations' field and adds no new semantics. The few uncovered details, such as the inner metadata fields (category, complexity, estimatedTime) and the args/recipe structure inside operations items, are not compensated for by the description, keeping this at baseline.

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 a specific verb ('Create') and resource ('a new recipe'), and the phrase 'with multiple operations' adds a scoping detail that aligns with the required operations parameter. It is clearly distinguishable from siblings like recipe_delete, recipe_get, and recipe_update by the create verb, though it does not explicitly name or differentiate from recipe_import, which could also be used to bring recipes in.

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 guidance on when to use this tool versus the many recipe-related siblings (recipe_validate, recipe_test, recipe_import, recipe_update). An agent gets no hints about workflow ordering, such as whether to validate operations before creating, or which sibling handles modifications to an existing recipe. Nothing in the description establishes selection criteria among alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the agent knows this operation mutates and can be repeated. The description adds no extra behavioral context beyond what the annotations provide, such as whether deletion is permanent, whether related data is affected, or whether authorization is required. Because the annotation already carries the core safety signal, the description is adequate but not enriched.

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 description is one short sentence that states the operation and parameter without waste. It is front-loaded and easily scanned. It could earn a 5 only by adding a bit more practical context, but for its brevity it is efficiently structured.

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?

Given that there is no output schema and this is a destructive operation, the description could usefully mention what the response looks like (e.g., success confirmation or deleted recipe) or any non-obvious behavior such as idempotent deletion of an already-missing recipe. The annotations cover the destructive and idempotent nature partially, but the description itself is minimal. It is adequate for a simple one-parameter delete but leaves room for more complete context.

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?

The input schema covers the single parameter (id) with a format and pattern, and the schema description coverage is 100%, so the schema does the heavy lifting. The description only says 'by ID' and does not add anything concrete about the semantics of id beyond what the schema already states. Baseline 3 is appropriate.

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 'Delete a recipe by ID' uses a specific verb ('Delete') and names the resource ('recipe') and the identifying parameter ('ID'). It is clear at a glance which operation is performed and on what entity, and the presence of sibling tools like cyberchef_recipe_get, cyberchef_recipe_create, and cyberchef_recipe_update makes this description sufficiently distinct as the deletion counterpart.

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 implies use when a recipe should be removed by its UUID, but it does not explicitly state when to use it versus alternatives or mention any restrictions or side effects such as whether the deletion is permanent or cascades. There is no explicit when-not-to-use guidance, so an agent is left to infer the usage context from the verb and resource.

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

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false, and the description adds no behavioral context beyond them. It does not disclose side effects, whether input is irreversibly transformed, quota consumption, or what 'execute' entails — all relevant given the destructive flag. There is no contradiction with the annotations, but the description contributes no additional transparency.

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 description is a single eight-word sentence with the verb front-loaded and zero filler words. It is efficient and scannable, though slightly under-sized for a tool carrying a destructive flag and a near-identical sibling.

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 should convey what the call returns on success, but it is silent on that. With destructiveHint=true and a large sibling set that includes cyberchef_bake and cyberchef_recipe_test, the description is too thin for an agent to invoke it confidently without external knowledge.

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%: the schema already documents 'id' as 'Recipe UUID' and 'input' as 'Input data to process'. The description's phrase 'with input data' merely restates the schema, so it adds no parameter-level meaning; the high-coverage baseline of 3 applies.

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 a specific verb (Execute) and resource (a saved recipe) along with the input payload, making the core action unambiguous. The qualifier 'saved' distinguishes it from recipe-management siblings like cyberchef_recipe_create/get/delete, but it does not explicitly differentiate it from the close sibling cyberchef_bake, so the distinction is implied rather than stated.

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 no when-to-use guidance, exclusions, or mention of alternatives. An agent cannot tell from this text whether to choose cyberchef_recipe_execute or cyberchef_bake (or cyberchef_recipe_test), since the selection criteria between saved-recipe execution and inline baking are never stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds little beyond the format list and does not disclose what the export returns or whether it has side effects, though no contradiction exists.

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 description is a single, direct sentence with no filler or redundancy. It immediately communicates the action, target, and supported formats.

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 simple read-only export operation, the description and schema cover the necessary inputs, and annotations cover the safety profile. However, there is no output schema and no note describing whether the export returns file contents, a URL, or another representation, which leaves a meaningful gap for agents using the result.

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 description coverage is 100%, with 'id' described as 'Recipe UUID' and 'format' as 'Export format' with a full enum. The description's format list largely restates the enum, adding no significant new meaning beyond what the schema already provides.

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 a specific verb ('Export'), a specific resource ('a recipe'), and enumerates the target formats (json, yaml, url, cyberchef). This clearly distinguishes the tool from siblings like cyberchef_recipe_import and cyberchef_recipe_get.

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 purpose is clear, but the description does not explicitly say when to use this tool versus alternatives such as recipe_get or recipe_import. The word 'Export' implies its niche, but no exclusions or alternative references are provided.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds no further behavioral details such as not-found behavior, response shape, or permission requirements, but it does not contradict 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?

The description is a single clear sentence with no filler or redundant wording. Every word contributes to the basic purpose of the tool.

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?

This is a simple one-parameter read-only getter, and the schema plus annotations cover most invocation needs. The absence of an output schema and any mention of what fields the returned recipe contains is a minor gap, but not enough to make the description inadequate.

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 description coverage is 100% and the single parameter 'id' is already described as 'Recipe UUID' with a UUID format and pattern. The description does not add meaningful parameter information beyond what the schema already provides.

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 clearly states the action ('Get'), the resource ('a recipe'), and the identifying mechanism ('by ID'). It is distinguishable from recipe_list and recipe_create, but it does not explicitly differentiate itself from recipe_export or recipe_execute.

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 phrase 'by ID' implies this tool should be used when the agent already has a recipe UUID and wants the stored recipe. However, no alternative tools are mentioned and no explicit when-to-use or when-not-to-use guidance is given.

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

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

Annotations already communicate that this is a non-destructive, state-changing operation, so the description does not need to restate that. It adds the fact that the recipe can come from external formats, but it does not disclose whether the import creates a new recipe, overwrites an existing one, or validates input first.

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 description is a single front-loaded sentence with no filler, making it concise and easy to scan. It is slightly too terse to carry meaningful selection guidance, but structurally it is efficient.

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 a fully descriptive schema and enum, the minimal description plus schema is enough for an agent to construct a valid call. However, the lack of mention of the import's effect or return value keeps it at only a minimum-viable level, especially with no output schema.

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?

The input schema covers both parameters with descriptions and an enum for format, so the schema does the heavy lifting. The description's 'various formats' adds no meaning beyond what the schema already provides.

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 clearly names the action ('Import') and the target resource ('a recipe'), and 'from various formats' conveys the operation's scope. It does not explicitly differentiate from sibling tools like recipe_create or recipe_export, so it is clear but not sharply distinguished.

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 guidance about when to choose import over alternatives such as recipe_create, recipe_export, or recipe_validate. 'From various formats' implies existing serialized recipe data, but the description never states exclusions or when to use a different sibling tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful scoping context by stating it lists all recipes with optional filtering, but it does not disclose pagination defaults, response shape, or ordering behavior.

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 description is a single concise sentence with no filler. The primary action, 'List all recipes', is front-loaded and the filtering detail is relevant.

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?

The schema documents all five optional parameters and the annotations cover read-only and non-destructive behavior. However, with no output schema, the description does not clarify what a returned recipe entry looks like, whether results are paginated by default, or what ordering is applied. This is minimally adequate but leaves some operational ambiguity.

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?

The input schema has 100% description coverage, with parameters like 'Filter by tag', 'Maximum results', and 'Pagination offset' already self-explanatory. The tool description's mention of optional filtering adds no meaningful semantics beyond the schema, so the baseline score of 3 applies.

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 uses the concrete verb 'List' and identifies the resource 'recipes', while also noting optional filtering. It is clear, but it does not explicitly distinguish this tool from sibling tools like cyberchef_recipe_get or cyberchef_list_operations.

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?

No guidance is given about when to use this tool instead of alternatives such as cyberchef_search, cyberchef_recipe_get, or cyberchef_list_operations. The phrase 'optional filtering' implies some use cases, but the description lacks explicit when-to-use or when-not-to-use guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to restate those. The description adds the basic behavior that the tool runs a test with sample inputs, which is already clear from the name and schema. It does not disclose anything beyond that, such as what 'testing' does differently from executing, what the result payload contains, or side effects like caching. That is acceptable given annotations but not richly transparent.

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 description is a single short sentence: 'Test a recipe with sample inputs.' There is no wasted wording, and the core action and object are front-loaded. It could earn a 5 if it also gave a one-line usage hint, but as written it is concise and structured enough for quick parsing.

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 read-only, idempotent tool with full schema coverage and no output schema, the description is minimally sufficient. However, it lacks contextual completeness in one important respect: given sibling names like cyberchef_recipe_validate, cyberchef_bake, and cyberchef_recipe_execute, an agent might not understand what 'test' uniquely offers. The description does not clarify the expected outcome of a test or how it differs from validation/execution, so the tool's role in the larger toolkit is not fully complete.

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 description coverage is 100%, so the schema already documents recipe and testInputs as an object containing a name and operations array and an array of test values. The description adds minimal semantic value beyond 'sample inputs' as the purpose of testInputs. It does not explain the nested operation structure, the meaning of args, or constraints on test inputs, but the schema already carries that burden. Baseline 3 is appropriate.

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 'Test a recipe with sample inputs' states a specific verb ('test') and resource ('recipe'), and the parameter names (recipe, testInputs) reinforce that this tool validates a recipe against sample inputs. While it is reasonably clear, it does not explicitly contrast itself with sibling tools like cyberchef_validate or cyberchef_bake, so it gets a 4 rather than a 5.

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 implies usage: use this tool when you have a recipe and sample inputs and want to test whether the recipe produces expected results. However, it does not explicitly say when to prefer this over cyberchef_recipe_validate (validation of recipe structure) or cyberchef_bake (executing a recipe against data). It gives no 'use X instead' guidance, so it is adequate but lacks explicit routing.

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

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

Annotations already indicate destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds no behavioral context beyond the generic word 'Update.' It does not disclose whether this is a partial update (only provided fields change) or a full replacement, what data may be overwritten, or any side effects. With a destructive tool and no additional behavioral disclosure, the description underperforms.

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 description is a single short sentence with no waste, but it is under-specified for a tool with six parameters and nested objects. It is concise without being informative. Other similarly short descriptions that listed updatable fields have been graded slightly higher because they front-load useful content.

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?

Given the tool has six parameters, nested objects, a destructive annotation, and no output schema, the description is far too thin. It does not explain update semantics, which fields can change, whether partial updates are supported, or anything about expected behavior after invocation. An agent would need to rely entirely on the schema and annotations.

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 description coverage is 83%, and the schema already documents parameters such as id, name, tags, metadata, operations, and description. The description itself adds no parameter meaning, but the high schema coverage means the baseline applies. No compensation is needed, though the description could have noted that only supplied optional fields are updated.

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 uses a specific verb and resource: 'Update an existing recipe.' It clearly identifies the tool as a modification operation on a recipe, and 'existing' subtly distinguishes it from create and delete siblings. However, it does not explicitly name sibling tools or state the scope of what can be updated, so it falls short of full differentiation.

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 no indication of when to use this tool versus alternatives like cyberchef_recipe_create, cyberchef_recipe_delete, or cyberchef_recipe_get. There are no exclusions, prerequisites, or context about why an agent would choose this update tool over related recipe operations.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety burden is covered. The description adds the no-save behavior, which is useful, but says nothing about what 'validate' returns or how it signals failure, so some behavioral context is missing.

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 sentence that front-loads the verb and resource, with no filler or duplicated schema information. Every phrase earns its place.

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 validation tool with no output schema, the description does not explain validation behavior (syntax only vs. deep operation/arg validation), error signaling, or whether the recipe is normalized/reported. The nested recipe structure and many sibling tools increase the need for more context.

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?

The schema has 100% description coverage, including the recipe property marked as 'Recipe to validate', so the description doesn't need to restate parameter meaning. It adds no operational detail about the nested operations/args structure, but baseline 3 is appropriate since schema handles the heavy lifting.

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?

Uses a specific verb ('validate') and resource ('recipe') and immediately qualifies that no save occurs, which separates it from create/update/execute siblings. It doesn't explicitly distinguish from recipe_test, so not a full 5.

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 phrase 'without saving it' implies use for non-persistent validation, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools like recipe_test or recipe_execute. The usage context is only inferable.

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations, notably that three of the four attacks recover the message without factoring anything, which sets expectations for what the tool achieves.

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 description is dense but efficient, packing the purpose, all four attacks, and the sibling pointer into a compact form. It is slightly long as a single sentence but every clause adds useful information.

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 complex multi-key cryptanalysis tool, the description covers the main use cases, attack conditions, and the single-key alternative. It does not describe output format, but given the absence of an output schema and the rich input schema, the description is sufficiently complete for an agent to invoke it correctly.

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%, but the description still adds meaning beyond the parameter names. It explains the franklin_reiter relation parameters as m1 = a*m2 + b and emphasizes that the relation must be known, which is crucial for correct use.

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 ('Attack a SET of RSA keys') and clearly defines the resource and scope. It distinguishes itself from its sibling by naming the single-key alternative, rsa_attack, and explaining that this tool handles multi-key scenarios.

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 states when to use this tool: for a set of keys or multiple ciphertexts under one key, versus rsa_attack for a single key. It also lists the conditions for each attack type, making selection among the four attacks straightforward.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral detail by stating the result shape (names and one-line summaries) and signaling that full schemas are intentionally deferred to another tool. This is meaningful context beyond 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?

Two tight sentences with no filler. The core action is front-loaded, the return behavior is stated, and the recommended next step is included. Every sentence earns its place.

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 simple read-only search tool with fully documented parameters, the description is nearly sufficient. It covers purpose, return content, and follow-up. The main gap is the lack of explicit positioning against cyberchef_list_operations, which could leave an agent slightly uncertain about which search/list tool to choose.

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 description coverage is 100%, so the schema already documents both parameters clearly. The description adds no extra parameter-level meaning, such as how 'query' matches against operations or when 'detailed' should be set. Baseline 3 applies because the schema carries the burden successfully.

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 a specific verb ('Search') and resource ('available CyberChef operations'), and clarifies that it returns names and one-line summaries. It distinguishes itself from cyberchef_describe_operation by pointing to that tool for schemas, but it does not explicitly differentiate itself from the similar-sounding cyberchef_list_operations, so it stops short of full sibling differentiation.

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 context: use it to search for operations, and follow up with cyberchef_describe_operation for argument schemas. It does not explicitly say when to prefer this over cyberchef_list_operations or cyberchef_categories, but the search-focused guidance is still useful and actionable.

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

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

Discloses stochastic hill-climbing with random restarts, non-deterministic behavior, benchmark success rates (83.6/91.2/95.9%), and the practical failure mode that a few letter pairs may remain swapped. It also provides the remediation (pass `known_mapping` and rerun). These details go well beyond the readOnly/non-destructive annotations and reveal the search is not guaranteed-exact.

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 with no filler: purpose and method, alternative rationale, error-rate expectations, and a concrete follow-up instruction. The main action and scope are front-loaded, and each remaining sentence carries operational value.

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 non-deterministic cryptanalysis tool with five parameters and no output schema, the definition supplies the key behavioral context: domain (English prose), expected accuracy, and how to improve results. The only notable gap is that the return shape (what parts are the recovered mapping vs. the decrypted preview) is not stated explicitly, though `preview_letters`' schema hint partially covers it.

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?

All five parameters already have detailed schema descriptions (100% coverage), so the bar for description contributions is lower. The description still adds meaningful input-length/accuracy expectations via the benchmark figures and offers a concrete usage strategy for `known_mapping`. It appropriately relies on the schema for `seed`, `restarts`, and `preview_letters` rather than restating them.

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?

States a specific action ('Recover a monoalphabetic substitution mapping') with the method (hill-climbing on English trigram fitness with random restarts), and scopes the cipher families covered ('Also solves Caesar, ROT-N and Atbash'). It also distinguishes itself from `Substitute` by noting that no operation finds a mapping. Readily distinguishable from siblings such as `vigenere_break`.

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?

Clearly tells the agent to use this when the mapping is unknown: 'Substitute needs the mapping and no operation finds one.' It also gives a repair workflow: pin known letters with `known_mapping` and run again. It stops short of explicitly routing away from the near-sibling `vigenere_break` for polyalphabetic ciphers, though 'monoalphabetic' implies the boundary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds one behavioral detail beyond that: the returned data is anonymized. This is useful context but not extensive; no rate limits, auth requirements, or output-shape caveats are mentioned.

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?

Two short sentences, both functional: the first states the operation, the second adds the anonymization detail. No fluff, no repetition of the schema, and the core action is front-loaded.

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 one optional parameter, complete schema coverage, and safety annotations, the description is nearly sufficient. It does not explain what the 'json' vs 'summary' formats return, but the schema defines those options. The only meaningful omission is lack of differentiation from sibling stats tools, which is more a usage-guidance 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?

The input schema covers the single 'format' parameter 100% with an enum, default, and description. The tool description adds nothing about the parameter, so the schema carries the full weight. This aligns with the baseline for high schema coverage.

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 uses a specific verb ('Export') and resource ('collected telemetry metrics'), and the second sentence clarifies what the result is ('anonymized usage statistics'). This clearly distinguishes it from the many baking/recipe tools in the sibling list, though it does not explicitly contrast with the other stats-like tools (e.g., cyberchef_worker_stats, cyberchef_cache_stats).

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 states only what the tool does and gives no guidance about when to use it versus alternatives. There is no mention of scenarios, exclusions, or a preferred sibling for similar telemetry/stats needs, leaving the agent to infer usage from the name alone.

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

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

The description reveals a key behavioral trait beyond the read-only annotations: results are always a ranked list because a single 64-bit integer can validly represent multiple formats. It also enumerates the format coverage, giving the agent realistic expectations about scope and ambiguity.

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 description is compact and front-loaded: it states the core purpose in the first sentence, provides format scope in the second, and explains a non-obvious output guarantee in the third. Every sentence contributes useful information without fluff.

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 output schema, it explains the ranked-list output and why that design is necessary, which is valuable. It does not fully describe the exact shape of each ranked result or the role of the plausible_from/plausible_to window, but the schema covers those parameters and the overall behavior is sufficiently clear.

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 description coverage is 100%, and the schema already documents all four parameters, so the baseline is 3. The description adds little parameter-level detail beyond restating that it accepts a decimal, hex, or v1 UUID, which duplicates the schema's 'value' description.

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 uses a specific verb ('rank') and identifies the resource ('every format it could plausibly be'), making the tool's purpose immediately clear. It also distinguishes itself from CyberChef's date operations by positioning itself as the prerequisite step, which sets it apart from sibling tools.

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 clearly states when to use this tool: before CyberChef's date operations, which require knowing the timestamp format in advance. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough for an agent to infer appropriate usage.

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

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

The description goes far beyond the readOnly/idempotent annotations by revealing the algorithm's internal decision logic: the index of coincidence is a filter, not a judge; multiple key lengths are shortlisted; and trigram scoring makes the final decision. It also discloses failure behavior and measured accuracy ('Exact key in 9 of 10 measured cases, and it reported its own failure on the tenth'), which is valuable transparency.

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 description is front-loaded with the core purpose and then provides dense, useful technical detail without any filler. Every sentence earns its place: purpose, differentiation, algorithm rationale, failure behavior, and measured reliability. It is detailed but still appropriately sized for a complex cryptanalysis tool.

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?

Given no output schema, the description compensates by describing key recovery, per-position runners-up, plaintext scoring, and failure signaling. The schema fully documents inputs and preview behavior. Together, they give an agent enough context to select the tool, set parameters, and interpret the result appropriately.

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 description coverage is 100%, so all four parameters already carry clear meanings. The description adds algorithm-level context about key-length search behavior, but it does not add new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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: 'Recover a Vigenere key from ciphertext alone.' It immediately distinguishes this tool from `Vigenère Decode`, which requires the key, and states that no other operation finds one. This makes the tool's unique role clear even among many sibling tools.

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 explicitly identifies the condition for use — ciphertext-only Vigenere key recovery — and contrasts it with the alternative, `Vigenère Decode`, which cannot be used without a key. It also clarifies the algorithm's intent and what the tool is designed to avoid, giving an agent clear guidance on when this tool is appropriate.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations by specifying the availability condition (ENABLE_WORKERS=true) and detailing the statistics returned.

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 description is a single, information-dense sentence. It front-loads the core purpose and then adds the key availability constraint without any redundant filler.

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 zero-parameter, read-only stats tool, the description is complete: it states what the tool does, what data it returns, and the environment flag required. No additional input or safety context is needed given the rich annotations.

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?

The tool has zero parameters, so the description cannot add parameter meaning beyond the schema. With no parameters, the baseline is 4, and the description appropriately focuses on output scope rather than inputs.

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 uses a specific verb ('Get') and a precise resource ('worker thread pool statistics'), listing the exact data returned. This clearly distinguishes it from sibling stats tools like cache_stats and deprecation_stats.

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 implies when to use this tool: when worker thread pool statistics are needed. It also provides a clear prerequisite and exclusion: the tool is only available when ENABLE_WORKERS=true, signaling not to use it otherwise.

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

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

Beyond the readOnly and idempotent annotations, the description discloses meaningful behavior: it uses three independent statistics, reports disagreements rather than averaging them away, and decrypts. It also provides measured success rates and known limitations, giving an agent realistic expectations about output quality.

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 dense sentences cover function, methodology, output behavior, differentiation, and limitations without wasted words. The core purpose is front-loaded, and every sentence adds information useful for selecting and invoking the tool.

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 complex crypto-analysis tool with no output schema, the description covers method, output behavior, success rates, and limitations. It could be slightly more explicit about the exact shape of the returned candidates and decrypted preview, but the schema's preview_bytes and candidates parameters plus the description's 'reports what each method concluded' make the behavior sufficiently clear.

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?

The input schema has full, detailed descriptions for all six parameters, including encoding options, defaults, and ranges, so the description does not need to restate them. The description adds little parameter-specific meaning, but baseline 3 is appropriate because the schema already carries the documentation burden.

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: 'Recover the key length of a repeating-key XOR' and explains it also scores key bytes against English and decrypts. It clearly differentiates itself by noting CyberChef's XOR Brute Force stops at a two-byte key, positioning this tool for longer keys.

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 useful selection context: CyberChef's XOR Brute Force only handles two-byte keys, implying this tool is for longer repeating-key XOR. It also adds reliability guidance by warning that it is least reliable on short inputs and plaintext with strong periodicity, though it does not explicitly name sibling alternatives or provide a full when-not-to-use list.

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