Drag between two points on an Android device using absolute pixel or normalized 0..1000 coordinates. Simulate swipes, scrolls, or drag-and-drop actions with configurable duration.
Drag between two points using absolute pixels or normalized 0..1000 coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| x1 | No | ||
| x2 | No | ||
| y1 | No | ||
| y2 | No | ||
| nx1 | No | ||
| nx2 | No | ||
| ny1 | No | ||
| ny2 | No | ||
| durationMs | No |
Changes observed during successful MCP inspections.
v0.8.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate the mutation risk. It adds the behavioral detail that both absolute and normalized coordinate systems are supported, but it does not disclose gesture mechanics (press-move-release), side effects beyond the annotation, or how normalized coordinates map to the screen.
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?
A single, focused sentence that front-loads the action and resource, then clarifies the coordinate systems. No redundant words or filler; it earns its place.
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 tool with 9 optional parameters, no output schema, and destructive annotations, the description is workable but thin. It omits guidance on choosing between coordinate systems, whether mixing is allowed, and how durationMs relates to the drag behavior. Annotations cover the destructive nature, but an agent would still need to infer several invocation details.
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. It adds meaning by explaining that x/y parameters are absolute pixels and nx/ny parameters are normalized 0..1000 values, which the bare schema does not convey. However, it does not clarify start/end point relationships, whether the two coordinate systems are mutually exclusive, or what durationMs controls.
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 uses a specific verb ('Drag') and resource ('between two points'), and immediately clarifies the two supported coordinate systems (absolute pixels vs normalized 0..1000). This clearly distinguishes it from sibling gesture tools like swipe, tap, long_press, and pinch.
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 gives no guidance on when to use this tool instead of alternatives such as android_swipe, android_scroll, or android_long_press. It does not state whether drag is preferred for particular UI interactions, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.