rush_pbt

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a dual import/run behavior but is silent on side effects such as executing property tests, sandbox implications, or the many 'allow_*' permission flags in the schema. The mention of --allow-slow hints at an execution mode but doesn't explain the broader 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 compact sentence with no filler and places the primary action first. It is efficient but the condensed 'or' construction makes the two modes less clear than a short list or separate clauses would.

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 9 parameters, an output schema, and no annotations, the description is far too thin. It omits the mode-selection mechanism, return content, permission flags, and prerequisites, so an agent cannot reliably invoke the tool or understand what will happen.

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%, and the description only references 'local property-test report' and '--allow-slow'. It does not clarify the roles of path, report_path, allow_build, allow_browser, allow_network, allow_download, allow_cache_write, or allow_artifact_write. For a tool with 9 parameters, this leaves most of the invocation semantics undocumented.

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 concrete operation: importing a local property-test report, and an alternative operation: running property tests under --allow-slow. This identifies the tool as focused on property-based testing, which separates it from generic siblings like rush_test and rush_fuzz. However, the dual-mode 'or' phrasing is slightly ambiguous and doesn't make clear how the two modes are selected.

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 on when to use rush_pbt instead of related tools such as rush_fuzz, rush_contract, or rush_test. The description presents two modes without conditions, so an agent cannot infer whether to provide a report path or run tests directly.

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