double_click

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

With no annotations, the description must carry the behavioral burden, and it does disclose one important trait: the index must come from the latest snapshot, implying staleness matters. It does not say what happens if the index is stale, whether the element is scrolled into view or waited on before clicking, or how the click is dispatched natively versus the two-click workaround.

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 short sentences, front-loaded with the action and the parameter contract, followed by the usage condition and the mechanism clarification. No filler and nothing important buried.

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?

An output schema exists, so return values need not be explained, and the core invocation contract (index from latest snapshot) is present. Still missing are the second parameter's behavior and any indication of failure modes on stale or missing indices, which matters for an action tool with zero annotations.

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 0%, so `index` and `include_snapshot` both lack descriptions. The description meaningfully supplies the provenance of `index` (from the latest snapshot), which is real added meaning. However, `include_snapshot` is completely unaddressed, leaving a documented default of true with no stated effect.

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 and resource ('Double-click the element') and pins the element identity to the index from the latest snapshot. It also goes beyond the name by explaining that two `click` calls do not fire a `dblclick`, which separates it mechanically from the `click` sibling, though it stops short of an explicit routing rule.

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?

Gives an explicit when-to-use condition ('a control that opens or edits on a double click') plus two concrete examples (a file row, an inline rename), which is enough for an agent to judge applicability. It does not state the inverse case (use `click` for ordinary single-click targets), but the examples carry most of the decision.

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