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

With no annotations, the description carries the full behavioral burden, but it does disclose the single most important trait: the tool raises/returns a failure rather than a boolean, which is non-obvious for an assertion helper. It is silent on timing (is it instantaneous?), retry behavior, timeout, and the actual error shape.

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

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

One short sentence, front-loaded with the failure condition and no filler. It is terse rather than wasted, though the terseness shades into under-specification.

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 prose, but for a mutation-free assertion tool with no annotations and 0% parameter coverage the description should still cover synchronization semantics and the device parameter. As written it is too thin for an automation precondition check.

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 conveys what app_id means (the package/identifier expected in the foreground) but says nothing about the second parameter, device, leaving half the parameters undocumented in both schema and 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 states a specific outcome: it fails unless the given app_id occupies the foreground. That is more precise than a restatement of the name 'assert_on', and an agent can infer it is a precondition check rather than a query. It does not, however, name the neighboring concepts it should not be confused with (current_app_id, wait_for_app, validate_action).

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 this over current_app_id (which reads the foreground app), wait_for_app (which waits for an app to appear), or validate_action. The agent must infer the usage context entirely from the word 'fail'.

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, and it does disclose the core behavior: the tool fails rather than merely returning, and it blocks for up to timeout seconds. It does not say how failure surfaces (exception vs. error result), whether it polls or waits once, or what happens on timeout expiry beyond 'fail'.

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 assertion condition and the timing constraint both land immediately.

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-shape explanation is not required, but for a 3-parameter assertion tool with no annotations and 0% schema description coverage, leaving the device parameter and text-matching semantics unexplained is a real gap. It is minimally 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 coverage is 0%, so the description must compensate; it names 'text' and the timeout semantics ('within timeout seconds') but gives no matching rules for text (exact, substring, regex, case sensitivity) and never mentions the 'device' parameter or the 5-second 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 (assert/fail) against a specific resource (text visible on screen) with the timeout condition, so the agent knows this is a blocking assertion, not a passive wait. It does not, however, name or contrast itself with close siblings like wait_for_text, assert_on, or verify_action.

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 assertion versus wait_for_text, assert_on, or verify_action, nor any prerequisite (e.g., app must be foregrounded, screen state must be settled). The agent must infer usage from the 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?

No annotations are provided, so the description carries the full behavioral-disclosure burden. It implies an informational query but does not state that it is read-only, whether it has side effects, or what permissions it requires. This is a significant gap for an agent deciding whether invoking it is safe.

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 short and economical, so it is not bloated. However, it is a sentence fragment rather than a structured, front-loaded explanation, and its brevity comes at the cost of clarity.

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. Still, with no annotations, 0% parameter coverage, and no usage guidance, the description is incomplete for helping an agent invoke the tool correctly in the context of many sibling 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 description coverage is 0% for the single optional 'device' parameter, and the description does not explain what the parameter accepts or how omitting it affects the result. The phrase 'this device' hints at device scoping but does not add real semantic meaning beyond the schema.

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

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

The description names the information categories ('Backend, platform and the actions this device supports'), which gives some sense of what the tool returns. However, it does not use a specific verb or resource action, and it does not distinguish this tool from siblings such as 'supports'. The purpose remains somewhat vague.

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

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

There is no guidance on when to use this tool, when not to use it, or which sibling tool is the appropriate alternative. The description provides no context for selecting it over related tools like 'supports' or 'get_device_status'.

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, and it discloses almost nothing: it does not say whether the whole field is emptied or one character removed, whether it requires prior focus, what error occurs if nothing is focused, or whether the action is reversible.

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

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

A single front-loaded sentence with no filler, which is appropriate for a simple action tool. It is arguably too terse, but nothing is wasted or buried.

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

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

An output schema exists, so return values need not be explained. However, for a tool with no annotations and an undocumented 'device' parameter, the description leaves the agent without enough information to invoke it confidently or predict its effects.

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

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

The schema has one parameter ('device') at 0% description coverage, and the description says nothing about it — not its purpose, format, or what the null default implies. With a single undocumented parameter, the description fails to compensate for the coverage 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 ('clear') and resource ('the focused text field'), so an agent knows exactly what action is taken. It does not need sibling differentiation since no other sibling clears text input, but it also adds no scoping detail beyond the name/title.

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 'focused text field' implies the precondition for use (a field must currently hold focus), which is useful context. However, there is no explicit when-to-use guidance, no mention of alternatives, and no statement of what happens when no field is focused.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It implies reconnection is idempotent and recovery-oriented, but does not explain side effects, prerequisites, failure behavior, or whether the operation disconnects before reconnecting.

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 that communicates the action and the trigger condition with no filler. Every part earns its place.

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

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

For a low-complexity tool with an output schema, the description is mostly adequate: it says what the tool does and when to use it. However, it leaves the optional device parameter's default behavior and the meaning of 'Portal' unexplained, so an agent may still be uncertain on some edge cases.

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 the description only says 'for a device,' which adds minimal meaning beyond the parameter name. It does not explain what the device value should be, what null/default means, or what happens 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 states a specific action: (re)connecting adb and the Portal for a device, which distinguishes it from diagnostic siblings like ping_device or get_device_status. The term 'Portal' is somewhat domain-specific and unexplained, but the core verb and resource are 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 description gives a clear usage condition: use it after the network path has recovered. It does not mention alternative tools or explicit when-not-to-use cases, but the recovery context is enough to guide selection.

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

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

No annotations are provided, so the description carries the full burden. It does not say the tool is a read-only query, what happens if no app is in the foreground (null? error?), or how the optional device parameter affects resolution.

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 fragment with no filler. It is efficient, though extremely terse given the tool's role.

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 the description leaves the optional device parameter and the no-foreground-app edge case entirely unaddressed. For a query tool with a nullable input, that gap matters.

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 the description never mentions the sole `device` parameter, which defaults to null. The agent cannot tell whether omitting it targets the current device or something else.

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 scope: the package/bundle id of the *foreground* app. An agent can distinguish this from list_apps or lookup_app. It lacks an explicit verb, but the noun phrase 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?

