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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds the coordinate-space constraint but never warns that a tap can navigate away, trigger irreversible app actions, or produce no effect if coordinates are stale. For a state-changing interaction with a lower annotation bar, this is adequate but thin.

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

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

One sentence, front-loaded with the action and the core semantics. Nothing is wasted and nothing needs trimming.

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?

An output schema exists, so return values needn't be explained, and the coordinate-space clarification covers the main ambiguity for this simple three-parameter tool. The only real gap is the undocumented required 'device' parameter.

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 0%, so the description must carry the parameter burden. It does explain x/y meaningfully (screen coordinates, with a recommended source), but the required 'device' parameter is completely unaddressed and no format or bounds are given for x/y.

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 (tap) plus the exact coordinate semantics ('screen coordinates') and disambiguates the unit of input. The contrast with phone_long_press_on_screen_at_coordinates and phone_swipe_on_screen is implicit in the verb choice, so an agent can select it without opening another 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?

Provides real guidance on where coordinates come from by naming phone_list_elements_on_screen as a source. However, it never says when to prefer tap over long-press, press_button, or type_keys — usage relative to alternatives 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?

readOnlyHint already declares this is a safe read, and the description adds a genuinely non-obvious behavioral caveat: support is device-dependent, so calls may return nothing usable. The fallback instruction operationalizes that failure mode, which 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?

Two short sentences, front-loaded with the purpose and immediately followed by the failure/fallback note. No filler, nothing that could be trimmed without losing information.

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

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

An output schema exists so return shape need not be explained, and the device-support caveat is covered. The remaining gap is the undocumented device parameter and whether a non-reporting phone errors or returns empty, which matters for how an agent bounds the call.

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?

There is one required parameter (device) with 0% schema description coverage, and the description says nothing about its expected identifier format or where to obtain it (presumably phone_list_available_devices). With low coverage the description is expected to compensate, and it does not.

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?

"Which app is in front right now" names a specific resource and query intent, so an agent can tell this apart from phone_list_apps or phone_list_elements_on_screen. It lacks an explicit verb (e.g. "get"/"return") but the intent is unambiguous.

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 names the fallback path and the condition that triggers it: when a phone does not report the foreground app, use phone_take_screenshot. That is real routing guidance rather than implied usage, though it does not cover the positive case (why to prefer this over list_apps).

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 readOnlyHint already declares this is a safe read, and an output schema exists, so the description's main added value is the coordinate-space guarantee. It does not disclose whether the value changes with device rotation, whether it is cached, or how it relates to a specific running device.

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 filler. It is efficient, though the coordinate-space clause could be sharpened into an explicit call-order hint.

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 an output schema present, return values need not be explained, and the coordinate-space note covers the main conceptual gap. However, the undocumented 'device' parameter and the missing unit/prerequisite details leave the definition only partially complete for a device-scoped 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 coverage is 0% and the single required parameter 'device' is never mentioned in the description. An agent must guess whether this is a device id from phone_list_available_devices or a human-readable name, and whether the device must be started first.

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 resource and return value (screen size) and adds the key qualifier that it is in the coordinate space used by the tap and swipe tools. That distinguishes it from siblings like phone_take_screenshot or phone_list_elements_on_screen without naming them 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 via the reference to 'the tap and swipe tools' – an agent can infer it should be called before phone_click_on_screen_at_coordinates or phone_swipe_on_screen, but the description never states when to call it or that it is a prerequisite for coordinate math.

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 and destructiveHint=false, so the agent knows this is a non-destructive action. The description adds the naming convention but omits what happens on failure (app not installed), whether the app is brought to the foreground if already running, and any device-state prerequisites.

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 sentence with no waste; the primary identifier convention is front-loaded and the Android package-id exception is appended compactly.

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?

An output schema exists, so return values needn't be explained, and the annotations cover the safety profile. However, with 0% schema description coverage and a completely undocumented "device" parameter, plus no mention of device-state prerequisites, the description leaves meaningful gaps for a two-required-param device 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 coverage is 0% for two required parameters, so the description carries the full burden. It explains the "name" parameter well (icon label or Android package id, with examples) but says nothing at all about the required "device" parameter, leaving half the surface undocumented.

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 ("Open") plus resource ("app") with concrete examples of the accepted identifier formats ("Settings", "Notes", "Chrome") and the Android package-id variant. It doesn't explicitly contrast with siblings like phone_list_apps or phone_get_foreground_app, 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?

