click_at_xy

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

No annotations are provided, so the description carries full burden. It mentions isTrusted:true (a useful detail about event trust), but doesn't disclose behavioral traits like whether the click is preceded by hover/mousedown/mouseup events, whether visibility is checked, what happens if the coordinates are out of viewport or off-screen, or if scrolling/waits are involved. '完整鼠标点击序列' implies a full sequence but doesn't specify what that sequence includes.

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 extremely short—a single line with an example. It's efficient and front-loaded with the key CDP mechanism and isTrusted info. However, it may be under-specified rather than concise; still, by pure conciseness criteria it earns a good score for zero waste.

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 2-param tool with no output schema and no annotations, the description is thin. It doesn't cover click behavior semantics, coordinate reference frame, failure modes, or relationship to gesture/hover tools. Given the complexity implied by a full CDP mouse event sequence and the absence of annotations, the description is incomplete for safe reliable selection and invocation.

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 description coverage is 0%, so the description must compensate for parameter documentation. The example 'click_at_xy(100, 200)' implies x and y are coordinates, but the description doesn't state coordinate system (viewport vs page vs screen), units (pixels), or validity ranges. With 0% schema coverage, this is a notable gap.

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 'CDP 完整鼠标点击序列 (isTrusted:true)' conveys it performs a complete mouse click sequence via CDP with isTrusted:true, which is specific about the mechanism. However, it's in Chinese and somewhat terse; the verb 'click' is implied by the name rather than explicitly described, but the CDP reference and the (100,200) example clarify it's a coordinate-based click. It doesn't explicitly distinguish from siblings like click_selector, click_text, or click_index, though 'xy' naming plus the example does differentiate coordinates.

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?

No guidance on when to use this tool versus alternatives. It doesn't state when to prefer coordinate-based clicking over click_selector, click_text, or hover. With 7+ click/hover siblings, explicit usage guidance would significantly help the agent, but the description provides none.

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