Drag

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

With no annotations, the description carries the full burden; it does disclose the key behavioral trait that the movement is bezier-jittered rather than a straight teleport, which matters for bot-detection avoidance. It says nothing about timing/duration, intermediate steps, failure behavior if the target element moved, or whether the mouse button is released between the two points.

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?

Two tight lines: capability and differentiator first, use cases second, a runnable example last. Nothing is padded, though the example would earn more space if it clarified the coordinates.

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?

An output schema exists and the example confirms a simple `{"ok":true}` result, so return values need no explanation. For a six-parameter geometry tool with zero schema descriptions and no annotations, though, the description leaves coordinate frame, button selection, and drag duration unaddressed.

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% for all six parameters, so the example is doing real work: `drag('t0', 100, 200, 400, 200)` fixes the positional ordering as tab_id, x1, y1, x2, y2 and shows a start-to-end vector. The `button` parameter is never mentioned, and the coordinate origin (viewport vs page) remains ambiguous.

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 ("mouse drag") and adds a meaningful differentiator ("humanized bezier-jitter"), which separates it from plain coordinate tools like click_at. It stops short of naming the sibling it supersedes, so the agent must infer the drag-vs-click distinction.

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 three use cases (slider captchas, drag-drop UI, range sliders) give implied context for when this tool applies. There is no guidance on when NOT to use it or on the alternative for plain clicks and multi-step interactions, so routing is only partly resolved.

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