click

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

Annotations are absent, so the description carries the full disclosure burden and discharges it thoroughly. It reveals the three-tier internal execution fallback (element-level do_action → calibrated coordinate click → suggest screenshot), that the return states the effective tier, and the full set of coordinate-click return artifacts: landing evidence, unscaled crosshair snapshot, computed offset from the nearest text block, expect-driven corrective coordinates, and the post-click change percentage as a miss indicator.

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 long, but every clause earns its place given the 0% schema coverage and absent annotations, and it is front-loaded with the core purpose and preferred mode before details. The ①②③ fallback chain, bolded key terms, and arrow/percent framing keep the density structured; the crosshair pixel-mapping passage is valuable but could arguably be tightened.

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 10-parameter tool with no annotations, no schema descriptions, and no output schema, the description supplies everything an agent needs to call it correctly: targeting modes, fallback mechanics, return artifacts, the expect retry loop, and the preview tradeoff. Remaining gaps are minor: role is undocumented, button is underexplained, and the error-return format beyond the effective-tier indicator is not specified.

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?

With 0% schema description coverage, the description compensates strongly: it explains ref (source tools and precedence), text(+app) first-match semantics, x/y as absolute screen coordinates, expect (enables miss-offset plus suggested retry coordinates), preview (toggles the visual feedback payload), and action via the element-level do_action reference. However, role is never mentioned and button's semantics are left entirely to its default value, so coverage of the 10 parameters is strong but not complete.

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 the purpose immediately and specifically: '点击一个元素' (click an element), a clear verb+resource. It then enumerates the three targeting modes (ref, text+app, bare coordinates), and distinguishes itself from siblings by naming get_ui_tree/find_element/get_screen_text as the sources of ref and screenshot as the fallback path, so an agent can tell it apart from the find/read/keyboard siblings.

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 explicit priority ordering: prefer ref, fall back to text(+app) first-match, and use bare x+y only for gray-zone apps lacking an element tree. It also states when not to use the feedback payload (preview=false to save tokens) and when to abandon the tool (both fallback tiers fail → switch to screenshot), which is explicit when/when-not guidance with named alternatives.

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