bisect_signal

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

With no annotations provided, the description carries full disclosure burden. It admirably explains the internal mechanism (checkpoint/restore cycles with watchpoints) and return format ('iteration log and final time range'). However, it omits whether the simulation state is restored to original or left at the found time upon completion, and whether the operation is blocking.

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 front-loaded with the core purpose in the first sentence. Subsequent paragraphs logically flow from mechanism to parameters. Every sentence adds value beyond the structured schema; there is no redundancy or filler. The Args list format is efficient for the missing schema documentation.

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 complex 6-parameter tool with zero annotations, the description adequately covers the operational mechanism, parameter semantics, and return structure (sufficient since output schema exists). Minor gap: it lacks mention of error conditions, permission requirements, or the simulator state post-execution (restored vs. positioned at result).

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?

Given 0% schema description coverage (titles only), the Args section fully compensates by providing semantic meaning for all 6 parameters. It includes critical context like units (nanoseconds), format examples ('8'h11'), hierarchical path guidance ('Full hierarchical signal path'), and default value documentation for precision_ns.

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 pair ('Find when a signal condition...') and precisely defines the scope (temporal binary search). It clearly distinguishes from siblings like get_signal_value (point-in-time) and watch_signal (continuous monitoring) by emphasizing 'automated binary search' over a time range.

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 implies usage through the mechanism explanation ('narrow down the exact time'), but lacks explicit guidance on when to prefer this over alternatives like watch_signal or manual stepping. It does not state prerequisites (e.g., requiring an active simulation) or when-not-to-use conditions.

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