Recheck

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

With annotations covering only the safety profile (readOnly=false, destructive=false, non-idempotent), the description earns credit by disclosing real failure semantics: the optional tunnel-manager dependency is never required to import, and recheck/live remote dispatch refuse with a named, cause-preserving error rather than raising ImportError. It also flags that host_loss_reconcile always refuses today because no live ResourceScheduler is wired in — a fact an agent could not obtain from annotations or schema.

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?

Reasonably sized but back-loaded: the useful dependency-refusal behavior sits in the middle of a long compound sentence, while the lead is a name restatement. References to internal tickets (RMDD-15, RMDD-08) and RST double-backtick markup cost space without informing an agent.

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 35-parameter tool with zero required parameters, an output schema, and eight implicit sub-operations, the description omits the single most important fact — that operations are selected by which parameters are supplied and that most parameters are ignored per call. The dependency caveats are valuable but do not compensate for the missing dispatch model.

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 100% and every parameter carries its own 'For <operation>:' note in the schema, so the schema does the heavy lifting. The description adds no parameter-level syntax, format, or interaction detail beyond the schema, which is the expected baseline-3 outcome.

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 opening line restates the tool name ('Recheck') and then lists the whole package's domain (remote worker registry, staging, artifact transport) rather than stating what this tool does. Critically, it never discloses that this single tool is a multi-operation dispatcher — its 35 parameters fork into recheck, register_worker, seed_from_inventory, stage_source, verify_source, receive_artifact, dispatch_build and host_loss_reconcile — so an agent cannot infer the actual action from the text.

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 when-to-use guidance, prerequisites, or exclusions appear anywhere. This is severe here because the sibling list contains dedicated tools (rm_remote_workers_stage_source, rm_remote_workers_verify_source, rm_remote_workers_register_worker, rm_remote_workers_receive_artifact, rm_remote_workers_dispatch_build) that duplicate this tool's sub-operations, and the description gives no basis for choosing between the dispatcher and the single-purpose siblings.

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