apps

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

Annotations already flag destructiveHint=true and non-idempotent, and the description goes well beyond them: stop loses no data and the app restarts when opened, clear deletes all data, uninstall of a system app only hides it for the user, restore needs the full package name, and install from PC refuses sensitive folders and preserves data as an update. Sensitive-folder refusal and system-app hiding are non-obvious behaviors that a schema could never convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Written as tight action:meaning fragments with zero filler, and the destructive-action confirmation rule is stated where it matters. The telegraphic run-on style ('Phone apps. info: ... stop: ...') is efficient but slightly harder to parse than a short bulleted form.

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

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

There is no output schema, and the description compensates by saying what info reports (version, install/update dates, source, enabled). Combined with the safety exclusions and the destructive-action rules, an agent has enough to call it correctly, though nothing is said about failure modes beyond refused folders.

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

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

Schema coverage is 0%, so the description carries the full burden and does: app is 'package or part of its name', path is an .apk from the PC with sensitive folders refused, and confirm=true is required for clear/uninstall/install. Every one of the four parameters gains meaning beyond its schema entry.

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

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

Each action is given a specific meaning (info/stop/clear/uninstall/install), so the agent knows exactly what the tool does per action. It is weaker on sibling differentiation: it references 'launch' for the app selector but never distinguishes itself from nearby tools like act or settings, which also touch device state.

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

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

It states explicit preconditions ('confirm=true, only on the user's explicit order') and hard exclusions: never for system parts (phone, interface, Settings, store, keyboard, Google services) and never clear/uninstall of banking, payment and identity apps. This is exactly the when/when-not guidance an agent needs before a destructive call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.