mouse_drag

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

With no annotations, the description fully carries the burden. It discloses that both start and end points are guarded, cross-window drags are blocked by default, and mentions the optional lensId for advanced workflows. It also includes the instant speed option (speed=0) and homing correction, providing comprehensive behavioral transparency.

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 concise (4 sentences) and front-loaded with the core action. It uses a clear structure: action, use cases, example, caveats. Every sentence adds value without redundancy.

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?

Given no output schema and 13 parameters, the description provides complete context: it explains the drag action, the required parameters, optional advanced parameters (lensId, allowCrossWindowDrag, allowTabDrag), and behavioral constraints (guarding, blocking cross-window). No gaps remain for an agent to safely invoke the tool.

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?

The description adds meaning beyond schema by explaining the purpose of allowCrossWindowDrag (to confirm intent for cross-window drags) and allowTabDrag (for rearranging tabs). It also contextualizes lensId as 'only for advanced pinned-target workflows'. With 69% schema coverage, the description compensates well for the remaining parameters by giving usage examples and caveats.

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 clearly states the tool does click-and-drag with specific verb+resource ('Click and drag from (startX, startY) to (endX, endY)') and lists example use cases (sliders, drag-and-drop, canvas drawing, window resizing). It distinguishes from siblings by its unique action of dragging, as opposed to mouse_click which only clicks.

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 explicitly states the tool is for dragging actions and provides caveats like 'Left button only' and 'Cross-window and desktop drags are blocked by default', guiding when to use with allowCrossWindowDrag. However, it does not explicitly differentiate from sibling tools like mouse_click, though the context implies it.

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