Skip to main content
Glama

wpf_drag

Simulate a real OS mouse drag between WPF elements by pressing, moving, and releasing using handles, AutomationIds, or coordinate deltas for state-changing UI automation.

Instructions

Drag using the real OS mouse: press, move gradually, release. Supply a source handle or automation_id and either target_handle, target_automation_id OR delta_x/delta_y (omitted delta axis is zero). target_root_handle scopes destination ID lookup independently of the source root_handle. start_x/start_y and target_x/target_y are optional coordinate pairs measured from the corresponding element's top-left in WPF DIPs; default is its center. Deltas are in the source element's local DIPs, including its transforms. button: left/right/middle. duration_ms: 100-10000, default 500. Brings the source window forward and moves the cursor. Both endpoints must be visible and unobstructed; no scrolling during the drag. Success reports input delivery, not drop acceptance: verify properties or a screenshot afterwards. STATE-CHANGING. Target by exactly one of element_handle or automation_id (exact, case-sensitive AutomationProperties.AutomationId). Use root_handle with automation_id to scope lookup; missing or duplicate IDs fail before input.

Input Schema

NameRequiredDescriptionDefault
buttonNoleft
delta_xNo
delta_yNo
start_xNo
start_yNo
target_xNo
target_yNo
duration_msNo
root_handleNo
automation_idNo
target_handleNo
element_handleNo
target_root_handleNo
target_automation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.17.2
    • addedInput schema / properties / automation_id
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / element_handle / default
      Added value: +null
    • addedInput schema / properties / root_handle
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / target_automation_id
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • addedInput schema / properties / target_root_handle
      Added value: +{
      +  "default": null,
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "element_handle"
      -]
  2. Addedv0.12.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that this is STATE-CHANGING, brings the source window forward, moves the cursor, requires visible unobstructed endpoints, prohibits scrolling, and fails before input on missing or duplicate IDs. It also gives an important post-condition warning that success reports input delivery, not drop acceptance, and recommends verifying afterward.

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

Conciseness5/5

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

Although long, the length is justified by the 14 undocumented parameters and the lack of annotations. The core action is front-loaded, and the remaining clauses each add necessary targeting, coordinate, side-effect, or verification information without redundant filler.

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

Completeness5/5

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

For a 14-parameter, state-changing input tool with no annotations and no output schema, the description is complete. It explains prerequisites, targeting rules, coordinate systems, side effects, failure conditions, and a post-call verification strategy, leaving little an agent would need to infer before invoking it safely.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all 14 parameters, and it largely does. It covers source versus target targeting, element handles versus automation IDs, target_root_handle scoping, coordinate pairs measured from top-left in WPF DIPs with center default, delta units in source local DIPs including transforms, button choices, and duration_ms range/default.

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?

The description opens with a specific verb and mechanism: 'Drag using the real OS mouse: press, move gradually, release.' It clearly distinguishes this as a real-input drag operation rather than a synthetic property change or touch gesture, and the subsequent sentences sharpen the scope with source/target selection and coordinate semantics.

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?

The description gives strong conditions for use: supply a source and either a target element/ID or deltas, ensure both endpoints are visible and unobstructed, and do not scroll during the drag. It also states this is state-changing and that success only means input delivery, not drop acceptance. It falls short of explicitly naming sibling alternatives like wpf_move_mouse, wpf_click_element, or wpf_touch_gesture, so it is not a full 5.

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