Usage is implied by the identifier format guidance, but there is no statement of when to prefer this over sibling tools (e.g., use phone_list_apps to discover valid names) and no preconditions such as the device needing to be started via phone_start_device. The agent must infer the workflow.

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?

readOnlyHint=true already communicates the safety profile, so the description's burden is lower. It usefully adds that returned identifiers are actionable in phone_launch_app and differ by platform, but says nothing about result size, ordering, or whether all installed apps (including system apps) are 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?

Two tight sentences with zero filler; the core purpose and identifier semantics are front-loaded before the follow-up hint about phone_launch_app.

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?

An output schema exists, so return values need not be explained, and the read-only nature is covered by annotations. The remaining gap is the undocumented required 'device' parameter, which an agent must infer from a sibling 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 0% for the single required 'device' parameter, and the description never mentions it. Given the total lack of schema documentation, the description should explain what 'device' expects (e.g., a device id from phone_list_available_devices), but it does not.

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 ('apps installed on the phone') and clarifies the identifier format per platform (package ids vs bundle ids), which distinguishes it from device-scoped siblings like phone_list_available_devices. It does not explicitly contrast with any named alternative, keeping it just 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 sentence 'Any of them can be passed to phone_launch_app' implies a downstream workflow, giving some implied usage context. However, there is no explicit when-to-use/when-not guidance or comparison against alternatives such as phone_get_foreground_app.

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?

readOnlyHint=true already covers the safety profile, and the description adds genuinely non-obvious content: the list spans two populations, already-running phones and phones that could be started. That distinction affects downstream logic (a returned id may need phone_start_device first). It does not cover ordering, empty-account behavior, or auth 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?

A single sentence carrying purpose, scope, and the cross-tool id contract, with the primary purpose front-loaded before the qualifier about startable phones. Nothing is redundant with the title or annotations.

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 no-argument, read-only list tool with an output schema, the description supplies everything needed to decide to call it and how to use the result. Minor gaps such as result ordering or the empty-account case are not material.

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, so baseline is 4; the schema adds nothing to explain. The description doesn't need to compensate, though it does usefully clarify the meaning of the `device` id values produced by this tool and consumed elsewhere.

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 plus resource ('List the phones running on this account') with a clearly delineated scope: it returns both running devices and devices the account can start. It also explains that the returned ids are the `device` identifiers consumed by the other phone_* tools, which makes its role unambiguous within the sibling set.

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 phrase 'whose ids the other tools take as `device`' effectively tells the agent to call this first for discovery, and the running-vs-startable split hints that phone_start_device handles the not-yet-running entries. It stops short of explicitly naming phone_start_device or stating when not to call it.

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?

Beyond the readOnlyHint annotation, it discloses an important implementation asymmetry: accessibility-tree positions on Android versus pixel-derived detection on iPhone, which tells the agent results may differ in reliability and completeness across platforms. The staleness warning ('call it again after the screen changes') is likewise useful behavioral context not present in 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?

Three short sentences, front-loaded with the what and the return shape, followed by platform behavior and the refresh caveat. No filler and nothing repeated from 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?

The output schema covers return values, so the description correctly does not restate them, and it explains the coordinate payload's purpose. The remaining gap is the silent 'device' argument, which matters in a toolset where many devices can be listed and started.

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 0%, so the description carries the burden, yet neither parameter is mentioned. The 'device' parameter — required, and non-obvious given a multi-device toolset with phone_list_available_devices as a sibling — and the text/json 'format' enum are left entirely unexplained.

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 the text visible on screen') plus the exact payload returned (each piece's center point), which distinguishes it from the screenshot siblings. It also names the natural follow-up tool, so the agent knows immediately what class of operation this is.

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 to phone_click_on_screen_at_coordinates as the consumer of the returned coordinates and tells the caller to refresh after the screen changes. It lacks a stated when-not (e.g. use phone_take_screenshot for images/non-text), which keeps it below 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=false and destructiveHint=false, so the safety profile is covered. The description adds only the duration default (which the schema already declares as default 800), and says nothing about gesture side effects, whether the hold triggers context menus, blocking behavior, or timing tolerance.

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

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

A single front-loaded sentence with zero filler; the coordinate anchor and duration semantics are both stated compactly.

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?

An output schema exists, so return values need not be described, and annotations cover safety. However, given 0% schema coverage the description should at least identify the device parameter and clarify interaction semantics relative to click/swipe; those omissions leave it only adequate.

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 0%, so the description must compensate: it explains what x/y mean (screen coordinates) and what duration is in milliseconds with its default. It leaves the required 'device' parameter completely unexplained, which is a meaningful gap for a 4-parameter tool.

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 hold') plus resource ('at (x, y) in screen coordinates'), which implicitly distinguishes it from click and swipe siblings. It does not explicitly name those siblings as alternatives, keeping it at 4 rather than 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?

