Skip to main content
Glama
Sign In
wasabi

wasabi

by creep-ltx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Drag with the mouse

amiga_drag

Perform mouse drags from x1,y1 to x2,y2 with optional via points to move icons/files, adjust sliders, resize windows, or select Amiga menu items; the button is released even on errors.

Instructions

Press a mouse button at x1,y1, move through the 'via' points if given, to x2,y2, and release. For drag and drop (icons, files), sliders and scroll bars, resizing, and Amiga menus (right button: hold it over the screen's title bar, drag to the item). The button is always released, even on an error. Coordinates as in amiga_screenshot. For a timed gesture use amiga_input; to pick a menu item by name use amiga_ui_menu.

Input Schema

NameRequiredDescriptionDefault
x1Yesstart x
x2Yesend x
y1Yesstart y
y2Yesend y
viaNopoints to pass through, [[x,y],...]
buttonNoleft (default), right (menus) or middle

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / properties / button / enum
      Added value: +[
+  "left",
+  "right",
+  "middle"
+]
    • addedInput schema / properties / x1 / description
      Added value: +"start x"
    • addedInput schema / properties / x2 / description
      Added value: +"end x"
    • addedInput schema / properties / y1 / description
      Added value: +"start y"
    • addedInput schema / properties / y2 / description
      Added value: +"end y"
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive and closed-world, so the safety profile is known. The description adds one genuinely useful trait beyond that: the button is always released even on error, which prevents an agent from worrying about stuck-button recovery. It says nothing about drag speed/interpolation or what a failed drag returns, so the added context is real but thin.

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?

Three tight sentences: mechanics first, then supported use cases, then alternatives and the coordinate reference. Every clause carries information; nothing is padding or repetition of the title.

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 six-parameter, no-output-schema tool this covers mechanics, use cases, coordinate basis, failure guarantee and alternatives. Remaining gaps are minor: no statement of drag duration/step count for the via path, and no mention of what happens if coordinates fall outside the screen.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents x1/y1/x2/y2, via and the button enum with its default. The description restates button usage and adds the coordinate-frame reference ('as in amiga_screenshot') plus the via-points path concept, but no format or range details beyond the schema, so baseline-plus is appropriate.

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 concrete sequence of actions (press at x1,y1, move through via points, release at x2,y2), which unambiguously identifies a mouse drag operation rather than a click or a timed input. The sibling list contains amiga_ui_click, amiga_mouse and amiga_input, and the description makes clear this is the coordinate-path drag variant.

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

Usage Guidelines5/5

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

Enumerates concrete scenarios: drag and drop of icons/files, sliders and scroll bars, resizing, and Amiga menus with the right-button-title-bar procedure. It also names two alternatives with the conditions that select them (amiga_input for timed gestures, amiga_ui_menu for picking a menu item by name), so an agent can route correctly without guessing.

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

Deploy Server

Other Tools