动作链(真实鼠标键盘)

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

Annotations only provide readOnlyHint=false. The description adds meaningful behavioral context: it is real input at CDP level (not JS simulation), and the steps schema mentions human-like typing rhythm (30~90ms) when interval is omitted. This goes beyond annotations. It doesn't disclose failure modes or page-focus requirements, but the core behavioral nature is clearly stated.

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 two short sentences plus a compact list of typical usage examples. The purpose is front-loaded, and every sentence adds value. No redundancy or fluff.

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?

The tool is complex (many action types), but the schema covers each action thoroughly. The description adds the key differentiator (real input) and typical sequences. It doesn't mention when to fall back to simpler siblings, which would be useful but is not critical. Given the rich schema, the description is adequate.

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 100% – the steps parameter already documents every action type and its parameters in detail. The description adds semantic guidance on how to combine actions (e.g., 'type 输入文本前先 move_to/click 输入框获得焦点'), which enriches the schema. This goes beyond baseline 3 by providing usage patterns that clarify parameter roles.

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 states a specific verb and resource: '按顺序执行一串真实鼠标/键盘操作' (execute a sequence of real mouse/keyboard operations). It explicitly distinguishes itself from JS simulation ('CDP Input 事件级别，非 JS 模拟'), which differentiates it from sibling tools like element_click or run_js. The typical usage patterns (move_to then click, hold+move+release drag, type after focus) make the purpose concrete.

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?

The description provides clear context of when to use the tool through typical usage examples (drag, focus before typing). However, it does not explicitly name alternatives or state when NOT to use it (e.g., for a single click, element_click might be simpler). The guidance is implied rather than explicit, but the examples give strong situational cues.

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