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

With no annotations, the description carries the full behavioral-disclosure burden. 'Get' implies a read operation, and the description usefully states the exact foreground data returned and frames the tool as cheaper than snapshot; however, it does not explicitly state that it is read-only or discuss permissions, side effects, or the optional device parameter's 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?

The description is two short sentences with no wasted wording. The core purpose and return fields are front-loaded, followed by the snapshot comparison that helps tool selection.

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 has an output schema, so the description need not explain return formatting. It is mostly complete for purpose and selection, but the sole parameter, 'device,' is entirely unaddressed, leaving a meaningful gap for invocation.

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 optional parameter, 'device,' with 0% schema description coverage, so the description would need to compensate. It does not mention the parameter at all, leaving its meaning and default behavior undocumented in both the schema and the 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 uses a specific verb and resource: 'Get just the foreground app,' then enumerates exactly what is returned: package, activity, and crash-dialog status. It also distinguishes the tool from the broader snapshot sibling by calling itself cheaper when only foreground information is needed.

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 compares the tool to 'a full snapshot' and states the condition for choosing it: when you only need the foreground app. It does not provide explicit when-not guidance or mention other possible alternatives such as get_device, but the main routing decision is 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?

With no annotations, the description carries the full burden; it clearly implies a read-only inspect operation and identifies the exact log buffer. It does not mention whether the buffer is cleared, whether a device must be connected, or what happens if multiple devices are attached and `device` is omitted. The output schema covers return values, but behavioral gaps around device selection and buffer state remain.

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 compact sentence front-loads the action and resource, then appends the use-case after an em dash. No wasted words and no buried essential 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?

The tool is simple and has an output schema, so return-value detail is not needed. However, with zero annotation coverage and zero schema description coverage on two parameters, the definition should at least explain the `lines` and `device` semantics and the default-device behavior. It is minimally viable but incomplete for correct invocation.

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, but it says nothing about `lines` (default 200) or `device` (default null). An agent cannot infer from the description how many lines are returned by default or how device selection works when the parameter is omitted.

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 verb ('Read') and resource ('crash log buffer') and even anchors it to the underlying implementation ('logcat -b crash'). It is clearly distinct from all siblings, which are device-control or app-management tools, none of which read logs.

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 usage context: 'use this after an app crashes during QA testing to see the real stack trace.' That tells the agent when to select it, though it offers no exclusions or named 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?

No annotations are provided, so the description carries the full disclosure burden. It is clearly a read operation and it enumerates the returned data, but it does not state what happens if the device is offline, uninstalled, or the identifier is invalid, nor whether the call blocks or times out. Adequate but with real gaps for an unannotated 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?

Two short sentences, zero filler, with the resource and its returned fields front-loaded before the optional-parameter note. Every clause carries information the 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?

For a single-optional-parameter read tool with an output schema and no annotations, the description covers purpose, output scope, and the default fallback. What remains missing is error/offline behavior and identifier format, which are not covered by the schema either.

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 compensate, and it does add one genuinely useful instruction: the parameter may be omitted to fall back to the default device. However, it never says what form a device identifier takes (serial, index, alias) or how to obtain one, leaving the only parameter partially specified.

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 full status of one device") followed by an enumeration of exactly what is returned: boot state, Android version, screen size, foreground app. The singular "one device" implicitly contrasts with the sibling list_devices, but no sibling is named explicitly, so differentiation is left to inference.

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

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

No explicit when-to-use vs when-not guidance, and no mention of how this differs from the sibling `foreground` tool, which appears to overlap on the foreground-app portion of the output. Usage is only implied by the read-status framing; the one line of guidance given ("Omit `device` to use the default") is a parameter default, not a selection rule.

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

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

With no annotations, the description carries the full burden, and it does add real value by disclosing that the returned payload includes parsed package info and an explicit success flag, plus the server-vs-device path caveat. However it says nothing about permission requirements, overwrite/replace behavior, downgrade rejection, or how failures surface — significant gaps for a mutating tool with zero annotation coverage.

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, front-loaded with the action and the critical path-location caveat. The parenthetical marketing aside ('the real use case ERIUS PHONE is built for') is the one sentence that does not fully earn 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?

