Mobilebox

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

With no annotations, the description carries the full behavioral burden. It usefully discloses batch ordering, first-failure stopping, and that results plus the new screen are returned, and it notes close_app is a force-stop. It does not disclose permission requirements, side-effect/irreversibility warnings, or the structure of the returned results.

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?

The description is compact and front-loaded: core batch behavior comes first, followed by action types and target formats. Every clause contributes operational information, and there is no filler.

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?

For a complex batch-action tool with no annotations and no output schema, the description covers the essentials of execution and target selection. It remains incomplete on how refs are obtained, how action results are shaped, and how optional per-action parameters behave.

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 description coverage is 50%, and the nested action schema has no field descriptions. The description compensates by listing action types and the five target shapes, which is meaningful beyond the schema. But it omits semantics for many action-specific fields such as duration_ms, clear, submit, direction, max_swipes, timeout_ms, gone, and package.

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?

The description gives a specific verb and resource: 'Run 1–20 actions in order' and then enumerates every supported action type. This clearly distinguishes the tool as a batch device-action executor rather than an observation tool like observe or screenshot.

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?

The description implies usage by stating it runs 1–20 actions and stops at the first failure, which tells the agent it is for performing device interactions. However, it never explicitly says when to choose this over siblings such as observe, screenshot, or the app-management tools, nor does it state exclusions.

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

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

With no annotations, the description carries the full burden, and it does disclose the two most important traits: the call is blocking until the device is ready, and it returns the first screen. That is genuinely useful given the schema says nothing about latency or readiness. It still omits what happens on failure/timeout, roughly how long provisioning takes, and that the phone will later park itself under idle_timeout — significant gaps for a resource-creating call.

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?

Two short sentences, front-loaded with the action and its blocking nature — no filler. The second sentence is slightly oblique ("its own phone" without saying why isolation matters), but nothing is wasted.

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 are no annotations and no output schema, so the description must cover behavior and return shape; it covers the return shape at a glance ("first screen") but not what readiness means, error modes, or session limits. Parameter documentation is mostly delegated to a well-annotated schema, so the gap is narrowed but the definition is still thin for a provisioning tool with lifecycle side effects.

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 description coverage is 80%, and the schema already explains country semantics, idle_timeout/max_duration defaults, and idempotency replay behavior in detail. The description adds no parameter-level meaning beyond the implicit notion that the new phone is owned by a task or end user. Baseline 3 is appropriate since the schema does the heavy lifting.

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?

"Create a phone, wait until it is ready and return its first screen" gives a specific verb plus resource and even names the lifecycle behavior (blocking until ready) and the return value (first screen). It is clear that this is provisioning, not interaction. However, it never distinguishes itself from the sibling start_phone, so an agent must guess whether create_phone and start_phone are the same operation or different lifecycle stages.

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?

"Give each task or end user its own phone" implies a usage policy (one phone per isolated task/user), which is real guidance about when to call it. But there are no exclusions and no routing to alternatives — notably start_phone, which sounds like it might resume an existing phone, nor any hint that repeated calls should reuse idempotency_key (that lives only in the schema).

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

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

With no annotations, the description must carry the behavioral load. It does disclose the critical trait that all data on the phone is destroyed, which is exactly the kind of context annotations would otherwise provide. However, it does not say whether the operation is irreversible, what permissions are required, or what happens if the phone is currently started or already parked.

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?

Two short sentences with zero filler, and the destructive scope is front-loaded before the redirect to the safer alternative. Nothing could be cut without losing meaning.

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?

For a simple one-parameter tool the description is nearly sufficient, and the data-destruction warning is the most important thing an agent needs. It stops short of stating irreversibility or any precondition, which matters most for an irreversible destructive operation with no annotations.

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?

The schema documents the single phone_id parameter at 100% coverage ("Phone id, ph_…"), so no compensation is needed. The description adds nothing beyond the schema, but the baseline for a fully documented single parameter is high.

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?

"Delete a phone and everything on it" names a specific verb (delete) and resource (phone) and states the blast radius. It is easy to distinguish from non-destructive siblings like list_phones or observe, though the differentiation is carried by the follow-up sentence rather than the purpose statement itself.

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?

"Prefer park_phone" explicitly names the alternative and signals that deletion is the non-default path. What is missing is the condition under which deletion is actually the right call (e.g., decommissioned device) and any prerequisite such as parking or stopping first.

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

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

With no annotations, the description carries the full burden. It usefully discloses that only arm64-v8a/universal APKs are accepted and that only the needed splits are auto-selected from bundles, but it says nothing about whether the call blocks until install completes, what happens to existing app data on an update, or how incompatible ABIs surface as errors.

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?

A single dense sentence, front-loaded with the action and resource, followed by compatibility constraints and then the follow-up call. No filler or redundant restatement of the tool name.

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?

For a three-parameter tool with full schema coverage and no output schema, the description covers the key external facts: accepted formats, ABI constraint, split behavior, and the next step. The remaining gap is failure/blocking behavior on incompatible artifacts, which an agent would benefit from knowing.

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 100%, so the baseline is 3. The description adds some meaning by clarifying that `url` must be a public direct download and by explaining the split-selection behavior tied to `phone_id`, but it never mentions `grant_permissions`, leaving that entirely to the schema.

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?

