bad-ass-mcp

Overview Schema Source Related Servers Discussions Admin

drag

Perform a real pointer drag from a source to a target using screen coordinates or element handles, to reorder lists, move sliders, or reach drop targets that lack accessibility paths.

Instructions

Drag-and-drop with real pointer events: press at the source, move to the target over duration seconds, release.

Give either screen coordinates (from_x/from_y, to_x/to_y, top-left origin in points) or element handles (from_handle/to_handle, from find_elements or get_tree); a handle is resolved to its on-screen center. You can mix: a handle on one end and coordinates on the other.

For drop targets that have no accessibility path, editors that only accept drops from another panel, list reordering, sliders. Delivery is system-global, so both ends must be visible and the window on top.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "drag"
  }
}

Input Schema

Name	Required	Default
`to_x`	No
`to_y`	No
`button`	No	left
`from_x`	No
`from_y`	No
`duration`	No
`to_handle`	No
`from_handle`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that events are real pointer events (not synthetic accessibility actions), that the gesture is timed by duration, and that delivery is system-global, which forces both endpoints to be on-screen and the target window focused. It omits failure behavior (what happens if the drop misses) and whether any confirmation is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core mechanism, then input modes, then use cases, then the visibility constraint — a sensible order with little filler. A few phrases ('press at the source, move to the target over duration seconds, release') partially restate the tool name, but they add the event-level detail that justifies them.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter gesture tool with no annotations and no output schema, the description covers input semantics, timing, and the critical precondition about visibility and z-order. The remaining gaps — the button parameter, return value, and error/retry behavior — are real but secondary to calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with 8 parameters, so the description must compensate, and it largely does: it explains the dual coordinate/handle input model, states that coordinates use a top-left origin in points, that handles resolve to the element's on-screen center, that the two modes may be mixed, and that duration is in seconds. The `button` parameter is never described, leaving one of eight undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus the mechanism: 'Drag-and-drop with real pointer events: press at the source, move to the target over duration seconds, release.' This distinguishes it clearly from click/click_at siblings, which cannot express press-move-release.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use scenarios (drop targets with no accessibility path, editors that only accept drops from another panel, list reordering, sliders) and a hard prerequisite: both ends must be visible and the window on top. It does not explicitly name a fallback alternative such as click_at for cases where both endpoints cannot be made visible, so it falls short of full routing guidance.

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

Deploy Server