Generate Chaos Fault Injection Policy

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

The description adds real behavioral context beyond the annotations: it discloses that policies are dynamic, scoped to simulations, and cause specific failures (429, 500, timeout, 401, malformed JSON). However, it never says whether the policy is applied immediately or merely generated, whether faults can be cleared, or whether state persists across runs — notable gaps for a tool whose annotations claim readOnlyHint=true while the verb used is "Configures", which an agent could read as mutation.

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 front-loaded sentence with the target surfaces named before the fault examples. The parenthetical enumeration is dense but each item maps to a real enum value, so there is little wasted wording.

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 and annotations that leave the read-only vs. configure ambiguity unresolved, the description should say what the call returns or whether the fault is live on return, and how to later disable it. It covers the what and where but not the lifecycle, which is the key unknown for a fault-injection 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?

Schema coverage is 100%, so the baseline is 3, and the description goes slightly further by decoding the faultType enum values into plain-language failure modes (rate limits, server errors, timeouts, unauthorized, malformed JSON). It says nothing about targetToolName semantics such as the 'all_tools' wildcard or how failureProbability shapes behavior, so it does not fully earn a 5.

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 ("Configures") and resource ("dynamic chaos injection policies") with concrete target surfaces (tools, mock APIs, databases) and enumerates the fault modes. An agent can tell what it produces; it just doesn't contrast itself with any sibling, though none of the listed siblings appear to overlap in fault injection.

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 "during simulations" implies the context of use, but there is no explicit when-to-use vs when-not guidance, no prerequisites, and no pointer to any alternative or follow-up tool. Usage is inferable only from the simulation framing.

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