States a specific verb and resource ('Install or update an app') plus the exact input form ('public download URL') and supported artifact types (APK arm64-v8a/universal, .apks/.xapk). This clearly separates it from list_apps and uninstall_app among the siblings.

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?

Covers both install and update cases and routes the agent to the next step by naming `act` with `{"type":"open_app","package":…}`, which is genuine alternative/sequencing guidance. It stops short of stating when not to use it (e.g. sideloading local files, downgrades) or any prerequisites.

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

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

No annotations are supplied, so the description carries the full burden and provides almost nothing: no indication of return format, whether system apps are included, ordering, pagination, or whether the device must be online/parked. The single clause about user-installed scope is the only behavioral hint.

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?

It is short and front-loaded, so nothing is wasted, but it is a sentence fragment rather than a structured statement of purpose and behavior. Brevity here reflects under-specification more than disciplined editing.

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?

For a simple single-parameter read tool this could be adequate, but with no annotations and no output schema the description is the only source of behavioral information and says nothing about what the call returns. An agent cannot tell whether it gets package names, labels, or versions.

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?

With one parameter at 100% schema description coverage ('Phone id, ph_…'), the schema already does the work; the description's phrase 'on this phone' merely echoes the phone_id concept without adding format or constraints. Baseline 3 applies when the schema fully documents the parameter.

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?

The fragment 'Apps the user installed on this phone' identifies the resource (installed apps) and implies a listing, but never states the verb and reads close to a restatement of the name list_apps. It does add the scope 'user-installed' which hints at excluding system apps, but does not distinguish this from siblings like install_app or list_phones in any explicit way.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g., the phone must exist or be running), and no reference to alternatives such as install_app/uninstall_app or list_phones. The agent must infer the call context entirely from the tool name.

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

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

No annotations are supplied, so the description carries the full disclosure burden. "List" implies a read-only, non-destructive operation and the phrase "this project's" discloses scoping, but nothing is said about whether offline/parked phones are included, what status values look like, ordering, or whether results are paginated.

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?

A single front-loaded sentence with no filler, and the scope constraint appears before the return-value hint. Nothing here could be cut without losing information.

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?

For a zero-parameter listing tool the bar is low, and the description covers what is listed and that status is included. However, with no annotations and no output schema, it leaves the agent guessing about the shape of the returned phone objects and the meaning of "status", which is the one piece of context this tool most needs.

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?

The tool takes zero parameters, so there is no parameter semantics for the description to compensate for. The description's addition of "this project's" correctly signals that scoping is implicit rather than argument-driven.

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?

The description gives a specific verb and resource ("List ... phones") plus a scope ("this project's") and an indication of what is returned ("their status"). This clearly separates it from the mutating siblings create_phone, delete_phone, park_phone, start_phone, and from list_apps, though it doesn't explicitly name any of them.

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?

