Skip to main content
Glama

Uninstall Android package

adb_uninstall
Destructive

Uninstall an Android package from a device, with the option to retain its data. Specify the package name to remove apps cleanly.

Instructions

Uninstall an Android package, optionally retaining its data.

Input Schema

NameRequiredDescriptionDefault
serialNo
deviceIdNo
keepDataNo
timeoutMsNo
deviceNameNo
packageNameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description usefully adds that package data can be retained, which is real behavioral context beyond the annotations, but it never says what is actually removed, whether the uninstall is reversible, or what happens on failure.

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?

A single front-loaded sentence with zero filler. The core action leads and the one behavioral caveat follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-device tool with six undocumented parameters and no output schema, the description is too thin: it omits device selection semantics, timeout behavior, and failure/return expectations. Annotations cover the safety profile, but the invocation-relevant gaps remain.

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

Parameters2/5

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

Schema description coverage is 0% across 6 parameters, so the description carries the full burden and largely fails it. It alludes to the keepData option ('retaining its data') without naming it, and says nothing about serial, deviceId, deviceName, or timeoutMs, leaving device targeting and timeouts undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Uninstall an Android package'), which clearly separates it from adb_install, adb_packages, and adb_app. It does not explicitly name or contrast a sibling tool, so it stops short of a 5.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites (e.g., whether the device must be connected/selected), and no alternatives named. The only conditional hint is 'optionally retaining its data', which is a capability note rather than usage guidance.

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