An output schema exists, so return-shape coverage is already handled, and the description correctly focuses on the path caveat and QA framing. But for a 4-parameter mutating tool with no annotations and no schema descriptions, the missing detail on device targeting, downgrade handling, and permission granting leaves the definition only minimally sufficient.

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% across 4 parameters. The description meaningfully clarifies only apk_path (local path on the MCP host, not the device); device, allow_downgrade, and grant_permissions are left entirely to their bare names, with no explanation of selection semantics or consequences.

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

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

States a specific verb and resource ('Install an APK') and immediately disambiguates the ambiguous part: the file path is on the MCP server, not the phone. An agent can distinguish this from siblings like launch_app or uninstall_app 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 frames the use case ('APK QA testing — the real use case ERIUS PHONE is built for'), which gives clear usage context. It does not name alternatives or state when not to use it (e.g., install from a URL, or reinstall flows vs uninstall_app), so it stops short of full when/when-not 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?

No annotations are supplied, so the description carries the burden. It does disclose one internal behavior (launcher activity is resolved automatically, with `activity` as fallback), which is genuinely useful, but says nothing about failure modes (app not installed), whether the call blocks until the app is foregrounded, or 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 sentences, zero filler, with the primary action and its main argument front-loaded before the edge-case note. Nothing to remove.

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?

Return values are covered by the output schema and the core launch semantics are stated. The gaps are the undocumented `device` selector and the absence of any failure/blocking behavior, which matter for a tool with no annotations.

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

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

Schema coverage is 0%, so the description must compensate; it explains `package` format via a concrete example and the conditional role of `activity`, covering two of three parameters. The `device` parameter gets no mention at all, leaving target selection undocumented despite a list_devices sibling.

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 installed app), and the parenthetical package-name example makes the granularity unambiguous. Easily separated from list_apps, install_apk, stop_app, and send_intent among the siblings.

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

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

The second sentence gives a clear conditional for the optional `activity` argument, which is real usage guidance. However, there is no statement of when to use this versus send_intent (deep links/custom intents) or open_url, and no preconditions such as the app needing to be installed first.

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

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

With no annotations at all, the description carries the full disclosure burden. It never states that this is a read-only, side-effect-free operation, what happens if no device is attached, or whether the device parameter defaults to the current target — all things an agent needs before invoking a device-level command.

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, no filler, with the core purpose front-loaded and the filter behavior immediately after. Nothing could be removed 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 values need not be explained. However, for a two-parameter tool with zero schema description coverage and no annotations, the unexplained `device` parameter leaves a real hole an agent must resolve by trial.

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 both parameters depend entirely on the description. The description handles third_party_only well (name, type, and effect), but the `device` parameter is never mentioned, leaving an agent to guess whether it takes a serial, an index, or an alias.

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 opens with a specific verb and resource: "List installed apps on the device," which is immediately distinguishable from list_devices and the launch/stop/uninstall siblings. It also carves out scope with the third_party_only filter. It stops short of naming a sibling or stating the resulting app-object shape, so it isn't 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 useful guidance for choosing a parameter value ("Set third_party_only=True to skip pre-installed system apps"), which implies when to use each mode. But there is no guidance on when to call list_apps versus inspecting a package another way, and no mention of prerequisites such as a connected 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?

With no annotations, the description carries the full behavioral burden. It discloses access scoping (API key visibility), live status contents, and returned device ids, but says nothing about pagination, empty-result behavior, or auth failure modes. That is adequate for a simple list tool but leaves clear gaps.

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 action and scope, followed by the sequencing instruction. Every clause earns its place and nothing is padded.

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

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

An output schema exists, so return structure need not be explained, and the description covers scope and call ordering. It stops short of noting pagination or error behavior, which keeps it from a perfect score but is sufficient for a simple discovery 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 are zero parameters, so there is no parameter behavior to explain; the baseline for a no-param tool is 4. Nothing in the description misleads about inputs.

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 every Android device") and scopes it to "your API key can access." The plural "every" implicitly distinguishes it from the single-device sibling get_device, so an agent can route correctly without opening other 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?