No guidance on when a long press is preferred over phone_click_on_screen_at_coordinates or phone_swipe_on_screen, and no prerequisites (e.g., an active device session) are stated. The agent must infer usage from the tool name alone.

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

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

Annotations already establish that this is not read-only and not destructive. The description adds a useful platform caveat that BACK does not exist on iPhone, but it does not disclose effects such as HOME backgrounding the app, whether ENTER targets a focused field, or device-state prerequisites.

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 front-loaded sentence with no filler. Every clause, including the iPhone caveat, contributes useful 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?

An output schema and annotations exist, so return format and safety need not be restated. Still, the definition is incomplete because the required device parameter is never explained and there is no guidance on alternatives or prerequisites.

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 0%. The description repeats the button enum values and adds platform meaning for BACK, but the required 'device' parameter is entirely undocumented in both the schema and the description. With low schema coverage, more parameter semantics 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?

The description states a specific verb and resource ('Press a system button') and enumerates the exact supported button values. The phrase 'system button' helps distinguish it from coordinate-based siblings, 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?

Usage is implied by the system-navigation button set, and the iPhone/Android note gives some context. However, it does not say when to use this instead of phone_click_on_screen_at_coordinates, phone_long_press_on_screen_at_coordinates, or phone_type_keys for ENTER.

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 say readOnlyHint=false and destructiveHint=false; the description adds genuine behavioral detail beyond that: file format is chosen by the extension (.png → PNG, otherwise JPEG) and the default is full resolution unless max_size or scale is given. It still omits overwrite behavior when the target file exists and whether permissions/paths are validated.

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 with the core action front-loaded and two concrete behavioral clauses appended. 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?

The existence of an output schema relieves the description of explaining return values, and the format/size rules are covered. But for a 4-parameter file-writing tool with 0% schema coverage, leaving `device` undocumented and the capture-vs-save semantics unstated against a directly competing sibling leaves real gaps.

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 0%, so the description must carry parameter meaning; it does explain save_to's extension-driven format and that max_size/scale override full size. But the required `device` parameter gets no mention at all, and units for max_size (pixels? bytes?) and scale (factor vs percentage) remain undefined.

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 ("Save a screenshot to a file on this machine") and adds the format rule, so the action is unambiguous. However, it never distinguishes itself from the sibling phone_take_screenshot — an agent cannot tell whether this captures a fresh screenshot or persists an existing one.

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 phrase "to a file on this machine" implicitly signals the use case (persisting to disk rather than returning inline), and "Full size unless max_size or scale says otherwise" implies when the sizing options apply. But there is no explicit when-to-use, when-not-to-use, or named alternative such as phone_take_screenshot, so the agent must infer the routing.

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/destructive/idempotent flags; the description adds genuinely new context: billing by the minute, the 30-minute default window, that state (apps and logins) persists on saved devices, and the required teardown step. It stops short of disclosing what happens if the device is already running or whether concurrent starts are limited.

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 dense sentences, front-loaded with action, return value, and default behavior, then parameters, then cost and teardown. No filler and no sentence that fails to add 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 an output schema present, the description need not explain return values, and it still covers lifecycle, cost, device selection, and cleanup. For a 4-param creation tool with no annotation detail, everything an agent needs to invoke it correctly is present.

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

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

Schema coverage is 0%, so the description carries the full burden and largely does: it explains the kind/platform coupling, the provenance of device_id, and the billing meaning and default of minutes. Remaining gaps are the absence of any bound or expiry behavior for minutes beyond the default.

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 a phone'), its blocking semantics ('wait until it is ready'), and its return ('returns its device id'). It also distinguishes variants (default temporary Android emulator vs. saved Android phone vs. account iPhone), so an agent can tell exactly what it will get.

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 names the sibling that supplies input ('device_id is an id from phone_list_available_devices') and the sibling that must follow ('stop it with phone_stop_device when done'). It also states the zero-argument default path, removing any ambiguity about how to call it.

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 and idempotentHint=true, so the description earns credit for adding the concrete consequence: unsaved data on the device is lost. That is exactly the pre-call warning an agent needs beyond the hint flags. It does not discuss auth or session state, but the output schema covers results.

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

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

