Skip to main content
Glama
DB-25

arc-control-mcp

Drag

drag

Simulate a real mouse press, move, and release between two selectors or viewport coordinates to operate sliders, sortable lists, canvases, and native HTML5 interactions.

Instructions

Drag with a real mouse: press at the start, move in steps, release at the end. Each end is a selector (its center) or x and y in viewport pixels. Works for sliders, sortable lists, canvases, and native HTML5 drag and drop (reported as nativeDrag true). Needs the DevTools engine. Top-level page only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_xNoEnd x in viewport pixels, instead of to_selector
to_yNoEnd y in viewport pixels, instead of to_selector
stepsNoIntermediate mouse moves between start and end
from_xNoStart x in viewport pixels, instead of from_selector
from_yNoStart y in viewport pixels, instead of from_selector
tab_idNoArc tab id from list_tabs. Omit to use this agent's current tab. A tool that changes a tab will not fall back to the tab the user is looking at, so pass this or call open_url first.
to_nthNoWhich to_selector match to use, 0-based
from_nthNoWhich from_selector match to use, 0-based
to_selectorNoElement to release on. CSS selector, "text=Label", or ref=, role=, label=, placeholder= as in click.
from_selectorNoElement to press on. CSS selector, "text=Label", or ref=, role=, label=, placeholder= as in click.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly=false, idempotent=false, destructive=false, openWorld=true. The description adds real value beyond that: the DevTools-engine requirement, the top-level-page restriction, and the nativeDrag=true return signal for HTML5 drag.

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?

Four tight sentences, front-loaded with the core action, then endpoint format, then use cases and constraints. No filler; every sentence carries information.

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 10-parameter tool with no output schema, the description covers mechanism, endpoint formats, engine prerequisite, and page scope. It does not detail step-count tradeoffs or failure behavior, but annotations and the rich schema fill most remaining gaps.

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 100%, so baseline is 3, but the description clarifies the dual-mode endpoints ('a selector (its center) or x and y in viewport pixels'), explaining the selector-vs-coordinate mutual exclusivity that the schema only implies per-field.

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 (drag) and describes the exact mechanism: press at start, move in steps, release at end. An agent immediately knows this performs a real-mouse drag, distinct from click/hover/trusted_click siblings.

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?

Enumerates concrete use cases (sliders, sortable lists, canvases, native HTML5 drag and drop) and states prerequisites/exclusions: needs the DevTools engine, top-level page only. No explicit 'when-not' or named alternative, but the context is clear.

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