"Call this first to get device ids" gives explicit sequencing guidance that tells the agent this is the entry point before device-specific tools like get_device or tap. It lacks an explicit exclusion case, but the recommended order is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one real trait — the hold duration default of 800 ms and the fact that `ms` only applies to the x,y form — but says nothing about what the press does to UI state, whether it blocks/waits, or what happens if the target isn't found.

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, front-loaded with the action and its use cases, then the targeting model, then the one non-obvious parameter rule. Nothing is redundant.

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 no explanation, but for a 9-parameter UI-interaction tool with zero annotations the description leaves gaps: the `device` parameter, target-resolution precedence, and failure/blocking behavior are 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 0%, so the description must compensate; it does explain five of the nine parameters (ref, text/content_desc, x/y, image_width/image_height, ms) and the important constraint that ms is ignored for element targeting. However, `device` is never mentioned and the precedence between ref, text, and x/y is only implied by wording.

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 verb+resource ("long-press an element") and gives concrete purposes for it (open a context menu, start a drag), which distinguishes it from the plain tap sibling. It stops short of an explicit 'this is tap-with-a-hold' contrast line, but the reference to tap() makes the relationship clear.

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 examples (context menu, drag start) imply when this is the right tool, but there is no explicit 'use this instead of tap/swipe when...' guidance and no mention of alternatives among the many siblings (tap, swipe, scroll). Usage is inferable rather than 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?

No annotations are provided, so the description carries the full burden: it does not say that this brings an app to the foreground, what happens if no handler exists for the scheme, whether it fails on an unknown package, or which device is targeted when 'device' is omitted. The scheme list and the package-override effect are the only behavioral facts supplied.

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 action, with the optional behavior in a parenthetical. No filler; the only nit is the awkward line break mid-sentence, which is cosmetic.

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 URL/package semantics are covered. However, for a three-parameter device-action tool with no annotations, the unexplained 'device' parameter and the absence of any failure/foreground behavior leave meaningful 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 compensate. It usefully explains the accepted URL schemes and clarifies that 'package' forces a specific app package (with an example), but the third parameter, 'device', is never mentioned — the agent cannot tell whether it takes a serial, an id, or a name, nor what the null default means.

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 a URL ... on the device') and enumerates the accepted schemes (http/https/market), which goes beyond restating the name. It does not differentiate from plausible siblings like launch_app or send_intent, so an agent must infer which one to reach for.

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 only guidance is tied to a parameter ('optionally forcing it into a specific app package, e.g. open a link in Chrome'), not to tool selection. There is no statement of when to use open_url versus launch_app, send_intent, or when a package override is required versus optional.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the action but does not disclose side effects, permissions, target-device assumptions, or the potentially disruptive nature of keys like power, delete, back, or home.

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. The key list is long but directly useful and appropriately placed after the core action.

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 key-press tool with an output schema, the description is mostly sufficient about the action and key values. It is incomplete because it omits the optional 'device' parameter and does not disclose any behavioral effects, which matters given the absence of annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaningful semantics for the required 'key' parameter by listing valid key names, but it does not mention the optional 'device' parameter at all, leaving half the parameters 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?

The description uses a specific verb and resource ('Press a hardware/navigation key') and enumerates the supported keys, making the core action clear. However, it does not explicitly contrast this with siblings like tap, long_press, type_text, or swipe, so sibling differentiation is implied rather than stated.

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 provides no explicit when-to-use or when-not-to-use guidance. It implies usage through the list of key names, but does not name alternatives such as tap or type_text or explain when this tool is preferred over them.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return payload shape, default encoding and size (~1024 px JPEG, tens of KB), and a concrete failure mode — a 3 MB PNG exceeding many MCP clients' tool-result limits. It doesn't say what happens with the nullable `device` parameter (whether it defaults to the active device) or what occurs on error when no device is attached.

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 outcome and return shape, then cost guidance, then parameters — the ordering matches how an agent needs the information. Mild redundancy in restating the default size and then re-explaining when to override it, but nothing is padded.

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

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

