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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds material context the annotations do not: the context string is transmitted to external developers, and therefore must not contain PII, secrets, or credentials. It still does not say what comes back or how/when the request is fulfilled, which keeps it short of a 5.

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 sentences, all load-bearing: trigger, exclusions, and privacy constraint. The gating condition is front-loaded with 'Only call this when...', so the agent sees the routing rule first.

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 meta tool with annotations and no output schema, the description covers when to use it, when not to, and what is safe to send. The only gap is what the call returns or how the request is fulfilled, which a description of this kind could reasonably mention.

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, but the description meaningfully constrains the single parameter beyond the schema by prohibiting private information in it. That is a real usage rule for 'context', not a restatement of the field description.

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 establishes this as a fallback meta-tool whose input is forwarded to the mobile-mcp developers, which lets an agent infer that it requests capabilities not currently exposed. However, it never states the action plainly (e.g. 'request additional tools'), leaving the verb to inference. It is clearly distinguishable from every sibling, which all operate on a device rather than requesting new capability.

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 gives an explicit trigger ('only call this when none of the other tools can do what you need on a mobile device') plus two explicit exclusions ('do not call it for tasks unrelated to mobile', 'or when another tool already covers the task'). This is exactly the when/when-not/alternative structure that a fallback tool needs.

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?

The annotations only establish that this is a non-read-only, open-world, non-destructive operation; the description adds the consequential context the agent actually needs: the device is shared and billed, allocation borrows it for the session only, it must not be triggered silently, authentication may fail and require a prior login call, and released devices lose their state. That is far beyond what the structured fields disclose.

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?

