task_explore

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

No annotations exist, so the description carries full weight. It discloses key behaviors: runs every candidate through the full loop, returns all with acceptance results and provenance, ranks by rule, and documents the timeout behavior (separate process, kill on overrun, returns success False/timed_out True). It stops short of stating side effects or permission needs, but the coverage is strong for a non-annotated tool.

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 tightly written with a clear summary, args, and returns structure. It packs essential distinctions (ranking logic, timeout behavior, task_run comparison) without redundancy. Every sentence contributes.

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 two-parameter tool with an output schema, the description explains the return shape ('{"success", "concept", "candidates": [...]} ranked best-first') and the ranking semantics. It also directs the user to task_plan for spec definition. It is complete enough for an agent to select and invoke without ambiguity, though some details of 'DTS' are delegated.

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?

Context signals show 0% schema description coverage, so parameter meaning depends entirely on the description. It defines spec as 'A DTS dict (see task_plan); alternatives are the branches' and explains timeout_s as a wall-clock cap with process isolation and kill behavior. This adds meaningful semantics beyond the bare type/required info in the schema.

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 opens with a specific verb+resource: 'Explore a branching derivation tree from a DTS.' It clearly identifies the tool's function and distinguishes it from the sibling task_run by noting that task_explore surfaces all candidates ranked best-first, while task_run self-corrects to the first passing branch.

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?

Provides explicit usage guidance via the contrast with task_run: 'Unlike task_run (which self-corrects to the first passing branch), this surfaces the whole space of verified answers.' This tells the agent when to choose this tool (when all candidate branches are needed) over the named alternative. No other exclusions needed.

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