No output schema and no annotations exist, so the description must explain returns and cost, and it does — including the text line, image dimensions, and client size limits. Combined with the parameter ranges, an agent has everything needed to call this correctly on the first try.

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, and it does for four of five parameters — explaining `format` values, `quality` range 1-100, `max_side` range 64-8192 and its default role, and `scale` (0.1-1) as a multiplicative alternative. The `device` parameter is never mentioned at all, leaving a real gap in an otherwise strong explanation.

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 and resource ("take a screenshot of the device screen") plus an explicit statement of what comes back (an image plus one line of size text). It also differentiates from the sibling snapshot() by contrasting image output with text+refs, so an agent can route correctly 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 the expensive variant ("ask for it only when you need it: format=\"png\", max_side=None") and names the alternative ("Prefer snapshot() when you only need text and refs"). It also flags the downstream condition that coordinates must be interpreted in image pixels via image_width/image_height on tap/long_press/swipe.

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

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

No annotations exist, so the description carries the full burden. It discloses a key failure mode ('scrolling a single row does nothing') and a fallback path, which is exactly the kind of non-obvious behavior an agent needs; it does not mention scroll magnitude, whether it stops at boundaries, or any device-side effects, so it stops short of full disclosure.

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 critical constraint, then the alternative. No wasted clauses, though the ref constraint and the alternative could arguably be merged to tighten it further.

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 no explanation. For a 3-param no-annotation tool the description covers the make-or-break detail (which ref to pass) and the escape hatch, but leaves `device` and scroll distance unspecified.

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 compensate. It does well for `ref` (must be the container's ref, not a row's) and implies the `direction` value set (up/down/left/right), but says nothing about `device` or how direction strings are formatted. Partial compensation for a three-parameter, undocumented schema.

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

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

The first sentence gives a specific verb (scroll) plus the resource (list/container) and the supported directions, which maps directly to the `direction` param. It also implicitly separates itself from `swipe`, the closest sibling, by naming it as the fallback for a different case.

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?

States an explicit precondition (the ref must be the scrollable container, not a row) and an explicit alternative with the condition that selects it: if the container has no ref, use swipe(). Nothing about when to use this vs. swipe 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?

No annotations exist, so the description bears the full disclosure burden. It does disclose the key side effect — this launches an activity and changes the foreground app — plus the return shape ('ok plus the new foreground app'). It says nothing about failure behavior for malformed intents, missing components, or whether the action is blocked on certain devices.

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 concrete shell equivalent, then the example, then parameter formatting notes, then the return. Three sentences and no filler. It is dense rather than padded, though the example and the extras note could be tightened 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?

