Skip to main content
Glama
Sign In
adb-mcp

adb-mcp

by iksnerd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

get_app_details

Read an installed app's version name/code and launchable activity, or inspect a local APK's package ID, version and launcher activity without a device.

Instructions

Report an installed app's version name/code and its launchable activity (dumpsys package + resolve-activity) — to confirm what build is installed and find the activity to launch. Pass apk_path instead of package to read a local .apk (package id, version, launcher activity) with no device attached — handy right after gradle_build.

Input Schema

NameRequiredDescriptionDefault
serialNoTarget device serial (adb -s). Optional when exactly one device is attached.
packageNoInstalled application package name (e.g. com.example.app). Required unless apk_path is given.
apk_pathNoLocal path to an .apk to read instead of querying a device: returns its package id, version and launcher activity via aapt2. Needs no device; use it right after a build to get the applicationId.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.24.3
    • addedInput schema / properties / apk_path
      Added value: +{
+  "description": "Local path to an .apk to read instead of querying a device: returns its package id, version and launcher activity via aapt2. Needs no device; use it right after a build to get the applicationId.",
+  "type": "string"
+}
    • changedInput schema / properties / package / description
      Previous value: -"Application package name (e.g. com.example.app)."New value: +"Installed application package name (e.g. com.example.app). Required unless apk_path is given."
    • removedInput schema / required
      Removed value: -[
-  "package"
-]
  2. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the underlying commands, that apk_path needs no attached device, and that serial is only optional when exactly one device is attached. It implies a read-only inspection but never states explicitly that it makes no changes or what happens if the package is not installed.

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?

Front-loaded with the primary action and return values, then the alternate mode in a second clause; no filler sentences. The parenthetical mechanism lists are dense but each earns its place by telling the agent what will run.

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 3-param read tool with no annotations and no output schema, the description covers what is returned (version name/code, launchable activity) and both invocation modes. Remaining gaps — exact response shape and error behavior when the package or apk is missing — are modest but not addressed.

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 the baseline is 3, but the description adds real semantic value: package and apk_path are framed as mutually exclusive modes ('Pass apk_path instead of package'), and the no-device consequence of apk_path is made operational rather than just documented. Only minor redundancy with the schema keeps it from a 5.

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 and resource: reports an installed app's version name/code plus its launchable activity, and names the concrete mechanisms (dumpsys package, resolve-activity, aapt2). It also clearly separates the two modes (device package query vs. local apk_path inspection), so an agent can distinguish it from siblings like list_packages or app_state.

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?

Gives explicit purpose-driven triggers: 'to confirm what build is installed and find the activity to launch', and 'handy right after gradle_build' for the apk_path mode. It does not explicitly name sibling alternatives (e.g. list_packages) or exclusions, so it stops short of full when/when-not routing.

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