wbpp_run

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

The description discloses useful runtime behavior: a separate PixInsight instance, fully automated execution, and slowness due to the whole pipeline. However, annotations are all false/neutral and carry no safety or side-effect information, and the description does not say what files it writes, whether it is asynchronous, or what happens to the current session, so some burden remains unmet.

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?

Three sentences pack purpose, tradeoff, and parameter guidance with no filler. Key behavioral cues are front-loaded before the parameter examples.

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 6-parameter, no-output-schema tool with neutral annotations, the description covers what the tool does and roughly how to invoke it, but is silent on return value, async vs blocking behavior, status checking, and side effects on disk. An agent would have to infer these from sibling wbpp_status/job_* tools.

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 only 17%, so the description must compensate. It explains that any WBPP automation parameters can be passed via params and gives three concrete examples, and it maps light_group_id/calibration_group_ids by saying calibration groups are used. It does not explain dirs, files, or output_dir, so compensation is partial.

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+resource: run PixInsight's WeightedBatchPreprocessing in a separate instance on light+calibration groups. It also frames itself as a cross-check and says to compare outputs with image_statistics/measure_stars, so an agent can distinguish it from the many build_master*/pipeline_run siblings.

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?

Opens with 'Cross-check' and says the purpose is to independently compare its master light to ours, which is a clear usage signal for validation rather than production preprocessing. It notes the tool is slow but independent, giving a cost/benefit cue. It does not explicitly say when not to use it or name sibling alternatives, but the context is sufficient.

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