Skip to main content
Glama
st412m

brickproof-adb

by st412m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Manage packages

adb_app
Destructive

Manage Android packages over ADB with dry-run defaults, protected-package checks, network guard, and one-call restore to inspect, launch, stop, disable, uninstall, back up, or restore apps.

Instructions

Package operations with guard rails: inspect, launch, stop, clear, disable, uninstall, back up and restore packages. Use it rather than adb_shell or adb_uninstall for package changes. Every action that changes packages defaults to dry_run=true. A protected set derived from the device (launcher, active IME, installer, WebView provider, role holders, account packages) aborts the whole call on any overlap, and has no override. A network guard refuses disable, uninstall, stop and clear while the package is serving an off-device client, naming the port and the peer. Only force_network=true lifts it; force covers a failed APK backup and nothing else. An account canary between batches rolls a batch back and stops on a drop. Everything applied goes into a snapshot, so action=restore undoes it. mode=uninstall also needs the server option allow_uninstall and a successful APK backup. action=launch also accepts uri and/or intent_action for an intent or deep link; CALL, CALL_PRIVILEGED and CALL_EMERGENCY are refused while allow_shell is false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoaction=list only: case-insensitive substring filter
uriNoaction=launch only: deep-link / intent data URI (am start -d). Its presence, together with intent_action, selects the intent-based launch instead of resolving the package's main activity.
modeNoHow to remove: disable (default) is undone by action=enable or restore; uninstall needs allow_uninstall.
forceNoProceed even if the APK backup failed. Off by default. It does not affect the network guard; see force_network.
scopeNoaction=backup only: what to back up when packages is omitted (default user)
storeNoWhere snapshots and APK backups live: by default the snapshot store (setting store). Another path must be inside file_roots.
actionYeslist/info/protected/state only read. launch/stop/clear act at once (clear defaults to dry_run), stop/clear under the network guard. disable/uninstall/enable/restore default to dry_run.
backupNoPull APKs before removing. Default true for uninstall, false for disable.
canaryNoCheck the account count and the launcher between batches, default true. Turning it off removes the only automatic check for a latent breakage.
extrasNoaction=launch only: intent extras. string -> --es, boolean -> --ez, int32 integer -> --ei, larger integer -> --el; anything else is refused by key name. A JSON-stringified object is accepted too.
filterNoaction=list only, default user
serialNoDevice serial from adb_devices. Optional when exactly one device is connected.
dry_runNoDefault true for state-changing actions. Set false to actually apply.
packagesNoPackage name or array of package names. For action=launch with uri/intent_action, at most one package is accepted (used as -p to narrow the resolver); it is otherwise optional there.
batch_sizeNoPackages per batch between canary checks, default 5, max 25
force_networkNoOverride the network guard for disable, uninstall, stop and clear: act on a package that is currently serving an off-device client. It does NOT override the protected set. Off by default.
intent_actionNoaction=launch only: intent action, default android.intent.action.VIEW when uri is set. Must match [A-Za-z0-9_.]+. See the CALL refusal note above.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the destructiveHint=true annotation: it names the protected set and that overlap aborts the whole call with no override, describes the network guard's refusal message (port and peer), the account canary rollback, snapshot-backed restore, and the allow_uninstall prerequisite. This is exactly the operational risk context an agent needs before a destructive call.

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 a one-line scope statement and then dense, non-redundant sentences about guards and preconditions. The unbroken paragraph of seven dense sentences makes it harder to scan than a short bulleted list would be, but no sentence is 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 a 17-parameter destructive tool with no output schema, it covers the safety model thoroughly (guards, canary, snapshot, uninstall prerequisites). The gap is the read-side actions: list/info/protected/state are only summarized as 'only read', so an agent gets no sense of what state or protected report or what a batch result looks like.

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% and the per-property descriptions are already detailed, so the baseline is 3; the description earns an extra point by disambiguating cross-parameter semantics the schema documents only locally — force covers a failed APK backup 'and nothing else' while force_network lifts only the network guard and never the protected set. It still restates some defaults (dry_run, backup) that the schema already carries.

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 set and resource ('Package operations ... inspect, launch, stop, clear, disable, uninstall, back up and restore') and explicitly distinguishes itself from adb_shell and adb_uninstall. An agent can route package-management calls here without opening a 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?

States the routing decision outright ('Use it rather than adb_shell or adb_uninstall for package changes') and layers per-action guidance (which actions are instant vs dry_run, which fall under the network guard). Alternatives are named and the condition selecting them is given.

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