No guidance on when to call this versus siblings such as list_apps, get_device_status, or wait_for_app. Nothing tells the agent the context in which the foreground app id is useful.

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

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

With no annotations, the description carries the full burden. It does disclose the effect ('drop its session'), which is real behavioral information beyond the name, but says nothing about permissions required, behavior when the device is not connected, or idempotency of a repeated disconnect.

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 efficient sentence with the operation and its target front-loaded; no filler. It is arguably too lean rather than too verbose, which costs it a point on this dimension rather than earning one.

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 need not be explained. However, for a tool where the only parameter is optional with a null default, the description leaves the no-argument case (disconnect all vs. error) undefined, which is a material gap 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% and the single parameter is a bare anyOf(string, null) with default null. The description compensates by revealing the expected 'host:port' format, but it does not explain what omitting the optional device argument does.

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 (disconnect) and resource (TCP/IP adb device), and even names the underlying command it maps to (adb disconnect host:port). It does not explicitly name connect_device as the inverse sibling, so it stops short of full sibling 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 rather than stated: the 'TCP/IP adb device' qualifier tells the agent this is for network-attached devices, not USB ones, and the counterpart connect_device exists in the sibling list. No explicit when-to-use, prerequisites, or when-not guidance is given.

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 of behavioral disclosure. It mentions 'clearable' but does not explain side effects, irreversibility, permissions, or how the tool handles the clear_all flag. It does not disclose whether dismissing is destructive or if it affects other system 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?

The description is a single efficient sentence, front-loaded with the main action. It avoids fluff and directly states the core functionality. However, it is so terse that it under-specifies important details, but that is a completeness issue rather than a structure issue.

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

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

Given 5 parameters and no annotations, the description is incomplete. It does not explain the selection logic clearly, omits the device parameter, and does not describe return values or error conditions. The existence of an output schema does not compensate for the lack of parameter and usage context.

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 explain parameters. It mentions key, package, title, and clear_all indirectly ('every clearable one'), but the phrasing 'by key, or package/title' is ambiguous about how selectors combine. The 'device' parameter is entirely unmentioned, and the logic for when clear_all applies is unclear.

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 clearly states the action (dismiss) and the resource (notification), and distinguishes two modes: single (by key or package/title) or all clearable. It is specific and understandable, though it does not explicitly contrast with sibling tools like notification_action.

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 is provided on when to use this tool versus alternatives such as read_notifications or notification_action. The description implies usage (dismissing notifications) but does not offer exclusions or context about when to prefer this over related tools.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does almost none of it. It doesn't say whether the check is read-only or side-effecting, whether it starts/restarts the Portal, how long it takes, or what failure modes look like — all of which matter for a multi-component diagnostic.

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

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

One short sentence with the purpose front-loaded; the parenthetical CLI hint adds a little orientation without bloat. Slightly terse given the tool's scope, but no wasted words.

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-value detail is not required. However, for a multi-component diagnostic with an undocumented device parameter and no annotations, the description leaves lingering questions about behavior and scoping that the structured fields do not answer.

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

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

The single 'device' parameter has 0% schema description coverage and a null default, and the description only refers to 'the device' in passing without explaining what supplying or omitting it does (e.g., check all devices vs. one). It adds essentially no meaning beyond the schema.

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

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

States a specific action (health check) and enumerates the three things checked: adb, the Portal, and the device. It's a clear verb+resource, but it does not differentiate itself from diagnostic-looking siblings like get_device_status, ping_device, or capabilities, so an agent cannot tell which diagnostic to pick.

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

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

No when-to-use guidance is given. With siblings such as get_device_status, ping_device, and capabilities in the same list, the description never says when a full doctor run is preferable to a cheaper single-target check, nor does it state any preconditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the tool name. It omits whether the double-tap is synchronous, how long to wait, whether it requires an active device, or what side effects occur.

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 single sentence is front-loaded and free of filler, but it is under-specified rather than appropriately sized for a four-parameter action tool.

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

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

Because an output schema exists, return values need not be explained. However, the description is not complete for a gesture tool with no annotations and undocumented parameters: usage alternatives, device semantics, and behavioral expectations are missing.

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

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

Schema description coverage is 0% for four parameters. The description hints that x, y, and a mark (likely som_id) are inputs, but it leaves device completely unexplained and gives no coordinate system, range, or format for the mark.

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: double-tapping at coordinates or a mark. It is clearly distinguishable from unrelated siblings like volume_up or open_file, but it does not differentiate itself from tap, long_press, or tap_node, so it falls short of a 5.

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

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

There is no guidance on when to use double_tap instead of tap, long_press, tap_node, or tap_text. No prerequisites, timing considerations, or exclusion conditions are given.

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

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

With no annotations provided, the description carries the full burden and does disclose the key behavioral trait: output is verbatim input, with no device interaction or side effects. It is transparent about being a no-op diagnostic, though it says nothing about error behavior if the transport is down.

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 that states the behavior first and the purpose second, with zero 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?

An output schema exists, so return values need not be explained, and the tool is trivially simple. The description is nearly complete for its complexity; the only missing piece is guidance on the two input parameters.

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?