An output schema exists, so return values need not be spelled out (and the description's brief mention is a bonus). But for a flexible 6-parameter intent tool with zero schema coverage, leaving `data`, `package`, and `device` undefined is a real gap — an agent cannot tell how to target a specific device or attach a URI.

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 6 parameters, so the description must compensate. It does add real meaning for `action` (via an example intent string), `component` (the 'package/.Activity' format), and `extras` (type-to-extras coercion). The `data`, `package`, and `device` parameters get no explanation at all — `device` in particular, which is unexplained despite likely meaning multi-device targeting.

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 an activity with an arbitrary Android intent') and grounds it in the underlying command (`am start -a ACTION`), which tells an agent exactly what primitive this wraps. It does not explicitly distinguish itself from the closer siblings (`launch_app`, `open_url`), leaving that differentiation to inference.

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

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

The settings-page example implies a usage context (deep-linking to a specific screen), which is genuinely helpful. However, there is no statement of when to prefer `launch_app` or `open_url` over this lower-level escape hatch, and no mention of any prerequisite such as a connected device or debugging permissions.

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

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

With no annotations, the description carries the full burden and does disclose a critical behavioral trait: refs reset on every snapshot, so a new snapshot must be taken after each action. It does not mention whether the call is read-only, cost/latency, or output size limits from max_depth/max_nodes.

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 tightly written sentences, front-loaded with the core action and followed by the operating rule. No filler; every clause carries 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?

An output schema exists so return values needn't be spelled out, and the read-before/read-after workflow is covered. However, for a tool with three undocumented optional parameters (including truncation controls), the description leaves the agent guessing about how to shape 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?

Schema description coverage is 0%, so the description must compensate for the three parameters, and it mentions none of them — 'device', 'max_depth', and 'max_nodes' are entirely unexplained. This is a meaningful gap since max_depth/max_nodes likely control truncation behavior an agent needs to know about.

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 — 'Get an accessibility-tree snapshot of the current screen' — and enumerates what the result contains (text, role, ref id). This makes it clearly distinguishable from the sibling 'screenshot' (pixels) and from action tools like tap/scroll.

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 workflow guidance: 'read it before acting, and take a fresh one after any action since refs reset on every snapshot.' It does not state when to prefer 'screenshot' or 'wait_for_text' instead, so the alternative-selection guidance is incomplete.

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

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

No annotations, so the description carries the full burden. 'Force-stop' implies destructive behavior (unsaved state lost, process killed) yet the description never states this, nor whether permissions are needed or what happens on a non-running or nonexistent package.

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 front-loaded sentence with zero waste; no filler or restated 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?

For a destructive mutation with no annotations and undocumented parameters, the definition is thin. The output schema covers return values, but the missing 'device' semantics and absent force-stop side effects leave gaps an agent needs filled before calling.

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% across two parameters. The description clarifies that 'package' is the package name, which adds real meaning over the bare string schema, but the optional 'device' parameter is completely unexplained — an agent cannot tell how to target a specific device.

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?

A specific verb (force-stop) applied to a specific resource (a running app), plus the keying parameter. It is clearly separable from launch_app, uninstall_app, and list_apps in 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 'a running app' implies the context, but there is no explicit when-to-use guidance, no statement about what happens if the app is not running, and no routing to alternatives such as uninstall_app or launch_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?

With no annotations, the description carries the full burden and does add genuine behavioral context about the two coordinate frames. However, it omits the gesture duration semantics (`ms` defaults to 300), whether the call blocks until the swipe completes, and what happens with out-of-bounds coordinates or a missing `device` — all material for an input-injection tool with zero annotation coverage.

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 the core action first and the coordinate-space caveat second; no wasted prose. Slightly dense at the end, but the structure serves the reader.

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 that need not be described. But for an 8-parameter, unannotated interaction tool, the definition leaves device targeting, timing, and failure behavior unaddressed — enough gaps that an agent could call it correctly only by guessing.

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 for 8 parameters. It explains the meaning of x1/y1/x2/y2 and how image_width/image_height switch the coordinate space, which is real added value, but leaves `ms` (duration) and `device` (target selection) completely 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?

The description gives a specific verb (swipe) plus the exact endpoints (from one point to another) and the coordinate frame, so an agent knows precisely what gesture is performed. It does not distinguish itself from the adjacent sibling `scroll`, which is the most likely source of ambiguity in this toolset.

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 statement of when to prefer `swipe` over `scroll`, `tap`, or `long_press`, nor any prerequisite context (device must be attached, app in foreground). The only conditional guidance is about coordinate systems, which is parameter behavior rather than tool 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?

No annotations are present, so the description carries the full burden. It does add genuinely useful behavioral context about coordinate interpretation (device pixels vs. screenshot-space pixels mapped to the screen), but it omits what happens when no element matches, how ambiguity between multiple matches is resolved, and that this mutates UI 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?

Three tight sentences with the preferred path front-loaded and the coordinate-mapping caveat packed into a single parenthetical. No filler, and the most important guidance (use `ref`) comes 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?

The output schema exists, so return values needn't be described. Still, for an 8-parameter tool with zero schema descriptions and no annotations, leaving `device` undocumented and not addressing failure/no-match behavior leaves gaps an agent may hit in practice.

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 — and it largely does, explaining the meaning and interplay of `ref`, `text`, `content_desc`, `x`, `y`, `image_width`, and `image_height`, including that the image_* pair changes the coordinate space. Only `device` is 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?

Opens with a specific verb+resource ("Tap an element") and immediately distinguishes itself from siblings like long_press, swipe, and scroll by being a discrete-tap action. The three targeting strategies name the exact inputs an agent would use.

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 a preference order: "Prefer `ref` from a snapshot()", then `text`/`content_desc`, then raw coordinates as a fallback. This is clear routing guidance and names the snapshot() sibling that produces the preferred input, though it never says when to choose tap over long_press or scroll.

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

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

With no annotations, the description carries the full burden and discloses a real failure mode (keystrokes sent while the field is opening are lost), the ASCII-only adb limitation, and clear/enter side effects. It does not cover error behavior on an invalid ref or whether `clear` is irreversible, so it falls just 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?

Front-loaded with the core action, then the optional behaviors, then the timing pitfall. Slightly long and the middle clause is a bit run-on, but every sentence conveys actionable 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?

Output schema exists so return values need no explanation; the description instead spends its space on the non-obvious timing hazard and the multi-step focus/wait/type recipe, which is exactly what an agent cannot infer from structured fields.

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 compensate: it explains ref and text_target as focus targets, clear as clearing the existing value, and enter as pressing Enter after. Only the `device` parameter is left unexplained, which is a modest gap for a 6-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?

Opens with a specific verb and resource ("Type text into a field") and immediately clarifies its interaction boundary with sibling tools tap, press_key, and snapshot. An agent can distinguish it from tap or press_key without consulting 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 an explicit conditional workflow: if tapping the field opens a new screen, tap first, wait with snapshot() or wait_for_text(), then type with no target. It names the alternative tools and the exact conditions that select them, plus the "check the result with snapshot()" follow-up.

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

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

With no annotations, the description carries the full burden, yet it never says this is destructive, that app data is removed and unrecoverable, or what happens when the package is not installed. "Uninstall" implies mutation, but an agent gets no explicit warning about irreversibility or required permissions.

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 efficient, though its brevity here is more under-specification 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 destructive, irreversible operation with no annotations and an undocumented device parameter, the description is far too thin. The presence of an output schema removes the need to explain return values, but the missing safety and targeting context is significant.

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 should compensate. "By package name" does add meaning for the required package parameter (fully qualified package identifier implied), but the optional device parameter is completely unexplained in both schema and description, leaving a real gap.

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 ("Uninstall an app"), which is unambiguous and clearly distinct from install_apk. However, it does not clarify how it differs from stop_app, the closest sibling, which also terminates a running app but without removing it.

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 stop_app or install_apk, and no prerequisites such as the app needing to be installed or a device needing to be selected. The agent must infer usage 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?

With no annotations, the description carries the full load: it discloses the polling/waiting behavior, a 120000 ms ceiling on timeout_ms, and that the result is a settled snapshot. It omits what happens on timeout (error vs. last snapshot), whether matching is exact or substring beyond 'somewhere on screen', and whether any device/session prerequisite applies.

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 condition front-loaded and the timeout bound parenthesized inline. No waste, though the return-value clause could carry more 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?

An output schema exists so return values needn't be explained, which the description respects. Still, for a blocking wait tool with no annotations, the absence of failure/timeout semantics and any `device` explanation leaves a meaningful gap before an agent can call it confidently.

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 clarifies `text` (matched anywhere on screen) and adds a real constraint to `timeout_ms` (max 120000, default implied by schema), but the `device` parameter is never explained at all, leaving a third of 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?

States a specific verb and condition: wait until `text` appears on screen, with an example motivating it. It implicitly distinguishes itself from the immediate `snapshot` sibling by noting it returns the 'settled snapshot', though it never names the alternative outright.

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 use case (after a slow screen transition), which implies when to prefer this over a plain snapshot. However there is no explicit when-not guidance, no mention of what to do if the text never appears, and no sibling named as an alternative.

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 description discloses what identifiers are returned and implies a read-only diagnostic check, which is useful context. However, with no annotations, it does not explicitly confirm absence of side effects, permission requirements, or other behavioral 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?

Two sentences, front-loaded with the core purpose and followed by a practical use case. No unnecessary wording.

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 in detail. The description still names the key returned identifiers and gives enough context to call the zero-parameter tool correctly.

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 are zero parameters, so there is no parameter semantics to explain. The baseline for a no-parameter tool is 4.

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?

Uses a specific verb ("Show") and names the exact resources returned: account/tenant, key id, and accessible device ids. It is clearly an identity/diagnostic tool and distinguishable from the device-control siblings, though it does not explicitly contrast itself with them.

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

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

Provides a clear usage context: "Handy to check the API key works." This tells the agent when the tool is useful, but it does not state exclusions or name alternatives.

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