browser_click_at

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

With no annotations, the description carries the full behavioral burden and over-delivers: pointer event ordering ('Moves the pointer there first (no teleport), then down, then up'), the return value (screenshot after release), a documented silent-failure version caveat for hold_seconds, viewport-relative coordinate semantics, the no-raise stale-coordinate behavior, and a concrete mitigation (take a fresh snapshot).

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 paragraphs, but high information density: the first front-loads purpose, use cases, mechanics, and return value; the third covers the staleness trap and routing. The only somewhat expendable line is the 'floor in pyproject.toml is set accordingly' remark in the version caveat, which reassures rather than instructs; otherwise every sentence earns its place.

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?

Complete for a 3-parameter click tool with several genuine traps. It covers the event sequence, the return value (stated, so no output schema is needed), the version trap, the coordinate-system trap, the silent failure mode, and the mitigation. Nothing an agent needs to invoke this correctly is 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 0% — the schema offers only bare titles ('X', 'Y', 'Hold Seconds') — so the description must compensate, and it does fully. It defines the coordinate reference frame (viewport, not page), what staleness does to a coordinate, and hold_seconds' real semantics plus its version dependency. Both parameters are materially clarified beyond 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?

States a specific verb and resource — 'Click (or press-and-hold) a raw viewport coordinate instead of a selector' — and gives concrete target examples (slider track, canvas-drawn captcha, precise point inside a wider element). It is explicitly framed against the sibling browser_click ('instead of a selector'), so there is no ambiguity about what it does or when it applies.

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?

Explicitly sets the selection condition — 'for targets a selector cannot reliably reach' — and closes with a direct routing instruction: 'prefer browser_click with the element's `selector` whenever it has one.' This is exactly the when-to-use vs alternative guidance the rubric asks for.

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