There is no when-to-use guidance, no mention of alternatives (e.g. list_apps for apps, observe or screenshot for a single device's state), and no prerequisites such as whether a project must already have phones provisioned. The agent must infer that this is the discovery/enumeration call from the verb alone.

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

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

No annotations are supplied, so the description carries the full burden, and it only implies read-only via the word 'Read'. It does not say what the element list represents (accessibility tree vs. OCR), whether indices are stable or reusable as input to act, or anything about latency or failure behavior.

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?

One short sentence with no waste, and the core action is front-loaded. It is efficient but so terse that it borders on under-specification rather than pure conciseness.

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 no annotations, so the description is the only place to explain what a 'numbered element list' looks like and how the numbers relate to the act tool. For a tool at the center of the observe/act loop, that critical context is missing.

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 100% and the single phone_id parameter is documented in the schema as 'Phone id, ph_…'. The description adds no additional meaning, so the baseline of 3 for a fully described schema applies.

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?

States a specific verb+resource ('Read the current screen') and qualifies the return format ('numbered element list'), which implicitly distinguishes it from the sibling screenshot tool. It stops short of naming that alternative, so it is clear but not fully differentiated.

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?

No guidance on when to use observe versus screenshot or act, and no statement of prerequisites or the typical observe-then-act loop. The agent must infer usage entirely from the name and sibling list.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that billing stops, that apps/data/logins persist, and that app state resets on start_phone 'like after a reboot' — a strong mental model for an agent. It omits idempotency (is parking an already-parked phone an error?) and any return/confirmation behavior.

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?

Three short sentences, front-loaded with the core action and effects, then state semantics, then the imperative. No filler or repetition.

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?

For a one-parameter lifecycle tool with no annotations and no output schema, the description covers the essential state model an agent needs (data persists, apps reset). Only the failure/idempotency caveat and confirmation behavior are absent, which is a minor gap.

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 description coverage is 100% and the single phone_id parameter is fully documented in the schema as 'ph_…', so the schema does the heavy lifting. The description adds no additional meaning about the identifier or its format, making the baseline 3 appropriate.

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?

States a specific verb (park) and resource (phone) plus the two concrete effects: shuts down and stops billing. It implicitly distinguishes itself from delete_phone by stating 'Apps, data and logins stay', so an agent can tell park apart from destructive siblings.

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?

'Always park when done' gives an explicit directive for when to call it, and the data-preservation clause signals the boundary against delete_phone. It does not explicitly name delete_phone or start_phone as alternatives, so the routing guidance is clear but not fully enumerated.

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

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

With no annotations, the description carries the full burden; it does disclose the return format (PNG) and that it is a read-style capture. It does not mention latency, size, whether the device must be started/awake, or any failure modes, so transparency is adequate but thin.

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?

A single front-loaded sentence with no filler; the output format and the use case are both stated immediately. Slightly terse rather than overlong.

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?

For a one-parameter, no-output-schema capture tool, saying it returns a PNG and when to prefer it over the element list covers what an agent needs to call it correctly; only operational details (device state, cost) are absent.

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 100% for the single phone_id parameter, so the description adds nothing about parameters; baseline 3 applies.

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?

States the output format (PNG) and the resource (the screen), and implicitly distinguishes itself from the element-list tool (observe) by naming the content type it uniquely captures.

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?

Gives a clear selection rule: use this for content the element list cannot show, with concrete examples (images, maps, games). It does not explicitly name the sibling to prefer otherwise, but the boundary is inferable.

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

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

With no annotations provided, the description carries the full burden and does solid work: it explains proxy routing semantics ('all traffic leaves through it, null = direct'), states persistence across park/start, and warns that changing locale restarts the UI (~15 s). Gaps remain — whether unspecified fields are left unchanged (partial update vs. full replace), auth requirements, and error behavior for malformed values are unstated.

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?

A single front-loaded sentence enumerates the four settable facets with their formats, followed by two short sentences covering persistence and the restart side effect. No filler, and the most operationally important caveat (UI restart) is placed last where it is still visible.

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?

For a 5-parameter mutating tool with a nested object, no annotations, and no output schema, the description covers formats, persistence, routing effect, and a disruptive side effect. It stops short of describing partial-update semantics or what a successful call returns, which an agent would still need to reason about.

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 description coverage is only 20% (just phone_id), so the description must compensate and does: it specifies IANA for timezone, BCP-47 for locale, socks5://user:pass@host:port for proxy with null meaning direct, and identifies location as GPS. It adds little on the lat/lng nested fields, but the schema already supplies their ranges.

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?

The description states a specific verb (set) plus the resources it configures — timezone, locale, GPS location, proxy — and the title/name pair 'set_device' is the only setter among the listed siblings (act, park_phone, start_phone, install_app are all different operations). An agent can tell exactly what this does without any inference.

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?

The description implicitly defines the use case as device-environment configuration and adds context ('kept across park/start') that clarifies it is a persistent setting rather than a transient action. There are no explicit when-not-to-use exclusions, but no sibling overlaps enough to require them.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses that apps and logins persist across the resume, but says nothing about whether this is a billable/state-mutating operation, what error occurs if the phone isn't parked, or how long a resume takes.

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?

Two short sentences, front-loaded with the action and followed by the one piece of behavior worth knowing. Nothing is wasted or padded.

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?

For a one-parameter lifecycle tool with a fully described schema and no output schema, the description covers what it does and the key state-preservation behavior. Only minor gaps remain around preconditions and failure modes.

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 100% and the single phone_id parameter is fully documented in the schema, so the baseline of 3 applies. The description adds only a weak constraint that the id should reference a parked phone, with no format or validation detail beyond the schema.

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?

The description gives a specific verb and resource ("Resume a parked phone") and implicitly distinguishes itself from the sibling park_phone by naming the state it operates on. It falls short of a 5 only because it never names the sibling or the broader lifecycle explicitly.

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?

Usage is implied by the precondition "parked phone" — an agent can infer it should call this only on a parked device. There is no explicit statement of alternatives (e.g., create_phone for a fresh device) or of what happens if the phone is not parked.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the critical trait — that app data is deleted, not just the binary removed — which is the most important warning for a destructive operation. However, it says nothing about irreversibility, whether deletion can be scoped or skipped, required permissions, 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.

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

A single front-loaded sentence with zero filler: the action and its destructive consequence come first. It is terse rather than padded, though that terseness is the same under-specification penalized elsewhere.

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?

For a destructive, two-required-parameter operation with no annotations and no output schema, the description is thin. It omits preconditions, irreversibility, the undocumented 'package' format, and any sense of what the call returns or how failures surface.

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 description coverage is only 50%: phone_id is documented as the 'ph_…' identifier, but 'package' has no description at all and the tool description never clarifies its expected format (e.g., reverse-domain package name) or whether it must match an installed app. The description adds no parameter meaning beyond the schema.

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?

The description pairs a specific verb ('Uninstall') with a specific resource ('an app') and adds the side effect of deleting its data. The verb alone distinguishes it from the sibling install_app and list_apps, though it never names those siblings explicitly.

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?

There is no guidance on when to use this versus install_app or list_apps, no prerequisites (must the app be installed, must the phone be running or parked), and no indication that data deletion is unconditional. The agent must infer all usage context.

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