Skip to main content
Glama
Sign In
brickproof-adb

brickproof-adb

by st412m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Swipe

adb_swipe

Swipe between coordinates or long-press by holding one point on Android over ADB, with optional activity/UI verification to confirm the gesture.

Instructions

Swipe from (x1,y1) to (x2,y2) over duration_ms (default 300). The same point at both ends with duration_ms >= 800 is a long-press. coords and verify work as in adb_tap and both endpoints share one coordinate space; with verify="ui", an "unchanged" result on a swipe usually means the end of a scrollable list. On a TV box without a touchscreen, move the focus with adb_key DPAD_* instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "x1": "<x1>",
      "y1": "<y1>",
      "x2": "<x2>",
      "y2": "<y2>"
    },
    "name": "adb_swipe"
  }
}

Input Schema

NameRequiredDescriptionDefault
x1YesStart X in pixels, in the space chosen by coords.
x2YesEnd X in pixels.
y1YesStart Y in pixels.
y2YesEnd Y in pixels.
coordsNoCoordinate space for BOTH endpoints, default "screen". See adb_tap for the "screenshot" semantics and its 120s TTL.
serialNoDevice serial from adb_devices. Optional when exactly one device is connected.
verifyNoSee adb_tap. For a swipe, "ui" reporting "unchanged" usually means you hit the end of a scrollable list rather than that nothing happened.
duration_msNoDuration in ms, default 300.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare the write/idempotency profile (readOnlyHint=false, idempotentHint=false), so the description's job is to add context, which it does: it explains that verify="ui" returning "unchanged" typically signals the end of a scrollable list rather than a no-op. That result-interpretation guidance is genuinely useful and not derivable from annotations or schema. It stops short of covering failure modes or return shape.

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?

Three dense sentences, front-loaded with the core geometry and timing before the long-press and TV caveats. Slightly reliant on cross-references to adb_tap for coords/verify semantics, which costs a little, but there is no filler.

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 an 8-parameter input-injection tool with no output schema and annotations that only cover the safety profile, the description covers the non-obvious cases an agent would otherwise get wrong: the long-press threshold, shared coordinate space, and the interpretation of a verify="ui" unchanged result. Only the failure/return behavior remains unaddressed.

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 description coverage is 100%, so the baseline is 3, but the description adds real semantic content beyond the schema: the default 300 ms duration, the >= 800 ms long-press threshold rule, and the fact that both endpoints share a single coordinate space. Those are behavioral constraints the schema does not encode.

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?

Opens with a specific verb plus explicit geometry and timing ('Swipe from (x1,y1) to (x2,y2) over duration_ms'), which is unambiguous and clearly distinct from adb_tap, adb_key, and adb_find_and_tap. It also defines the long-press variant, so the agent understands the tool covers more than literal swipes.

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?

Gives concrete when-to-use routing: use adb_key DPAD_* on a TV box without a touchscreen, and use the same-point + duration_ms >= 800 form for a long-press. It also names the sibling whose conventions it inherits (adb_tap for coords and verify), so the agent knows where to look for the shared semantics.

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