generate_adversarial_probes

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

No annotations are provided, so the description carries the full burden. It discloses that it returns up to 100 probes, that they are selected from a curated per-domain library, and that they are not generated from the user's code. However, it does not mention side effects, permissions, rate limits, or whether the operation is read-only. For a generation tool, this is likely safe, but the description leaves these unstated.

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 concise (two sentences) and front-loaded with the primary action and an example. It avoids fluff but could be slightly more explicit about usage context. The structure is clear and scannable.

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 must explain return values, and it does: 'Returns concrete Tier-3 failure scenarios... paired with the invariant... example... Returns up to 100.' However, it does not clarify what constitutes 'affected workflows' or how they are determined, which may be ambiguous without additional context. It also does not specify any prerequisites or error conditions.

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 schema is empty. The description does not need to explain parameters. Per the baseline rule for zero parameters, a score of 4 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: 'Returns concrete Tier-3 failure scenarios for the affected workflows, each paired with the invariant that must hold.' It provides a concrete example and explicitly contrasts itself with code-generated probes ('they name the failure mode rather than the specific call site'), which distinguishes it from sibling analysis 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 implies usage for generating adversarial failure scenarios and clarifies that probes come from a library, but it does not explicitly state when to use this tool over alternatives (e.g., 'use when you need known failure modes' or 'use instead of analyze_workflow'). It does not provide exclusions or alternative tool names.

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