double_click

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

No annotations are provided, so the description carries the full burden and does so well: it discloses cross-agent rejection with TAB_NOT_OWNED, tab ownership semantics, a configurable concurrency cap (default 8, range 1-64), and detailed return behavior including the change_report structure and truncation handling. This is exactly the behavioral context an agent needs for an unannotated mutation 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?

Front-loaded with purpose and usage before the denser multi-agent and return sections, which is the right ordering. It is somewhat verbose and the 'Returns click confirmation' line is redundant with the later RETURNS block, but each section is purposeful.

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, unannotated, no-output-schema tool, the description covers purpose, usage, ownership/error semantics, and return shape (change_report plus truncation fallback). Nothing an agent needs in order to call it correctly appears to be missing.

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 100%, so the schema already documents all five parameters. The description's note that tab_id should only be passed when the agent owns multiple tabs largely restates the schema's own tab_id description rather than adding new format or syntax meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (double-click) and resource (element), and immediately distinguishes itself from siblings by naming click, select_text_range, and get_dom_snapshot as related-but-different tools. An agent can route between double_click and click without opening either schema.

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?

Explicit 'When to use' clause with concrete scenarios (selecting a word, opening items in file managers, activating edit mode) plus a 'Related' clause naming the alternatives and their distinct roles. When-to-use and when-to-use-something-else are both covered.

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