Skip to main content
Glama
Sign In
brickproof-adb

brickproof-adb

by st412m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Dump UI hierarchy

adb_ui_dump
Read-onlyIdempotent

Dump Android UI hierarchy as a compact list of interactive and labeled elements with tap coordinates. Mark password fields and use coordinates with adb_tap to target UI elements.

Instructions

Dump the current UI hierarchy (uiautomator) as a compact list of interactive/labeled elements with tap coordinates @(x,y). Password fields are marked [PASSWORD] and listed even with no visible text. Use together with adb_tap. Prefer it over adb_screenshot for labels and tap targets; use adb_screenshot for content the dump does not see (images, video, some WebViews and games).

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": "adb_ui_dump"
  }
}

Input Schema

NameRequiredDescriptionDefault
serialNoDevice serial from adb_devices. Optional when exactly one device is connected.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's added value is the uiautomator source, the coordinate annotation format, and the notable behavior that password fields are marked [PASSWORD] and listed even with no visible text. That last detail is real behavioral disclosure an agent could not infer from structured fields. It doesn't mention output size limits or pagination, so not a 5.

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, zero filler. Capability and output format come first, then the pairing with adb_tap, then the routing rule against adb_screenshot — properly front-loaded.

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 read-only, single-optional-param tool with full annotation coverage, the description supplies everything needed: what it returns, how coordinates are encoded, and how it differs from the screenshot sibling. No output schema is needed because the return format is described in prose.

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% and the single 'serial' parameter is fully documented there, including the 'optional when exactly one device is connected' rule. The description adds nothing about serial, so the baseline 3 is correct.

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 (Dump) and resource (current UI hierarchy via uiautomator) plus the exact output shape: a compact list of interactive/labeled elements with tap coordinates @(x,y). It explicitly distinguishes itself from adb_screenshot, so an agent can choose between them without opening either schema.

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 explicit when-to-use ('Use together with adb_tap', 'Prefer it over adb_screenshot for labels and tap targets') and when-not ('use adb_screenshot for content the dump does not see — images, video, some WebViews and games'). Both the alternative tool and the selecting condition are named.

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