Two short sentences, zero waste, with the action and its consequence front-loaded before the loss warning. Nothing could be cut without losing meaning.

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

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

The output schema removes the need to describe return values, and the data-loss warning covers the destructive risk. The missing piece is how to supply a valid 'device' identifier, which is the sole required input for a mutation 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?

There is one parameter ('device') with 0% schema description coverage, and the description says nothing about what form it takes — device ID, name, or index from phone_list_available_devices. This is the one place the description should compensate for the empty schema and it does not.

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 ('End a running phone session') plus the practical reason ('so it stops billing'), which clearly positions it as the counterpart to phone_start_device. It does not name the sibling explicitly, so it stops just 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?

Usage is implied by the billing rationale — an agent can infer you call this when a session is no longer needed — but there is no explicit when-not guidance, no mention of checking unsaved state first, and no reference to phone_start_device or phone_list_available_devices.

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 and destructiveHint=false, so the safety frame is set. The description adds real behavioral context — the start point falls back to screen center and distance defaults to 40% of the screen — but says nothing about gesture speed/duration, whether the call blocks until the gesture settles, or side effects like triggering navigation or dismissing content.

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

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

A single dense sentence with the direction semantics front-loaded and no filler. Every clause — direction meaning, start point default, distance default — carries information the schema does not.

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 an output schema present, return values need no explanation, and the geometrically tricky parameters are covered. The gaps are the undocumented `device` parameter and the absence of guidance on when this gesture is the right choice versus the many sibling interaction tools.

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

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

Schema coverage is 0%, so the description must carry the load, and it does: x/y are explained as the start point with a screen-center default, distance as pixels with a 40%-of-screen default, and direction is given concrete finger-movement semantics. Only the required `device` parameter is left unexplained.

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 (swipe) plus the key semantic subtlety that trips agents up: direction is the direction the finger moves, so "up" reveals content below. That is a concrete, distinguishing clarification that separates it from the click and long_press siblings without needing 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?

Usage is only implied by the gesture semantics — there is no statement of when to prefer a swipe over phone_click_on_screen_at_coordinates, phone_list_elements_on_screen, or phone_press_button. An agent can infer that swiping is for scroll/reveal gestures, but nothing explicitly routes it away from 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 only cover readOnlyHint, so the description carries most of the burden and does well: it discloses that the returned image is scaled down from the real screen and that a coordinate conversion note precedes it. Those are behaviors an agent cannot get from the schema. It still omits how the scaling relates to the scale/max_size inputs.

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 usage condition, then the freshness warning. Little waste, though 'the text before it' is a vague reference that costs a moment of parsing.

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

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

There is no output schema, and the description compensates by explaining the returned image format and coordinate mapping. However, for a 3-parameter tool with zero schema documentation, the total absence of parameter guidance (especially the required device) leaves a 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 0% and there are 3 parameters, including a required 'device', yet the description never explains what any of them mean. The remark that 'the image is usually smaller than the screen' hints at scale/max_size but gives no guidance on values or defaults, so the coverage gap is unmitigated.

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: 'Take a screenshot of the phone'. The distinction from the sibling phone_save_screenshot (capture vs persist) is not made explicit, so an agent must infer which one it wants when saving is the goal.

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 it to understand what is on screen when the text list is not enough' gives a clear trigger and implicitly routes away from phone_list_elements_on_screen. 'Do not reuse an old screenshot: the screen changes' gives a valuable when-not rule, but it never names phone_save_screenshot or any alternative explicitly.

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 that this is a non-destructive write; the description adds genuinely new behavior: input requires an existing focus, unfocused input is silently discarded, and `submit` triggers Enter afterwards. It does not say what happens on failure or what is returned, but the key interaction risks are disclosed.

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

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

Three short sentences, front-loaded with the core action, then the precondition, then the optional flag. No filler and nothing repeated from 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?

Output is covered by an output schema, so return values need not be explained. Combined with the focus precondition and Enter behavior, an agent has what it needs to call it correctly; only error handling and the `device` parameter are unstated.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains `submit` explicitly ('presses Enter afterwards') and `text` implicitly through the verb; only `device` is left unaddressed, though its meaning is self-evident from the sibling set.

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 field'), which no sibling covers – siblings handle taps, swipes, buttons, and screenshots. An agent can select this tool 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?

Gives a concrete precondition ('Tap the field first so the keyboard is up') and warns about the failure mode when nothing is focused. It does not name the sibling to use for focusing (e.g., phone_click_on_screen_at_coordinates), so the alternative routing is left implicit.

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