Front-loaded with the core action, then prerequisites, then cleanup guidance. Every sentence carries operational weight, though the run of imperatives (list first, release after, don't reallocate) makes it longer than strictly necessary for a single call.

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 stateful, billable, prerequisite-gated operation with six parameters but no output schema, the description covers the essential agent-facing facts: what is returned (a device identifier), what must precede it, how to handle auth failure, how to pick valid filter values, and how and when to tear down. Nothing needed to call it correctly 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 description coverage is 100% and each parameter (name prefix matching, version comparison prefixes, wait/timeoutSeconds semantics, platform enum) is documented in-schema, so the baseline is 3. The description adds only the workflow hint that filters should be chosen against fleet contents verified via mobile_list_remote_devices, not new syntax or meaning for the parameters themselves.

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 precise verb and resource ('Reserve a physical device from the remote cloud fleet for exclusive use') and immediately distinguishes the target from local devices, which the sibling tool mobile_list_available_devices covers. It also names the returned artifact (device identifier) and the tool family that consumes it, so it is uniquely identifiable among the mobile_* 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?

Explicit when-to-use and when-not clauses: never call silently, only offer a remote device if no local device is available, and only call after the user agrees. It names the prerequisite (mobile_login_to_cloud_provider), a pre-filtering step (mobile_list_remote_devices), a failure recovery path (call login then retry), and the release counterpart with an explicit warning not to release/reallocate mid-task.

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?

Annotations cover the safety profile (destructiveHint=true, openWorldHint=true), and the description adds real behavioral context beyond them: the device argument propagates to every step unless a step overrides it, and the enumerated allowlist bounds what steps may run. It does not, however, warn that steps can be destructive or describe partial-failure semantics.

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?

Purpose and usage are front-loaded in two tight sentences, but the third sentence is an unstructured 30-item run-on list of tool names that dominates the description's length. It earns some of its place as a constraint, but not in prose 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?

For a multi-step orchestrator with no output schema, the description plus schema explains how to compose calls and how device/stopOnError/listElementsAtEnd behave. The main missing piece is what the response looks like when several steps run, which an agent consuming results would want.

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, but the description adds a rule absent from the schema: the top-level device is applied to every step unless a step supplies its own. The step-name allowlist is repeated from the schema's own description, so the marginal gain is moderate rather than large.

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 ('run multiple tools in sequence in a single call') and immediately gives a concrete example flow ('click, type, click, type'). It is unmistakably an orchestration meta-tool, distinct from every sibling it names.

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?

'Use this to fill forms or perform multi-step flows without round-trips' gives clear selection context and the implicit alternative (calling tools individually). It stops short of explicit when-not conditions, e.g. when a single call is preferable.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the freshness constraint that refs come from the latest list_elements result, but says nothing about failure behavior, coordinate origins, or what happens if neither x,y nor ref resolve.

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 immediately followed by the ref-vs-coordinates preference. 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 4-parameter, no-output-schema action tool, the description plus fully documented schema cover what an agent needs to invoke it correctly. Only minor gaps remain around the coordinate system 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%, so x, y, ref and device are all already documented, including the ref-over-x,y precedence. The description reinforces the mutual exclusivity and the provenance of ref, which is mild added value over the structured fields, so baseline 3 fits.

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 (click) and resource (screen) with two distinct modes: coordinates or element ref. It is clear and self-contained, but does not explicitly contrast itself with near siblings such as mobile_double_tap_on_screen or mobile_long_press_on_screen_at_coordinates.

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: 'Prefer ref when the element is listed,' and points to mobile_list_elements_on_screen as the source of refs. It stops short of stating when coordinates are mandatory (e.g. unlisted/custom targets) or what to do when no ref exists.

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?

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description is consistent with that (it can mutate, and 'replace' clarifies the write is an overwrite, not an append). It does not say what the read mode returns or whether the prior clipboard content is recoverable, so it adds only moderate value beyond the annotations.

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 sentences, no filler, with the read/write rule front-loaded immediately after the purpose statement. Every clause earns its place.

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?

With only two parameters and full schema coverage, the description covers what an agent needs to call the tool. The one gap is the return behavior in read mode, which is not described and there is no output schema to compensate.

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%, so both parameters are already documented, including the omit-to-read semantics for 'text' and the pointer to mobile_list_available_devices for 'device'. The description restates rather than extends this, so the 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?

The description names a specific resource (the device clipboard) and both verbs it supports (read or replace), which is exactly the dual-mode behavior an agent needs to recognize. No sibling tool touches the clipboard, so no differentiation is required.

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 explicitly states the selection rule between the two modes: 'Pass text to set the clipboard, omit it to read the current clipboard.' That is clear operational context, though it names no alternatives or preconditions (e.g. device availability).

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?

Annotations already declare this is a non-readOnly, non-destructive, open-world interaction, so the safety profile is covered. The description adds the ref-vs-coordinate targeting distinction but discloses nothing further about effects (e.g. gestures that may zoom or trigger app behavior), rate limits, or permission needs. Adds marginal behavioral value over the annotations.

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 tight sentences with the action and both targeting modes front-loaded, followed by the preference rule. 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 simple interaction tool with full annotations and 100% schema coverage, the description covers both invocation paths and the ref source. No output schema exists, but a tap returns no meaningful payload, so nothing important is missing; only explicit prerequisites (e.g. device enumeration) are left to the schema.

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 goes beyond the schema by naming the ref source ("from the latest mobile_list_elements_on_screen result") and giving the "@e5" format example, plus the preference rule, which helps the agent construct ref values correctly.

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 (double-tap on the screen) and spells out the two targeting modes. The action verb distinguishes it cleanly from siblings like mobile_click_on_screen_at_coordinates and mobile_long_press_on_screen_at_coordinates without needing to open their schemas.

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?

Provides an explicit selection rule between the two parameter modes: "Prefer ref when the element is listed." It does not explicitly route the agent away from single-click or long-press alternatives, but the action verb makes that implied. Clear context with no exclusions stated.

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?

Annotations already disclose that this is a non-read-only, non-destructive, closed-world operation, so the description need not repeat the safety profile. It adds useful context about foldable device types and the posture/angle input requirement, but stops short of describing failure modes, prerequisites such as device allocation, or the effect on device state beyond the fold itself.

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 sentences, front-loaded with the operation and followed by the key input constraint. The examples and instruction all earn their place without redundancy.

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?

Given the low complexity, rich parameter schema, and annotations covering the mutation profile, the description supplies enough context to call the tool correctly. It could be slightly stronger by clarifying whether one of posture/angle is mandatory, but the schema and description together cover the essentials.

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 schema already documents all three parameters in detail. The description adds a meaningful constraint not encoded in the required list: the caller must provide either posture or angle, which helps resolve the otherwise ambiguous optional parameters.

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 pair (fold/unfold) and resource (foldable device), with examples that make the scope immediately clear. It is distinguishable from siblings like mobile_set_orientation because it targets foldable hardware and hinge posture/angle rather than general screen orientation.

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 provides clear context by naming the device class (foldable simulators/emulators) and instructs the caller to provide either posture or angle. It does not explicitly name an alternative tool or state when not to use it, but the context is sufficient to guide selection.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered without description help. The description adds the 'full content' nuance (as opposed to the summary implied by listing), but says nothing about report size, permissions, or whether content can be truncated.

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, zero filler, with the core action front-loaded and the dependency stated second. Every clause earns its place.

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 two-parameter read with no output schema, the description plus annotations give enough to invoke correctly, and 'full content' hints at the return payload. It stops short of describing the report's form (structured vs raw text), leaving 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%, so both 'id' and 'device' are already documented in the schema. The phrase 'by its ID' only echoes the schema's id description, adding no new syntax or format detail, so the 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?

The description states a specific verb and resource ('Get the full content of a crash report') and scopes it by ID, which cleanly separates it from the sibling mobile_list_crashes that enumerates crash IDs. An agent can tell the two apart without opening either schema.

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 names the prerequisite path explicitly: 'Use mobile_list_crashes to find available crash IDs.' That tells the agent both when to call this tool (once an ID is known) and where to get the input, mirroring the routing pattern of well-scored definitions.

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?

Annotations only declare readOnlyHint and openWorldHint, but the description adds substantial behavioral detail beyond them: only post-call logs are captured, termination on limit or 30s of silence, stack-trace lines counting as separate entries, and the saveTo side effect where only the entry count is returned.

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?

Front-loads what the tool captures, then the timing constraint, then termination behavior, then practical guidance. Six tight sentences with 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?

Even without an output schema, the description explains the return shape (one JSON object per line, or only an entry count with saveTo), which an agent needs to interpret results. Nothing required for correct invocation 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%, so the baseline is 3, but the description adds real value beyond the schema: practical guidance on limit sizing (20-50), the consequence of saveTo (file written, only count returned), and filter-by-process/tag noise avoidance.

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 ('Collect live device logs') and even names the platform-specific mechanisms (logcat, unified log). It is clearly distinguishable from siblings like mobile_get_crash and mobile_list_crashes by being a live-streaming capture tool.

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 actionable context: trigger the behavior right before/during the call, start with a small limit (20-50), filter by process or tag, and use saveTo for large captures. It does not explicitly name an alternative sibling tool or state when-not to use it, keeping it just short of a 5.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the platform-specific nature of the return value (activity class vs. view controller class) and its availability caveat ('when available').

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 sentences, zero filler, and the core purpose is front-loaded before the usage guidance. Every clause earns its place by contributing either scope or platform behavior.

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, but the description compensates by describing what the call returns and noting it may be unavailable in some cases. For a single-argument read tool with annotations, nothing an agent needs to call it correctly 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 'device' parameter is fully documented in the schema, including the pointer to mobile_list_available_devices. The description adds no additional parameter meaning, so the baseline 3 is 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?

Specific verb + resource ('Get the app currently in the foreground'), plus a precise statement of the returned payload (focused activity class on Android, view controller class on iOS). This cleanly distinguishes it from siblings like mobile_list_apps and mobile_list_elements_on_screen.

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?

Explicitly states the use case: verify which app or screen you are on before interacting with it, which is actionable context. It stops short of naming an alternative tool or a when-not-to-use condition, so it falls just short of a 5.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds no behavioral context such as what orientation values are returned or whether it reflects device vs app orientation, so it contributes little beyond the annotations.

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. It is exactly as long as it needs to be for a simple read tool.

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 read-only tool with no output schema, the description omits any indication of the return form (e.g., portrait/landscape values). An agent knows what to call but not what to expect back, leaving a small but real 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 device parameter is fully documented, including a pointer to mobile_list_available_devices. The description adds no parameter detail, so the baseline 3 for schema-covered parameters is 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?

The description states a specific verb+resource ('Get the current screen orientation') clearly. It is distinguishable from the opposite-direction sibling mobile_set_orientation by the read verb, though it never names or contrasts with that sibling explicitly, 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.

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as mobile_set_orientation or mobile_get_screen_size. The read verb only implies the use case, leaving the agent to infer everything.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, capping the need for safety disclosure. The description adds the output unit (pixels) and scope ('mobile device'), but says nothing about return format, orientation caveats, or whether values change with rotation.

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 waste. The unit, which is the most important qualifier, is placed at the end where it naturally qualifies 'size'.

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 read-only tool with full schema coverage and annotations, the definition is sufficient to invoke correctly. The only missing piece is whether the returned size is in physical or logical pixels and whether it reflects current orientation.

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 device parameter is fully documented (including a pointer to mobile_list_available_devices). The description adds no parameter meaning beyond the schema baseline.

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 (Get) and resource (screen size) with the unit ('in pixels'), distinguishing it from siblings like mobile_get_orientation. An agent knows exactly what this returns without checking the schema.

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 when-to-use guidance, no mention of prerequisites, and no reference to alternatives. The schema's device description points to mobile_list_available_devices, but the prose itself offers nothing about when this tool is appropriate.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context of its own: it does not say the device must be booted, whether it overwrites an existing install, how long the operation takes, 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 clause with no filler, and the verb+resource lead makes it front-loaded. It is efficient but so terse that it reads as under-specified rather than deliberately minimal.

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?

The tool is simple (2 required params, no output schema) and the schema plus annotations cover safety and parameter details, so an agent can invoke it. Still, the description omits any mention of device readiness or platform-specific install behavior that a caller would want before running it.

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%, so the schema already documents both parameters in detail, including per-platform file formats for 'path' and the device-listing hint for 'device'. The description adds nothing beyond the schema, which is the expected baseline of 3 when structured fields do 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?

States a specific verb (Install) and resource (app on mobile device), which is enough to distinguish it from siblings like mobile_uninstall_app and mobile_launch_app. It does not, however, explicitly name or contrast those 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?

No guidance on when to use this versus alternatives such as mobile_launch_app or mobile_uninstall_app, and no prerequisites stated (e.g., device must be running/allocated). The only useful routing hint, listing available devices, lives in the schema rather than the description.

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?

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description only needs supplementary context. It adds the discovery path for package names but says nothing about what happens if the app is not installed, whether the app is foregrounded, or any latency/state effects of launching.

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, action stated first, followed by usage and the prerequisite lookup. Every sentence carries information with 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?

There is no output schema, so return behavior is not required, and the description covers the core action and how to source the required packageName. It omits failure/edge-case behavior (invalid package, unavailable device), leaving minor gaps for a simple action tool.

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%, so all three parameters (device, locale, packageName) are documented in the schema itself. The description's pointer to mobile_list_apps for the package name adds marginal value but no syntax, format, or constraint detail beyond the schema, matching the baseline for fully-covered params.

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 ('Launch') and resource ('an app on mobile device'), which cleanly separates it from siblings such as mobile_terminate_app, mobile_install_app, and mobile_open_url. An agent can identify the tool's action without opening the schema.

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?

'Use this to open a specific app' gives clear positive usage context and explicitly routes the agent to mobile_list_apps for obtaining the package name. It stops short of naming when-not-to-use cases (e.g., opening a URL vs. launching an app, or batching), so it falls short of a full 5.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no note about return format, filtering, or whether system/user apps are included, which would have been the value-add for a listing tool.

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, front-loaded sentence with no wasted words. It is efficient, though so terse that it omits the scoping detail (user vs system apps) that would make it more actionable.

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 trivial read-only listing tool with no output schema and a fully documented single parameter, this is minimally adequate. It omits what the listing contains (package names, labels) and there are no annotations-independent behavioral notes, leaving a small but real 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?

Single parameter with 100% schema description coverage, so the schema fully documents 'device' including how to discover valid identifiers. The description adds no parameter meaning beyond the schema, 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 (List) and resource (installed apps), scoped to 'on the device'. It is clearly distinguishable from sibling list/get tools like mobile_get_foreground_app or mobile_list_remote_devices by the word 'installed', though it does not explicitly name an alternative.

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 gives no when-to-use guidance, prerequisites, or alternatives. The only routing hint ('Use mobile_list_available_devices to find which devices are available') lives in the schema's parameter description, not the description itself.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds real context beyond that: the devices are local, already connected, cost nothing, and include both emulators/simulators and physical Android/iOS hardware. It does not describe the return shape (e.g. device IDs or ordering), which keeps it short of a 5.

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?

Four tight sentences with the core capability front-loaded and the alternative routing placed last. Every sentence carries distinct information (scope, device types, platforms, locality/cost, alternative).

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, read-only listing tool with no output schema, the description covers scope, platform coverage, locality, cost, and the sibling alternative. Nothing required to call it correctly is 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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter behavior an agent could misconstrue. No parameter-level detail is needed or missing.

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 precise verb+resource (list available devices) and immediately scopes it to local physical devices plus simulators/emulators across Android and iOS. It explicitly distinguishes itself from the similarly named sibling mobile_list_remote_devices, so an agent can route without opening either schema.

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 an explicit when-to-use (local devices 'ready to use immediately at no cost') and an explicit when-not plus the named alternative ('for devices from the shared remote cloud fleet, use mobile_list_remote_devices instead'). This is the routing information an agent needs.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and environment scope are covered by structured data. The description adds no behavioral context beyond the annotation payload -- nothing about whether reports persist, how many are returned, or whether the device must be active.

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 tight sentence that is front-loaded and wastes no words. It is concise, though arguably too terse for the information an agent needs.

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?

With no output schema, the description should describe what a crash report contains (bundle id, timestamp, stack trace?) and whether results are paginated or limited. Neither is present, so an agent cannot anticipate the return shape from this definition alone.

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 'device' parameter already documents itself, including the pointer to mobile_list_available_devices. Per the high-coverage baseline this sits at 3; the description adds no format or discovery 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?

States a specific verb ('List') and resource ('crash reports') with device scope, which cleanly separates it from the singular mobile_get_crash sibling. It doesn't explicitly name that sibling or explain the distinction, but the list-vs-get contrast is reasonably inferable.

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 indication of when to use this tool versus alternatives such as mobile_get_crash (fetch one report) or mobile_get_device_logs. The only contextual pointer lives in the parameter schema, not the description.

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?

Annotations declare readOnlyHint and openWorldHint, so the safety profile is already covered. The description adds genuinely new behavior: refs and coordinates are screen-state-scoped and become stale after navigation or layout change, which is critical for correctly chaining calls. It doesn't mention output volume or pagination, keeping it short of a 5.

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 tight sentences with zero filler: purpose and return shape first, then consumer routing, then the staleness rule. Front-loaded and every sentence earns its place.

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, but the description itself enumerates what is returned (ref, coordinates, display text/accessibility label) and how to consume it. For a two-parameter read tool with full schema coverage and annotations, nothing an agent needs to call it correctly 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 description coverage is 100% and both parameters (device, format with its text/json enum) are fully documented in the schema. The description adds no parameter-level detail, so the 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 a specific verb and resource ('List elements on screen') and immediately names the returned fields: ref, coordinates, display text/accessibility label. That lets an agent distinguish this discovery tool from the sibling action tools without opening the schema.

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?

Explicitly routes the output to three named consumers (mobile_click_on_screen_at_coordinates, mobile_double_tap_on_screen, mobile_long_press_on_screen_at_coordinates) and gives a lifecycle rule: refs stay valid until the screen changes, so re-list only after navigation or layout change. There is no explicit when-not clause, but the conditions that select this tool are clear.

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?

Annotations only declare readOnlyHint and openWorldHint; the description adds meaningfully more: devices are unusable until reserved, reservation may be a limited/billed resource, and cloud login must have run first with a retry path on auth failure. This is exactly the beyond-annotation context the dimension rewards.

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?

Front-loads what is listed, then contrast, then prerequisites/cost and error handling. Multi-sentence but every sentence carries routing, dependency, or cost information with 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?

With no params, no output schema, and only two annotations, the description supplies the full operational picture: workflow position (login -> list -> allocate), cost/availability caveat, and the difference from the local-device sibling. Nothing an agent needs to call it correctly 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering/arguments are needed.

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 ('List the catalog of device models ... from the remote cloud device fleet') and explicitly distinguishes itself from mobile_list_available_devices by contrasting cloud fleet vs local connected devices. An agent can pick between the two without opening schemas.

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 explicit when-to-use (reservable cloud fleet) vs when-not (local devices via mobile_list_available_devices), plus the required prerequisite (mobile_login_to_cloud_provider) and the follow-up action (mobile_allocate_remote_device). Failure handling for auth errors is spelled out.

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?

Annotations only cover readOnly/openWorld/destructive; the description adds substantial non-obvious behavior beyond that: it is async (returns a URL and code immediately without waiting), background login continues, it interrupts the user, and the agent must relay the URL/code verbatim. This is the kind of behavioral context annotations cannot express.

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?

Front-loads the core purpose, then the usage trigger, then the interactive behavior, then the caution. It is somewhat long, but every sentence carries actionable content (async semantics, verbatim relay, speculative-call warning), so little 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?

For a zero-param, no-output-schema auth tool, the description covers everything an agent needs: purpose, trigger conditions, async interaction model, user-facing instructions, and the retry path. Nothing essential 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?

Zero parameters with full schema coverage, so the baseline is 4. The description correctly implies no inputs are needed and instead explains the interactive output flow (URL + one-time code to show the user), which is meaningful beyond an empty 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 (authenticating) and resource (remote device cloud provider), and clearly distinguishes this setup/auth tool from the sibling device tools it gates. An agent knows exactly what this does without opening the schema.

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?

Explicitly states when to use it (before mobile_list_remote_devices/mobile_allocate_remote_device work, or on auth error), names the alternative path (retry the failed tool after), and adds a clear when-not (never speculatively). This is textbook routing guidance.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the agent knows this is a non-destructive but state-changing interaction on an external device. The description adds the ref-precedence rule, which is useful, but says nothing about duration, timing sensitivity, or what a long press can trigger on a UI (menus, drag states).

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 tight sentences with no filler. The action and its two modes lead, and the ref-preference guidance is the second sentence, so the most actionable constraint is not buried.

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?

With no output schema, five parameters, and 100% schema coverage, the description supplies the decision logic the schema cannot (which input mode to prefer). Only the duration parameter and the device requirement are absent from the description, both fully documented in the schema.

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%, including x/y requirements, ref precedence, device lookup, and the 500ms default duration with its 1-10000ms bounds. The description only echoes the coordinates-vs-ref choice, adding no format or default detail beyond the schema, so the 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?

Specific verb+resource (long press on screen) with both invocation modes (x,y coordinates or element ref) stated up front. The action is clearly distinct from siblings like mobile_click_on_screen_at_coordinates and mobile_double_tap_on_screen, and it names mobile_list_elements_on_screen as the source for refs.

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 ref when the element is listed" gives an explicit selection rule between the two input modes and ties it to a specific sibling tool. It lacks a when-not / alternative-tool branch (e.g. when to use double-tap or click instead), so it falls short of full routing guidance.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/external-reach profile is covered. The description adds real behavioral value beyond that: it discloses scheme validation, the rejection behavior, and the MOBILEMCP_ALLOW_UNSAFE_URLS=1 escape hatch.

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 sentences, zero filler, with the core action front-loaded and the constraint following immediately. Every clause earns its place.

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 two-parameter tool with full schema coverage and annotations covering the safety profile, the description supplies purpose, accepted input domain, and failure mode. No output schema exists and none is needed for a fire-and-forget navigation action.

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%, so both parameters (url, device) are already documented in the schema, including the http/https requirement and the pointer to mobile_list_available_devices. The description's scheme constraint largely restates the url parameter description, so it adds only marginal meaning.

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 ('Open an http:// or https:// URL in the browser on device') and constrains the accepted scheme inline. This is readily distinguishable from siblings like mobile_launch_app, which handles app launching rather than URL opening.

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 gives a clear negative condition (non-http/https schemes such as app deep links are rejected unless the env flag is set), which tells the agent when the call will fail. However, it never names an alternative tool for the deep-link/app-launch case, so routing guidance is only implied.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds nothing beyond that – no note that presses are non-reversible state changes, no mention of device-state prerequisites, and no rate or timing 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?

A single short sentence with zero waste, front-loading the verb and resource. It is efficient, though it borders on under-specification rather than true 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?

For a simple two-parameter tool with full schema documentation and clear annotations, the definition is minimally sufficient. It omits nothing critical, but it also contributes no context the structured fields do not already provide.

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 schema already documents both parameters in depth, including the full list of supported buttons per platform and their effects. The description adds no parameter detail beyond the schema, so the baseline 3 is 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 ('Press') and resource ('button on device'), which is clearly distinct from coordinate-based siblings like mobile_click_on_screen_at_coordinates or mobile_type_keys. However, it offers no explicit differentiation from those siblings, leaving the agent to infer the boundary.

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 alternatives such as mobile_type_keys, mobile_double_tap_on_screen, or mobile_long_press_on_screen_at_coordinates. The agent must infer the use case entirely from the 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, but the description goes well beyond them by enumerating exactly what is lost (installed apps, pushed files, session changes) and warning that a later allocation may be slow and return a different physical unit. It does not cover auth/permission requirements or return behavior, but the added state-loss and reallocation context is substantive.

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?

Front-loaded with the core action and sibling link, then consequences and the workflow rule. Four sentences, all earning their place, though the final sentence could be trimmed slightly.

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 single-parameter release tool with no output schema, the definition covers purpose, consequences, reallocation caveats, and the timing rule an agent needs to avoid premature release. Nothing essential 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?

Only one parameter with 100% schema description coverage, so the schema already documents the device identifier. The description adds only indirect meaning by tying the identifier to a previously allocated reservation; baseline 3 applies when the schema carries the load.

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 ('release') and resource ('a device previously reserved') and explicitly names the counterpart tool mobile_allocate_remote_device, so the agent can distinguish this from siblings without opening any schema.

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 explicit when-to-use ('once the whole task is finished') and when-not ('if there is more work to do on the same device shortly, keep holding it'), plus the alternative action to take in that case. Nothing is left to inference.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent already knows this is a non-destructive local write. The description's addition that it saves to a file is consistent and mildly useful, but it says nothing about overwriting existing files, required permissions, or what is returned.

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 short sentence with no filler; the action and destination are front-loaded. It is efficient, though arguably too terse to be maximally useful.

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 four-parameter mutation tool with full schema coverage and no output schema, the description is adequate but thin: it omits sibling differentiation against mobile_take_screenshot and does not state whether the saved path is returned or whether existing files are overwritten.

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%, so all four parameters (scale, maxSize, device, saveTo) are fully documented in the schema, including the scale/maxSize interaction and the .png/.jpg/.jpeg filename requirement. The description adds no parameter detail beyond that, so the baseline of 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?

The description names a clear verb and resource (save a screenshot to a file), which is more specific than the title. However, it never distinguishes itself from the sibling mobile_take_screenshot, leaving the agent to guess which one writes to disk versus returns image data.

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 tool versus mobile_take_screenshot, nor any mention of prerequisites such as needing a device identifier. The only implied usage is the presence of a saveTo parameter.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, but not what the write actually does; the description fills that gap by explaining it overrides the reported GPS and that clearing restores the real location, which is meaningful beyond the annotations. It omits whether the override persists, whether it requires a connected device, or any permission requirements.

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 the primary mutation stated first and the clearing behavior second; no filler or redundancy.

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?

Given full schema coverage, a small parameter set, and no output schema, the description covers the essential operation and the reset path. It stops short of clarifying behavior when only one of latitude/longitude is supplied or whether the override survives device reconnect.

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 both latitude/longitude descriptions already contain the omit-together-to-clear rule, so the description largely restates schema content. Baseline 3 applies 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?

States a specific verb (override/clear) and resource (GPS location reported by the device), plus the inverse operation. No sibling tool manipulates location, so an agent can identify it unambiguously.

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?

Explicitly describes the clearing behavior (omit latitude and longitude) and the restoration effect, which is the key usage condition. No alternatives exist among siblings, so no exclusion guidance is needed, but it never states prerequisites about being connected to a device.

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?

Annotations already declare readOnlyHint=false (a mutation) and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the annotations — it does not say whether the change persists, what happens if the device is locked, or how failures surface.

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. It is appropriately sized for a two-parameter tool, though it is so terse it leaves the usage and behavioral gaps noted above.

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?

The tool is simple (2 required params, no nested objects, no output schema) and the schema carries most of the load, so the description is close to sufficient. It still omits any behavior on invocation and any reference to the paired get-orientation sibling.

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%, so the schema already documents both parameters, including the device pointer to mobile_list_available_devices and the orientation enum. The description adds no additional parameter meaning, making the baseline 3 correct.

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 ('change the screen orientation') and the 'change' framing implicitly distinguishes it from the sibling mobile_get_orientation. However, it does not explicitly name the sibling or the scope (persistent vs temporary), so it stops short of full differentiation.

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 when-to-use guidance, no prerequisites, and no mention of the sibling mobile_get_orientation or any alternative. Usage is only implied by the tool name; an agent gets no exclusions or conditions.

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?

Annotations already declare non-read-only, non-destructive, non-open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the recording persists in the background, must be explicitly stopped, and the return value is a save path rather than the recording itself. It omits edge cases such as behavior when a recording is already active or any storage/permission constraints.

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 action, then the lifecycle, then the return value. No filler or repetition of the schema.

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?

With no output schema, the description usefully explains the return value (the path where the recording will be saved) and the stop counterpart, which is what an agent needs to call it correctly. Minor gaps remain around concurrent recordings and failure behavior.

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%, so device, output, and timeLimit are fully documented in the schema, including the .mp4 requirement and auto-stop semantics. The description adds no parameter detail beyond the schema, so the 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 a specific verb+resource ("Start recording the screen of a mobile device") and names the paired sibling mobile_stop_screen_recording, distinguishing it from screenshot tools like mobile_take_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?

Explicitly describes the lifecycle: it "runs in the background until stopped with mobile_stop_screen_recording", which tells the agent this is a paired start/stop operation. It does not, however, say when to prefer recording over mobile_take_screenshot or mobile_save_screenshot.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is already covered. The description usefully adds the return payload (file path, size, duration), but says nothing about what happens if no recording is active or whether the file persists afterward.

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 tight sentences: purpose first, return values second. No filler, no redundancy with the title.

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?

No output schema exists, so the description correctly compensates by naming the returned fields. For a single-parameter tool with full annotation coverage, this is close to complete, though the failure mode (no active recording) is left unaddressed.

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?

Only one parameter with 100% schema description coverage, so the schema fully documents the device identifier and even points to mobile_list_available_devices. The description adds nothing beyond the schema, which is the expected baseline when coverage 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?

States a specific verb+resource (stop an active screen recording) and scopes it to a mobile device. The contrast with the sibling mobile_start_screen_recording is obvious from the verb, but the description never names or references the sibling 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 only implied by the phrase 'an active screen recording' — the agent can infer this applies when a recording is in progress, but the description gives no explicit when-to-use condition, no error case for when nothing is recording, and no routing to alternatives.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds no behavioral context beyond those annotations, such as what the swipe affects, whether it scrolls or navigates, or any side effects.

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 a single short phrase with no wasted words, but it is under-specified rather than concise. Like the calibration example 'Process', its brevity reflects missing substance, not efficient communication.

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?

Even with rich schema coverage and safety annotations, the description does not help an agent understand when this gesture is appropriate or how it relates to adjacent gesture tools. For a swipe tool with five parameters and multiple sibling gesture tools, more contextual framing is needed.

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%, with each parameter including a description, so the schema fully documents required device and direction plus optional x, y, and distance. The description adds no parameter meaning, so the baseline score of 3 is 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?

The description 'Swipe on the screen' is a near-exact restatement of the tool name and title, fitting the rubric's tautology category. It states a verb and resource but does not differentiate the tool from sibling gestures such as click, double-tap, or long-press.

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 about when to use swipe versus alternatives like click_on_screen or press_button, and no prerequisites are mentioned. The description merely repeats the operation without any context for selection.

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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower, yet the description still adds real behavioral context the annotations cannot convey: the image is usually smaller than the screen, the result states how to convert screenshot positions into screen coordinates before tapping, and the result must not be cached. It stops short of noting anything about size/quality tradeoffs (scale, maxSize) affecting the returned image.

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 sentences, zero filler, and the primary purpose is front-loaded before the alternative-tool guidance and the coordinate-conversion caveat. Slightly dense in the middle sentence but every clause carries usable 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?

With no output schema, the description compensates by explaining that the result includes coordinate conversion metadata, which is the key thing an agent must know to act on the returned image. Nothing critical is missing for a read-only capture tool, though the interaction with mobile_save_screenshot remains unaddressed.

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%, so parameters are already fully self-documented by the schema (device, scale, maxSize with ranges and defaults). The description adds nothing about how scale or maxSize change the output, so the baseline 3 applies rather than anything higher.

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 concrete verb+resource ("Take a screenshot of the mobile device") and explicitly names the condition that routes the agent elsewhere (view hierarchy -> list elements). It distinguishes itself from mobile_list_elements_on_screen but never clarifies its relationship to the sibling mobile_save_screenshot, so the boundary between capture-and-return vs capture-and-persist is left implicit.

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 an explicit when-to-use ("understand what's on screen") and an explicit when-not-to-use with the named alternative ("if you need to press an element that is available through view hierarchy then you must list elements on screen instead"). This is exactly the routing an agent needs between the two screen-inspection tools.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so safety profile is covered. The description adds no further context such as whether termination requires the app to be running, whether it is reversible, or what happens to unsaved state.

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 short, front-loaded sentence with no wasted clauses. 'Stop and terminate' is mildly redundant but not harmful.

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 two-parameter, non-destructive action tool with full schema coverage and no output schema, this is minimally adequate. It stops short of clarifying how termination differs from uninstalling, which is the main ambiguity given the sibling set.

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 'device' parameter even points the agent to mobile_list_available_devices. The description adds nothing beyond the schema, so the baseline of 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 a specific verb and resource ('Stop and terminate an app'), so the agent knows the action targets an app on a device. It does not differentiate from siblings like mobile_uninstall_app or mobile_launch_app, which would require knowing terminate vs. remove vs. start.

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 indication of when to use this rather than mobile_uninstall_app (removes the app) or mobile_launch_app (starts it). The agent must infer usage purely 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The phrase 'into the focused element' adds a real behavioral constraint — the tool silently depends on prior focus state — but nothing is said about failure behavior when no element is focused or about the submit side effect.

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, which is appropriate for a simple action. It is arguably too terse for the prerequisites involved, but there is no bloat to trim.

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?

The tool is simple and the schema carries all three parameters, so the definition is minimally viable. It still omits the focus prerequisite, what happens when nothing is focused, and any indication of what is returned, leaving gaps for a tool that mutates device state.

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%: text, device (with a pointer to mobile_list_available_devices) and submit are all documented in the schema, including the default for submit. The description adds no syntax, formatting, or encoding detail beyond that, so the 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 a specific verb and target: type text into the focused element. That is clearly distinct from sibling tools like mobile_press_button or mobile_click_on_screen_at_coordinates in effect, but the description never names those siblings or explicitly contrasts the interaction modes.

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 when-to-use guidance, no stated prerequisites (e.g. that a field must already be focused/clicked first), and no routing to alternatives such as mobile_press_button for key events. The agent must infer the calling context entirely.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no note that app data is removed, that the action is irreversible, or what happens on failure — so it contributes essentially no behavioral context.

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, appropriate in size for a two-parameter tool. It is terse to the point of under-specification rather than verbose, 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?

For a destructive, irreversible tool the annotations carry the safety signal and the schema carries the parameters, with no output schema needed. The description is minimally adequate but omits any consequence of the action (data removal, irreversibility) that would make it complete.

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%, so both parameters (device, packageName) are fully documented in the schema. The description adds no format, constraint, or example detail beyond that, which is the baseline case for high-coverage schemas.

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 (uninstall) and resource (app on a mobile device), which is enough for an agent to know the operation. It does not differentiate from near-siblings like mobile_terminate_app or mobile_install_app, so it falls 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.

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

The description gives no when-to-use guidance, prerequisites, or alternatives; it does not mention that mobile_terminate_app is the non-destructive option or when uninstall is appropriate. The only routing help (mobile_list_available_devices) lives in the schema, not the description.

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