Two parameters ('text' and 'message') have 0% schema description coverage, and the description does not mention either one. It is unclear which parameter actually supplies the echoed value or how the two interact (defaults suggest both optional), so the description fails to compensate for the schema 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 behavior ('Returns text verbatim') plus the operational purpose (transport liveness check). The parenthetical '(no device access)' distinguishes it from the many device-touching siblings like ping_device, read_screen, or get_device_status.

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 tool as a liveness/transport check and rules out device access, which tells an agent when to reach for it over device tools. It stops short of naming an alternative or stating when not to use it, but the context 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 and does so well: it discloses that the server keeps listening and the next call starts fresh, enumerates the accepted outcome values, and spells out the validation gates (screen read required after certain goal types, findings must meet the plan's target_count). These are exactly the behavioral traits an agent could not infer from the schema.

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 most important and surprising fact — that the server keeps listening — is front-loaded in the first clause, followed by parameter semantics. Content is dense and mostly earns its place, though the goal_type enumeration list and the refusal rules make it a fairly long block of prose rather than tightly chunked guidance.

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 description covers the refusal semantics an agent must anticipate. The remaining gap is that 'device' and the reason-versus-summary distinction are never explained, which matters for a tool that can be called against a specific target device.

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 the three semantically rich parameters: reason (short summary), outcome (success/partial/failure with definitions), and goal_type (an explicit enum list absent from the schema). It does not explain the 'device' parameter or the difference between 'summary' and 'reason', leaving two of five 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 opens with a precise verb+resource statement ('Mark the end of the task') and immediately clarifies the non-obvious scoping behavior ('the server keeps listening; the next call starts fresh'), which prevents an agent from assuming the session terminates. No sibling tool competes for this purpose, so differentiation is inherent. The definition is unambiguous about what the tool does.

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 explicit invocation rules — when success is refused (no screen read after send_message/send_email/purchase/post; fewer findings than the plan's target_count) and that failure is never refused. That is strong, actionable conditional guidance. It stops short of stating when not to call end_session at all (e.g., before completing the plan) or naming alternatives, so it is not a full 5.

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

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

With no annotations, the description carries the full burden. It discloses that execution targets the foreground page and returns a JSON result, but says nothing about side effects, permissions, whether it can hang on arbitrary JS, or error behavior for a powerful script-execution primitive.

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 verb and target are stated immediately.

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 2-parameter script-execution tool with no annotations and no output schema, the description omits the meaning of `device`, safety/permission context, and how errors or non-JSON returns are handled. It is too thin for the tool's power.

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 does not. The `device` parameter is entirely unexplained — nothing tells the agent what a device identifier means here or that a null default targets the active device. Only the `js` parameter is loosely implied by 'run JavaScript'.

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 (Run/Execute) and resource (JavaScript in the foreground browser page), which distinguishes it from UI-interaction siblings like tap or ui_json. However, it does not cross-reference any sibling tool, so selection between it and other script/UI tools 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?

There is no indication of when to prefer running script versus using the dedicated UI tools (ui, tap_text, find_nodes), and no stated prerequisites or exclusions. The agent is given no routing guidance.

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

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

With no annotations, the description carries the full burden and discloses useful behavior: result ordering (newest first), a default limit of 10 with a hard cap of 25, and that results are content:// URIs. It does not mention permission requirements, empty-result behavior, or cost/performance, so it is not complete, but it goes well beyond the bare schema.

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?

Dense, front-loaded and free of filler, with the primary mode stated first and the path-based alternative last. The telegraphic 'kind: image | video | ...' fragment is compact but slightly terse for a prose description.

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-value detail is not required, and the tool is a moderately complex 6-parameter search. However, two parameters (device, max_depth) are undocumented in both schema and description, and the path-vs-index interaction could be clearer, so an agent lacks full information to invoke it precisely.

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 for most parameters: 'kind' enum values (image | video | audio | document | any), 'limit' default and cap, 'path' semantics, and 'query' implied by searching 'by name'. 'device' and 'max_depth' receive no explanation anywhere, leaving two of six parameters opaque.

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 ('Search the device's media index by name') plus scope (images, videos, audio, documents) and ordering (newest first). It is clearly distinguishable from screen/UI siblings like find_nodes or perceive_screen, and it names the downstream consumer (open_file) of its results.

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 clear operating context: default search covers media types with downloads included, and supplying 'path' switches to a shared-storage folder search of any file type. It links output to open_file as the follow-up tool, but never states when NOT to use this versus alternatives like web_search or 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?

With no annotations, the description carries the full burden, and it does disclose two meaningful behaviors: filters are ANDed ('matching every given filter') and off-screen nodes are included. It says nothing about read-only safety, result ordering, duplicates, or behavior when no filters are supplied (all nine parameters are optional).

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 that front-loads the resource and matching rule, with the off-screen qualifier placed where it reads as a differentiator. 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?

An output schema exists, so return values need no explanation here. However, for a nine-parameter tool with zero schema descriptions and no annotations, the description omits the 'tree' and 'device' inputs and gives no explicit routing guidance against find_nodes_on_screen or get_ui_tree.

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 for most of the surface: it names text, desc, resource_id, class_name and the *_contains variants and explains exact-vs-substring semantics. It leaves two parameters, 'tree' and 'device', completely unexplained, which is a notable gap for an object-typed parameter.

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

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

The description gives a specific verb (find) and resource (nodes) plus the matching semantics: exact match on text/desc/resource_id/class_name or substring via *_contains. The clause 'including off-screen ones' implicitly distinguishes it from the sibling find_nodes_on_screen, though it never names that sibling.

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: an agent can infer this is the right tool when it wants nodes outside the current viewport, and that all filters are conjunctive. There is no explicit statement of when to prefer find_nodes over find_nodes_on_screen, get_ui_tree, or wait_for_nodes, nor any mention of required preconditions.

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, yet it discloses nothing beyond scope. It says nothing about what the operation returns, performance, truncation, or permission requirements for a 9-parameter query 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?

A single tight sentence with the scope constraint front-loaded and no filler. It is efficient, though it is arguably too terse to earn maximum credit for a 9-parameter tool.

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

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

An output schema exists so return values need not be explained, but with no annotations and zero schema descriptions on 9 parameters, the description leaves the agent without the semantics needed to call the 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?

Schema description coverage is 0% across 9 parameters, so the schema provides no meaning. The description adds only that results are screen-limited, giving no guidance on desc, text, tree, device, class_name, resource_id, or any of the *_contains filters.

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 clear operation (find nodes) and scopes it to the visible screen, which distinguishes it from the sibling find_nodes. However, it defines itself relative to find_nodes rather than describing what a 'node' is or what is returned, so an agent must already understand find_nodes.

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 'limited to nodes inside the visible screen' implicitly tells when to prefer it over find_nodes (when off-screen nodes are irrelevant), but there is no explicit when/when-not guidance or mention of alternatives by 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 must carry the full behavioral burden. It usefully discloses the Android requirement for the Mobilerun Keyboard as active IME, but omits other behavioral details such as read-only nature, error conditions when clipboard is empty, or permission needs.

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 very short, front-loads the resource, and includes the Android prerequisite without wasted words. It is a sentence fragment, but structure is efficient for the small amount of content.

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

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

The tool is simple, and the output schema exists, so return values need not be explained. However, the description omits any explanation of the optional 'device' parameter and provides no routing to the set_clipboard sibling, leaving gaps 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?

The sole parameter 'device' has 0% schema description coverage and the description does not mention it at all. No meaning is added beyond the raw schema type and default, so the description fails to compensate for the low coverage.

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 the specific resource returned ('the clipboard's text'), making the tool's purpose clear despite lacking an explicit verb. It adds an Android platform caveat but never contrasts with the sibling set_clipboard, so full sibling differentiation is absent.

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 does not say when to use this tool versus alternatives like set_clipboard or other clipboard-related operations. The Android IME note is a prerequisite, not usage guidance for selection between tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does convey what the report contains (a state snapshot across seven dimensions), which is useful. However, it does not disclose prerequisites (e.g., a connected device), the meaning or behavior of the null device default, failure modes, or confirm the read-only nature beyond what the name 'get' implies.

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 eight words long with zero wasted tokens; every term carries information about the returned status. For a one-parameter read tool this is an appropriately minimal size, though the lack of a verb is a structural weakness already accounted for in purpose clarity.

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?

Complexity is low: one optional parameter, an existing output schema, and a clear field list, so an agent can likely invoke it correctly with no arguments. Still, there are clear gaps — no usage routing against the many siblings and no explanation of the device parameter or null behavior — making it adequate but incomplete.

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 was expected to compensate by explaining the device parameter, yet it is entirely silent on it. The schema's string/null type and default null weakly suggest an optional device selector, but the description adds no meaning about device identifiers or what null resolves to, so it misses the only parameter entirely.

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 is a fragment listing seven concrete status dimensions (battery, screen power, foreground app, size, storage, network addresses, volume), so it clearly conveys what the tool reports and avoids tautology. The verb must be inferred from the tool name since no verb is present, and the field list implicitly separates this state/health read from pixel- or UI-tree-focused siblings like get_screenshot, read_screen, and get_ui_tree, though no sibling is named 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?

The description offers no guidance on when to use this tool versus alternatives such as read_screen, get_ui_tree, ping_device, or volume_up. It names no alternatives, gives no exclusions, and never states that this is the read-only status query among the many action-oriented sibling tools; the intended usage is only implied by the tool name and the field list.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It lists the output contents but does not say whether the operation is read-only, whether device defaults to the active device, what include_system changes, or whether any side effects occur. Basic output information is present, but behavioral context is largely missing.

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 terse sentence with no filler and the core resource is front-loaded. However, it is so abbreviated that it reads like a fragment rather than a complete sentence, and it omits parameter context. Still, the structure itself is efficient.

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?

Despite having an output schema, the description leaves the two optional parameters unexplained and provides no usage context or behavioral notes. It is minimally acceptable for a simple getter, but for a tool that accepts a device selector and an include_system flag, the description is incomplete.

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 the description does not mention either parameter, device or include_system, at all. The parameter names offer limited hints, but the description adds no meaning about device targeting or what including system sessions would mean. This is a significant 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?

The description identifies the resource (media sessions and music volume) and the specific payload fields (app, playback state, title/artist), which clearly distinguishes it from sibling control tools like media_control or volume_up. It lacks an explicit verb like 'retrieves' or 'returns', but the tool name supplies the action, so the purpose is still 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?

No guidance is given about when to use this tool versus siblings such as media_control, volume_up, or get_device_status. The description implies it is a read action, but it does not state exclusions, prerequisites, or alternative conditions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says the result is an image; it does not mention permissions, device applicability, side effects, failure modes, or whether the screenshot reflects the current screen. This is minimal disclosure 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?

The description is short and front-loaded with its main point, but it is under-specified rather than appropriately concise. The single sentence sacrifices essential usage and parameter information for brevity.

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 tool with one parameter, no output schema, and no annotations, the description should explain the device parameter and distinguish the tool from similar screenshot siblings. It does neither, leaving the agent without enough information to invoke the 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?

The input schema has one optional device parameter with 0% schema description coverage, and the description does not mention this parameter at all. The description completely fails to explain what device means, how it should be specified, or what the default behavior is.

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 clearly states that the tool produces a screenshot as an image, giving the agent the resource and output form. However, it does not distinguish get_screenshot from sibling tools like screenshot, screenshot_path, or browser_screenshot, 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 guidance is given about when to use this tool versus alternatives such as screenshot, perceive_screen, or read_screen. The word 'plain' weakly implies a raw image without analysis, but there is no explicit when-to-use or when-not-to-use 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?

With no annotations, the description carries the full burden. It adds that the tree is 'compact' and lists output fields, but does not disclose how accessibility data is obtained, what happens when the tree is unavailable, whether permissions are needed, or how max_depth affects results. These are significant behavioral 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?

The description is a single dense sentence with no filler and the key output concept is front-loaded. The field list is compact and informative, though the brevity comes at the cost of missing guidance.

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 structure, so explaining field contents is less critical. However, with zero annotations and zero parameter documentation, the description is too sparse to fully support correct invocation; it lacks device handling, depth semantics, and sibling differentiation.

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 undocumented device and max_depth parameters. It does not mention either parameter, leaving an agent unable to infer device selection or depth behavior from 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 identifies the resource (accessibility tree) and specifies the exact contents: class, id, label, flags, and bounds. It is not a tautology, but it does not differentiate from sibling tools like read_screen or perceive_screen.

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

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

No guidance is given on when to use this tool versus alternatives such as get_screenshot, read_screen, or perceive_screen. The description provides no context about suitable scenarios or exclusions.

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

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

No annotations are provided, so the description carries the burden, but for a read-only documentation tool the risk surface is small. It does disclose the set of valid topic values, which is real behavioral information; however, it never states that the call is non-destructive, whether unknown topics error, or what the default (null) topic yields.

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 purpose followed by the topic list; no filler. The raw enumeration is dense but each token is the valid input value, so it earns its place.

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

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

An output schema exists, so return formatting need not be described. Still missing for a zero-annotation, zero-coverage-parameter tool: behavior on omitted or invalid topic, and any hint of when this guidance is worth fetching.

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 the single topic parameter has no schema description, no enum, and accepts any string. The description partially compensates by enumerating the valid topic names (overview, shortcuts, text_entry, failures, ledger, safety, stop, efficiency, full), but it does not say which topic is default or what happens for an unrecognized value.

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 what the tool returns ('How to use this server well') and enumerates the available topics, so an agent knows this is a self-documentation/help lookup rather than an action tool. It is distinguishable from siblings like capabilities or supports, though it doesn't explicitly contrast 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?

Usage is implied by 'How to use this server well' — call it when guidance is needed — but there is no explicit when-to-use statement, no indication of when to call this versus capabilities/supports, and no note that it is safe to call speculatively.

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 disclosure burden. It says a grant occurs, but does not state whether the grant persists, whether it requires special device privileges, whether it can fail for undeclared permissions, or what side effects occur. It discloses only the basic mutation target.

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 redundant clauses. It is appropriately terse for a simple grant action, though the brevity contributes to the missing guidance elsewhere.

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

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

For a 3-parameter mutation tool with no annotations and no parameter descriptions, the description is incomplete. An output schema exists, so return values need not be explained, but the lack of device-parameter mention and prerequisite behavior leaves significant gaps 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. It adds useful meaning for the permission parameter by giving the android.permission.* format and implies the package parameter via 'to an app', but it completely omits the optional device parameter and any package format details.

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 (Grant) and resource (runtime permission) and scopes it to an app via the android.permission.* format. It clearly distinguishes itself from the related request_screen_capture_permission tool, though it does not explicitly name that sibling.

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

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

There is no guidance on when to use this tool versus alternatives such as request_screen_capture_permission or general app-management siblings. The description gives no prerequisites, no when-not conditions, and no indication of required state (e.g., app must be installed, permission must be declared).

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 notes the APK path is a host path (useful), but says nothing about whether an existing install is replaced, that grant_permissions defaults to true, whether this is destructive, or what permissions/auth are needed for a mutating install operation.

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

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

A single front-loaded sentence with no filler, and the host-path clarification is placed inline where it matters. It is efficient, though the brevity contributes to the specification gaps noted elsewhere.

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

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

An output schema exists, so return values need not be described. However, for a 4-parameter mutation tool with no annotations and 0% schema coverage, the description omits the behavioral and parameter details an agent needs to invoke it 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?

Schema description coverage is 0% across 4 parameters. The description clarifies only that 'path' refers to a host-side APK; 'device', 'replace', and 'grant_permissions' (and its default of true) are left completely unexplained in both schema and 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 states a specific verb (Install) and resource (an APK on the device), which is clear enough to separate it from siblings like uninstall_app, launch_app, and start_app. It does not explicitly name or contrast those siblings, which keeps it short of a 5.

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

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

There is no guidance on when to use install_app versus launch_app/start_app, nor any prerequisite context such as whether the device must be connected or whether the app must be absent first. 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?

No annotations are provided, so the description carries the full behavioral burden, but it only enumerates accepted inputs. It says nothing about side effects (key events injected into the active app/window), whether a device must be specified, or error behavior for unrecognized names.

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 accepted value formats after. No filler, though the trailing ellipsis leaves the name list open-ended.

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 the primary input's format is explained. However, for a tool with 0% schema coverage and no annotations, the unexplained device parameter and absent routing guidance leave it only minimally complete.

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

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

Schema description coverage is 0% and there are two parameters. The description does add real meaning for name_or_code (enumerated mobilerun-core names and the Android keycode number form), which the schema alone would not convey. It says nothing about the 'device' parameter, so it only half-compensates for the coverage 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 (press) and resource (a keyboard/device key) and enumerates the accepted key names plus the Android keycode alternative. It does not, however, differentiate itself from the many sibling press tools (press, press_home, press_back, press_enter, volume_up, volume_down).

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 generic key tool versus the specialized siblings press_home, press_back, press_enter, volume_up or volume_down. No prerequisites or context are given; the agent must infer all routing decisions.

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 a good job: it discloses fuzzy matching, the disambiguation strategy (ranked candidates rather than a guess), and the idempotent foreground check with the force override. It omits failure modes (app not installed / no match) and any permission considerations, which are the notable remaining 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?

Three short sentences, front-loaded with the primary action and lookup modes before the edge-case behavior. 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?

An output schema exists, so return values need not be explained. For a launch/mutation-style tool with zero annotations, the description covers matching semantics, disambiguation, and the foreground/force interaction adequately; only the device parameter and error behavior are left unaddressed.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate, and it only partially does: it clarifies that app_name is fuzzy and package_name is exact, and explains force. It says nothing about device, and the schema also exposes an undocumented 'package' parameter that the description never mentions or reconciles with package_name.

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

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

States a specific verb and resource ('Open an app') and names the two accepted lookup forms (fuzzy app_name vs. exact package_name). It does not distinguish itself from the sibling start_app or lookup_app, so an agent still has to infer which launcher to pick.

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

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

The description gives useful conditional behavior (ambiguous names return ranked candidates instead of guessing; already-foreground is a no-op unless force=true), which implicitly tells the agent when the call is safe. However, it never says when to prefer this over start_app, open_deeplink, or open_and_settle, all of which appear to overlap.

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 adds genuine value by defining the source priority (shortcut > resolved > catalog > discovered) and ranking ('best first'), which is non-obvious context. However, it says nothing about the safety profile, whether results are cached, or how many links are returned, leaving meaningful behavioral gaps for an annotation-free tool.

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

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

One front-loaded clause states the purpose and ranking, followed by a compact legend of source tiers. Every element carries information, though the run-on source list with nested parenthetical is dense and slightly harder to parse than it needs to be.

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-value explanation is unnecessary. But for a four-parameter tool with zero schema descriptions, the definition leaves the agent without guidance on how to identify the target app or device, which is a real completeness gap even though the purpose and ordering are well covered.

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 four parameters (device, package, app_name, package_name), so the schema does not compensate. The description never explains these parameters or how app identity should be supplied (e.g., package vs app_name vs package_name); the stray 'pkg' in the URL example is incidental, not documentation.

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

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

The fragment 'Deep links into an app, best first' clearly conveys that this tool retrieves deep links for an app and returns them in ranked order. The specific resource and the ordering behavior are stated. It does not explicitly distinguish itself from siblings like resolve_deeplink or open_deeplink, keeping it just shy 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 only implied. The mention that a shortcut link can be opened 'with open_deeplink' gives a weak pointer to a sibling, but there is no explicit statement of when to choose this listing tool versus resolve_deeplink/open_deeplink, and no exclusions or prerequisites.

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

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

With no annotations, the description carries full burden and does disclose the default filter (user apps only) and a platform-dependent limitation (include_protected_apps only honoured on Mobilerun Cloud). It omits other relevant behavior: whether a device must be connected, whether the result set is paginated, and error behavior on unreachable 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?

Two short sentences, both front-loaded with the most decision-relevant facts (default scope, then the platform caveat). No filler, though the protected-apps aside is parenthetical and slightly cryptic in its mobilerun-core reference.

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 four-parameter read-only listing tool, the description covers the default filtering behavior and the one platform-specific constraint; the remaining gap around the `device` parameter is minor given the schema's anyOf/default null structure.

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 all four parameters lack inline documentation, and the description compensates for only part of that: it explains include_system_apps and include_protected_apps semantics. The `device` parameter (format/selection) is never addressed, and the relationship between the `system` and `include_system_apps` booleans is left unreconciled despite looking redundant.

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 clear verb+resource ('List installed apps') and immediately qualifies the default scope (user apps only). It is distinguishable from siblings like lookup_app, install_app, and list_app_deeplinks, though it never names 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?

The description gives the condition that changes default behavior (include_system_apps=true) and notes the cloud-only constraint for protected apps, which is useful operational guidance. It does not, however, say when an agent should prefer this over lookup_app or list_app_deeplinks, leaving sibling selection implied.

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

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

With no annotations, this description carries the full burden and does well: it discloses the auth prerequisite for cloud scope and, importantly, that any listed device id is valid as the device argument of every other tool — a non-obvious behavioral contract. It stops short of describing pagination behavior or result volume.

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 resource, then scope semantics, then filters, then the cross-tool id note. It is dense and largely waste-free, though the pipe-delimited fragments read slightly telegraphically.

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 an 8-param tool with no annotations, the description covers scope, auth, filters, and the downstream use of returned ids; an output schema exists so return values need not be spelled out. Only pagination semantics and default behavior with no arguments 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 coverage is 0%, so the description must compensate, and it largely does: it names scope values, the cloud filter fields (state, type, name, country, page, pageSize, filters dict), and enumerates several state values. Only the precise behavior of the filters dict and defaults are left implicit.

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 identifies the resource ('Devices you can control') and, paired with the name list_devices, the operation is unambiguous. It does not need to differentiate from siblings since no other tool enumerates devices, but the fragmentary phrasing never states the verb outright, keeping it 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?

Explicitly tells the agent how to choose between the local, cloud, and all scopes, and flags that cloud requires MOBILERUN_CLOUD_API_KEY. It offers no exclusions or negative guidance (e.g. when not to call it), so it lands at a clear-context 4.

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 surface the default hold time (1000 ms) and both duration parameter aliases. However, it says nothing about what a long press actually triggers (context menus, deletions, drag initiation), permission needs, or the device parameter's effect, which is a meaningful gap for an interaction tool with destructive potential.

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, front-loaded with the action and targeting options before the timing detail. Every clause carries information not available elsewhere in structured form.

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

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

An output schema exists, so return values need no explanation. But for a 7-parameter, zero-coverage, annotation-free interaction tool, the description leaves 'device' undocumented and does not clarify mode precedence or the behavioral consequence of the hold, leaving 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 coverage is 0%, so the description must compensate, and it does for most parameters: x/y coordinates, som_id as 'a mark', index as 'a get_state element', and critically the ms/duration_ms alias and default of 1000 ms, none of which the schema conveys. It omits the 'device' parameter entirely, and does not state that the targeting modes are mutually exclusive alternatives.

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: 'Press and hold' with three concrete targeting modes (coordinates, som_id mark, get_state index). It is clear on its own, but it never distinguishes itself from the near-identical sibling 'long_press_at', which an agent must choose between.

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

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

There is no when-to-use guidance, no statement of which targeting mode takes precedence, and no routing to or away from alternatives such as 'press', 'tap', or the sibling 'long_press_at'. The agent must infer usage entirely from the gesture 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 behavioral burden, yet it discloses nothing about press duration, whether a context menu or drag is triggered, permission requirements, or reversibility. The critical behavioral property of a 'long press' (how long, what it triggers) is absent.

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

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

A single short sentence, front-loaded with the action. The trailing '(mobilerun agent action)' parenthetical is filler that adds no selection value but costs little.

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, but the description still omits the undocumented 'device' parameter and any behavioral detail for a mutation-like gesture tool with zero annotation coverage.

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 3 parameters. The description only echoes the required x/y coordinates and says nothing about the optional 'device' parameter, so it fails to compensate for the schema 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 (long press) and resource (a coordinate pair), which implicitly separates it from the node-based 'long_press' sibling. Sibling differentiation is implied by '(x, y)' rather than stated, but an agent can infer the distinction.

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

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

No guidance on when to use this versus 'long_press', 'tap', or 'double_tap'. No prerequisite or context conditions are given beyond the required coordinates.

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

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

No annotations are supplied, so the description carries the full behavioral burden, and it delivers only that results are ranked with scores. It does not state read-only nature, permission requirements, whether an empty result is an error, or any rate/behavioral constraints. Ranking/scores is a genuine addition but far short of what an unannotated tool needs.

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 compact sentence with the search target front-loaded and the return behavior appended. Nothing is wasted, though it is arguably too sparse for a four-parameter tool rather than elegantly brief.

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. But with zero annotation coverage and four entirely undocumented parameters, the description omits the parameter disambiguation an agent needs to call this correctly, leaving it materially incomplete.

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 four parameters (limit, query, device, app_name). The description's 'by name or package' loosely gestures at query/app_name but never clarifies the difference between those two overlapping inputs, what device scopes, or what limit controls. It does not compensate for the coverage 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 (search) plus resource (installed apps) and scope (by name or package), and discloses the return shape (ranked candidates with scores). It implies a distinction from list_apps through 'search' and 'ranked candidates', but never names that sibling or any other, so the 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?

There is no explicit when-to-use guidance and no mention of alternatives such as list_apps (enumerate everything) or launch_app/start_app (act on a chosen app). The reader must infer from 'search' that this is the fuzzy-name resolution step before launching.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that screen pixels are ephemeral ('the pixels are gone next turn'), which is a useful context for note-taking. However, it does not disclose other behavioral aspects such as side effects of updating a step, whether the change is reversible, or any permission requirements. It adds some value but remains thin for a state-changing 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 sentences with no wasted words. The purpose is front-loaded, and the note guidance is appended efficiently. Every sentence adds value, and the structure is clean and scannable.

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 has 4 parameters, no schema descriptions, and no annotations. The description covers purpose and the ephemeral screen context, but it omits parameter meanings for index and device, and doesn't describe expected behavior beyond the status update. While an output schema exists (which might define return values), the input semantics are incomplete. For a tool of this complexity, more context is needed.

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

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

Schema description coverage is 0%, so the description must explain parameter meanings. It covers 'status' by listing allowed values and explains 'note' as a place to put facts from the screen. However, it does not explain 'index' (likely the step number) or 'device' (which device to target), leaving two of four parameters ambiguous. The partial coverage is insufficient for a tool with no schema descriptions.

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 clearly states 'Update a plan step' with a specific list of valid status values (pending, in_progress, done, skipped, failed). This is a specific verb-resource pair that distinguishes it from sibling tools like set_plan (which likely creates a plan) and record_finding (which records findings). The purpose 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?

The description implies when to use it (when updating a plan step's status) but provides no explicit guidance on alternatives or when not to use it. It does offer a practical hint about using 'note' for facts read off the screen, which is a usage consideration, but it doesn't contrast with other plan-related tools like set_plan or record_finding. Clear context exists, but no exclusions or alternative 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?

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait — actions are dispatched to the *active* media session, and a supplied package_name is validated against that session and reported — but says nothing about failure behavior when no session is active or mismatched, or about 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?

Two sentences, front-loaded with the primary capability, and the compact action list is tightly packed. No filler, though the enumerated verbs would be more useful if tied to the correct parameter name.

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

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

An output schema exists, so return-shape explanation is not needed. However, with 4 undocumented parameters and an unresolved action/command ambiguity, the definition leaves an agent guessing about the exact call shape despite covering the high-level capability.

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 usefully defines the accepted action vocabulary and explains the origin of package_name (from get_media_sessions), but it never disambiguates the ambiguous 'action' vs 'command' parameters, and leaves 'device' 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 ('Control playback in any app') and enumerates the exact supported actions, so an agent immediately knows it is the media-session control tool. It is clearly distinct from the volume_* siblings, though it does not name 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 implied by 'control playback in any app without touching the screen', and it helpfully points at get_media_sessions as the source of package_name. It does not state when not to use it, nor how it relates to siblings like volume_up/mute.

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 discloses one genuinely useful behavioral trait—that the previous level is remembered for unmute—and clarifies toggle vs. forced state. It does not say which device/session is affected by default, whether it requires permissions, or what happens on an inactive stream.

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 core action and immediately followed by the forcing semantics and the unmute memory behavior. 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?

An output schema exists, so return values need not be described. However, for an unannotated mutation-style control, the description omits device targeting, which stream/session is affected by default, and any permission or failure behavior.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It does a good job on 'muted' (null = toggle, true/false = force), but the 'device' parameter is never mentioned, leaving half the input undocumented in both schema and 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?

Names a specific verb (toggle mute) and resource (the media stream), and clarifies that muted=true/false forces state rather than toggling. It does not, however, distinguish itself from siblings such as media_control, volume_up, or volume_down.

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 resource named ('the media stream') and the toggle-vs-force distinction, but there is no explicit statement of when to prefer this over media_control or the volume tools, and no prerequisites or exclusions are given.

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 usefully discloses that the operation is best-effort and drives the notification shade, and that reply_text sends an inline reply. However, it omits important behavioral context such as prerequisites, failure modes, or side effects.

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

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

The description is compact and front-loaded with the core purpose, followed by a clarifying example and a brief caveat. Every sentence contributes meaningful information without repetition or filler.

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

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

For a tool with six parameters, zero schema descriptions, and no annotations, this description is incomplete. An agent cannot confidently determine how to identify the target notification using key/title/package, nor understand the limitations of the best-effort behavior beyond a vague hint.

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 only explains reply_text and gives examples for action. The key, title, device, and package parameters are left completely unexplained, which is a significant gap since they likely determine which notification is targeted.

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: 'Tap one of a notification's own buttons' with concrete examples like reply, archive, and stop. This clearly differentiates it from generic tapping or notification dismissal tools, though it does not name a sibling tool 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?

The intended use is implied: use when you need to click a notification's embedded action button, and reply_text is for inline replies. However, there is no explicit guidance on when not to use it or which alternative to choose, such as dismiss_notification or type_text.

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, but it does disclose real behavior: the call blocks until the app is foregrounded and idle. It omits failure modes (what happens on timeout, app not installed, permission needed) and does not explain what 'in front' or 'idle' concretely mean, which matters for a tool with side effects.

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

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

A single front-loaded sentence with no filler; the primary action verb comes first and the wait semantics follow. Every word earns its place.

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

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

An output schema exists so return values need not be explained, but for a mutating four-parameter tool with zero annotation coverage and 0% schema description coverage, the definition is thin: it never explains the idle/timeout/device parameters, the failure behavior, or how it differs from sibling start/wait 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 description coverage is 0% and none of the four parameters are documented anywhere. The description's mention of 'idle' loosely hints at the idle parameter but gives no units, thresholds, or meaning, and says nothing about idle/timeout interplay or the device selector.

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 app') plus the completion condition ('wait until it is in front and idle'), which is clearer than a bare name restatement. However, it does not distinguish itself from close siblings such as start_app, launch_app, and wait_for_idle, leaving the agent to guess which entry point is intended.

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

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

No when-to-use guidance is given, and no alternatives are named despite obvious overlap with start_app, launch_app, wait_for_app, and wait_for_idle. The agent must infer that this is a combined start-then-wait convenience tool from the description alone, which is exactly the kind of routing the description should make explicit.

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 never says whether this launches an app, what happens if package_name is absent or wrong, whether the action is safe/reversible, or what permission or device state is required — major gaps for a dispatch/mutation 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?

A single economical sentence, front-loaded with the action verb, with no filler. Slight parenthetical for the default is efficient, though brevity here edges toward under-specification rather than true conciseness.

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

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

An output schema exists so return values need not be explained, but with zero annotations and zero schema descriptions the definition leaves the agent without enough to call this correctly against three close siblings or to predict failure behavior.

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

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

Schema description coverage is 0% across 4 parameters. The description adds meaning for only two of them (action defaults to VIEW; package_name pins the target) and says nothing about the required deep_link's format or what 'device' selects. It only partially compensates for the coverage 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 clear verb+resource ('Dispatch a deep link / intent'), which is more specific than a tautology. However, sibling tools resolve_deeplink and open_deeplink exist, and the description does nothing to distinguish this tool from them, leaving the agent to guess which of the near-identical siblings to call.

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 vs. resolve_deeplink/open_deeplink/system_intent, nor any prerequisites or exclusions. The only usage hint ('default action VIEW') describes a parameter default, not a selection condition.

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 present, the description carries the full burden and does disclose a genuinely useful behavioral constraint: intent:, file:, content: and javascript: URI schemes are refused, plus the pinning role of package_name/app_name. It stops short of stating what happens on launch failure, whether the navigation can leave the device in an unexpected state, or how device selection behaves, so it is strong but not complete.

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 no filler, and the core action is front-loaded ahead of the URI-source hint and the refusal constraint. Every clause carries information an agent can act on.

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. However, for a side-effecting navigation tool with zero annotations and 0% schema coverage, the definition leaves the `package` vs `package_name` distinction and device targeting unresolved, which are real invocation risks.

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% across 5 parameters, so the description must compensate. It covers only package_name and app_name (as app-pinning), and even that leaves the separate `package` parameter completely unaccounted for, creating ambiguity about which one wins. The `device` and `uri` format parameters get no semantic explanation beyond the URI examples.

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

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

States a concrete action and resource: jump to a screen via URI, with the accepted URI families (app-shortcut://pkg/id, intent action) spelled out. It also names list_app_deeplinks as the origin of the shortcut URIs, which helps an agent route between siblings. It does not differentiate itself from the near-identical sibling open_deep_link or resolve_deeplink, which keeps this from 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 rather than stated: use this to go directly to a screen, and get URIs from list_app_deeplinks. There is no explicit when-not guidance and no tie-breaking against open_deep_link, resolve_deeplink, launch_app, or start_app, which an agent would need given how many near-duplicate navigation siblings exist.

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 only names the viewer behavior; it does not disclose permission requirements, whether it launches an external app and disrupts current app state, or what side effects follow. That is thin for an action-launching 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 tightly written sentences, front-loaded with the action and followed by per-parameter guidance. Every clause carries information; there is no filler.

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

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

An output schema exists, so return values need no explanation. However, the undocumented 'device' parameter and the absence of any side-effect or permission context leave gaps an agent would still need to resolve before calling 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 coverage is 0%, so the description must compensate. It usefully documents uri (content://media/... format originating from find_files) and path ('a file under shared storage'), but the third parameter 'device' is undocumented, leaving part of the interface 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?

The description gives a specific verb and resource ('Open a file in its default viewer'), which clearly distinguishes it from lookup siblings like find_files. It does not explicitly name or contrast with alternative action tools (open_deeplink, system_intent), so it stops short of full sibling 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?

It gives a strong sourcing rule for uri ('from find_files, never build one by hand'), which implies the intended workflow, but it never states when to prefer this tool over alternatives like open_deeplink or open_deep_link, nor any preconditions. Usage is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing side effects, prerequisites (e.g., device must be awake), or what happens if no recent apps exist. The optional 'device' parameter hints at multi-device support but the description doesn't explain behavior across 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?

The description is a single short sentence with no wasted words. It is front-loaded with the action. However, it is so brief that it sacrifices useful context, but for what it contains, it is concise.

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

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

Given the tool has an output schema and one optional parameter, the description is minimal. It lacks context about device targeting, prerequisites, and expected outcomes. The output schema may cover return values, but the description doesn't help an agent understand when or how to invoke this 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?

Schema description coverage is 0%, and the description does not explain the 'device' parameter at all. The schema shows it's an optional string/null with a default of null, but the description adds no meaning about what device values are valid or how the parameter affects behavior.

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 ('Open') and resource ('recent-apps overview'), which clearly identifies the tool's function. It distinguishes it from sibling tools like launch_app or open_deeplink, though it doesn't explicitly name alternatives.

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 is provided on when to use this tool versus alternatives like launch_app, press_home, or system_intent. The context is implied by the name and description, but there is no explicit when-to-use or when-not-to-use information.

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