cyberchef_jwt_weakness

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.