rush_mutation

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the operation mode. It does not reveal side effects, whether the import modifies state, which permissions are needed, or what the many allow_* flags gate. The mention of --allow-slow hints that this can be a slow operation, but most behavioral impact is undisclosed.

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 repetition. Minor deduction because the phrase 'under --allow-slow' is slightly awkward and consumes space that could otherwise clarify the two operational modes.

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 10-parameter tool with zero schema descriptions and no annotations, this description is too thin. It covers the high-level purpose but omits the role of the required options parameter, the permission flags, and when the import mode vs. run mode should be chosen. The presence of an output schema reduces the need to document returns, but not the need for invocation guidance.

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 0%, so the description must compensate; it only sheds light on report_path (local mutation report) and allow_slow (the --allow-slow condition). The required path and options, plus the allow_build, allow_browser, allow_network, and write-related boolean flags, are left entirely unexplained.

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 two concrete behaviors — importing a local mutation report and running mutation testing — with a clear resource (mutation report) and condition (--allow-slow). This is specific enough to distinguish rush_mutation from its many siblings, none of which target mutation testing.

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 the tool is relevant: either ingest an existing mutation report or execute mutation testing when slow execution is permitted. It does not explicitly name alternatives or exclusion criteria, but the two-mode distinction is enough to guide selection among siblings.

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