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

The description adds meaningful behavioral context beyond the annotations: 'validated' indicates input checking, 'synchronize' reveals a built-in waiting step, and 'Mutating actions are never blindly retried' discloses retry safety behavior. This complements the existing destructiveHint and idempotentHint annotations without contradicting them.

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

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

Two tight sentences with no filler. The primary purpose is front-loaded, and the safety retry clause is concise. 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?

This tool is complex (nested wait/observe/action objects, multiple enums, no output schema) but the description only provides a high-level summary. It omits essential details like what action methods are available, how wait modes affect behavior, what 'context or diff' contains, and how the tool handles failures. The description is not sufficient for correct invocation without deep schema inspection or external knowledge.

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

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

With 0% schema description coverage and three nested object parameters (action, wait, observe), the description should compensate by explaining what these parameters do. It does not—it only uses the words 'action' and 'synchronize' generically. No parameter names, defaults, enums, or method examples are mentioned, leaving the agent without crucial operational 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 clearly identifies the tool as executing a UI/system action, synchronizing, and returning semantic context or diff in one round trip. It effectively distinguishes this composite tool from dedicated siblings like android_screen_diff, android_wait_idle, and android_ui_click. However, it doesn't explicitly mention the `action` parameter or the `observe`/`wait` options, so the exact mechanism is left to the schema.

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

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

No explicit guidance is provided about when to use this tool versus the many sibling action, wait, and observe tools. The phrase 'one round trip' implies a combined workflow, but the description never states when a single action+observe call is preferable to separate calls or when it should be avoided. There are no exclusions or alternative tool references.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying exactly what is read: package metadata, launchability, version, and requested permissions.

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

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

A single sentence that front-loads the action and lists the returned data categories. There is no filler, and every element helps an agent understand what the tool does.

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

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

For a simple one-parameter read-only tool with rich annotations, the description covers the essential purpose and scope. It does not describe return format or error behavior for missing packages, but the simplicity and safety annotations make this a minor gap.

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

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

Schema description coverage is 0%, and the description does not mention the packageName parameter at all. The parameter is arguably self-explanatory from its name and the tool name, and the schema includes a pattern, but the description itself adds no parameter-level meaning.

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

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

The description uses a specific verb ('Read') and resource ('installed package metadata'), and enumerates the exact data areas covered: launchability, version, and requested permissions. It clearly distinguishes this from siblings like android_apps (listing apps) or android_launch_app (launching apps).

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 context is clear: this tool is for reading details about a single installed package, and the required packageName parameter reinforces that. It does not explicitly name alternatives or exclusion conditions, but the intended use case is readily inferable from the description.

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

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

Annotations already establish the read-only, idempotent, non-destructive profile. The description adds the 'launchable' scope and label/package filtering semantics, but it does not describe matching behavior, sorting, pagination, or how the query interacts with the limit parameter.

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

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

One front-loaded sentence with no filler. It states the action, the resource, and the optional filter in a compact, easily parseable form.

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

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

For a simple list tool, the description is sufficiently complete: it indicates what is returned and when filtering applies. It could add more detail about query matching behavior or point to android_launch_app, but neither is essential for correct selection and 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?

With 0% schema description coverage, the description gives the query parameter meaning by tying it to label/package filtering. The limit parameter is left to schema defaults and its self-descriptive name, so parameter semantics are only partially compensated.

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

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

The description uses a specific verb ('List') and resource ('launchable applications and package names'), and it states the optional filter by label or package. This clearly distinguishes it from action-oriented siblings like android_launch_app.

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 clear context: use this tool to discover launchable apps and package names, optionally filtering by query. It does not explicitly mention alternatives or exclusions, but the read-only discovery role is obvious enough for an agent to select it appropriately.

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

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

Annotations already indicate destructive, non-read-only behavior, and the description adds that operations are validated, limited to 20, executed sequentially, and that certain operation categories are intentionally excluded. This enriches the behavioral picture beyond the annotations, though it does not discuss failure behavior.

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

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

Two sentences with no wasted words. The main purpose is front-loaded, and the exclusion note is a useful, compact scope boundary. Every sentence earns its place.

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

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

For a composite tool with no output schema and no parameter descriptions, the description omits critical details such as failFast behavior, what 'validated' means, what valid method values are, and what the tool returns. An agent cannot fully predict execution semantics without additional information.

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 only adds 'up to 20' and 'sequentially', which mostly restates schema constraints, and it says nothing about failFast, how steps are structured, or what methods are valid. An agent would struggle to construct steps correctly.

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

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

The description clearly states the tool runs a batch of UI/system operations sequentially to reduce round trips, and explicitly lists what is excluded. This gives a specific verb, resource, and scope. It distinguishes itself from single-operation tools, though it does not name a sibling directly.

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

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

The phrase 'to reduce round trips' gives a clear reason to use this tool, and the sentence about exclusions tells agents not to use it for screenshots, shell, or file mutations. It lacks an explicit 'use X instead' alternative routing, but the context is strong enough.

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

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

The annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds a meaningful guarantee: 'No backend is silently escalated,' which clarifies an important behavioral boundary beyond the annotations.

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

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

The description is two concise sentences with no redundant wording. It front-loads the core purpose and adds only the essential behavioral guarantee.

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 no parameters and no output schema, the description is sufficiently complete for an agent to understand what the tool reports and why to call it. It covers purpose, usage context, and a key non-escalation guarantee.

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

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

The tool has zero parameters, so the baseline score of 4 applies. There are no parameter semantics to describe, and the description does not need to clarify inputs.

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

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

The description clearly states the verb 'Report' and the specific resource: runtime feature/backend availability. It also gives the intended purpose, helping an agent choose the least-privileged working path, which distinguishes it from action-oriented sibling tools.

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 the tool: before choosing a backend or working path, to select the least-privileged option. It does not explicitly name alternative tools or provide exclusion criteria, but the purpose is clear enough for appropriate usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond those annotations by specifying that only plain-text clipboard content is read and that Android permission may restrict access, which is useful behavioral context.

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

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

The description is a single sentence that front-loads the action and resource, then adds the key permission caveat. Every word contributes meaning, with no fluff or repetition of schema information.

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

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

For a parameterless read-only operation, the description is mostly complete: it states the resource, the access limitation, and the read-only nature. It does not describe what happens when Android does not permit access, but the low complexity and strong annotations make this a minor gap rather than a critical one.

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

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

The tool takes zero parameters, and the schema reflects that with an empty properties object. With no parameters to document, the description carries no obligation to explain parameter semantics; the baseline of 4 for a parameterless tool applies.

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

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

The description uses a specific verb ('Read') and a precise resource ('the current plain-text clipboard'), clearly distinguishing it from its write-side sibling android_clipboard_set. The qualifier 'when Android permits it' adds a condition without obscuring the core function.

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 the tool is for reading clipboard text, and the 'when Android permits it' caveat signals that OS permission constraints may apply. It does not explicitly name alternatives or exclusions, but there is no obvious read-clipboard sibling competing with this tool, so the context is reasonably clear.

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

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

Annotations already indicate destructiveHint=true, and the description's 'Replace' aligns with that. The description adds useful context not in annotations by specifying the new clipboard content will be 'plain text', which clarifies the tool sets plain text rather than rich content. It also implies overwriting the existing system clipboard, adding behavioral nuance beyond the structured annotations.

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

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

A single, complete sentence with no filler or redundancy. Every word contributes to the tool's meaning and the core action is front-loaded. This is exemplary conciseness for a simple tool.

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

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

For a one-parameter, simple clipboard setter with no output schema, the description covers the essential operation and content type. It does not mention usage alternatives or side effects, but the simplicity of the tool and the strong annotations (destructiveHint, openWorldHint) reduce the need for extensive context. Minor gaps remain in not explicitly warning about overwriting existing clipboard content, though that's implied by 'Replace'.

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 0% description coverage, so the description must compensate. While it does not explicitly name the 'text' parameter, 'with plain text' clearly indicates that the text argument is the plain text to place on the clipboard. This conveys the parameter's purpose and type more meaningfully than the bare schema, despite not mentioning the maxLength restriction (which the schema already documents).

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

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

The description uses a specific verb ('Replace') and resource ('current clipboard') to state exactly what the tool does. It clearly distinguishes from read-only clipboard operations or share actions, though it doesn't explicitly name a sibling alternative. The scope is unambiguous enough for an agent to identify it as a clipboard setter.

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

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

The description provides no guidance on when to use this tool versus alternatives like android_clipboard_get or android_share_text. It does not mention any exclusions, prerequisites, or context that would help an agent decide between sibling tools. The intended usage is only implied by the verb 'Replace'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read' is consistent with a safe, non-mutating operation. The description adds only the scope of what is read and the ambiguous 'optional capability status,' but does not disclose return shape, permission needs, or behavior when capabilities are missing. No contradiction with annotations.

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

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

One sentence with no filler, front-loaded with the verb and immediate resource. Every word earns its place by enumerating a distinct information category.

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

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

For a zero-parameter, read-only introspection tool the description is close to sufficient, but 'volume' is ambiguous (audio vs storage) and 'optional capability status' is undefined. With no output schema, an agent cannot know the return structure without invoking it, which leaves a real gap.

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

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

The input schema is empty with zero parameters and schema_description_coverage is trivially 100%. There are no parameters for the description to clarify, so the baseline of 4 applies; the description's category list is relevant but not required.

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

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

The description uses the specific verb 'Read' and names a clear set of resources: device, Android, battery, storage, network, volume, and capability status. It is broad enough to be distinguished from sibling tools that target single domains like volume or media, though it does not explicitly contrast itself with android_status or android_volume_get.

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

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

No guidance is given about when to use this tool versus the many sibling tools, nor any exclusions or prerequisites. The intended use case is only implied by the list of categories it reads, so an agent must infer when to prefer it over more specific alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it is metadata-only and that no action parameters or sensitive payloads are stored, providing extra behavioral and privacy context beyond the structured hints. No contradiction.

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

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

Two sentences, front-loaded with the action and resource list; the second sentence adds an important safety qualifier. No filler or repetition, and every sentence earns its place.

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

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

The description covers what diagnostics are exposed and underscores metadata-only/no-storage behavior, but with no output schema it does not describe return shape or result content. The parameter effects are also only implied. For a broad diagnostics tool this is adequate but not 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%, so the description must compensate. It mentions 'event' and 'execution-trace' diagnostics, which loosely map to eventLimit and traceLimit, but it never explains how the limits behave or affect results. The schema provides type/default/range, but the description adds minimal value for the parameters.

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

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

The description uses the explicit verb 'Read' and enumerates the resource categories (service, Tailscale, request, accessibility, snapshot, capability, event, execution-trace). It clearly states the tool's purpose and is not a tautology, but it does not explicitly differentiate itself from overlapping siblings like android_events or android_capabilities.

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

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

No explicit when-to-use or when-not-to-use guidance is provided, nor any alternatives among overlapping siblings. The metadata-only safety note implies a read-only diagnostic use case, but the agent is left to infer when to choose this broad tool over specific tools such as android_events or android_capabilities.

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

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

Annotations already mark this as destructive and non-read-only, so the safety profile is covered. The description adds no extra behavioral context such as possible side effects, prerequisites, or interaction with app state, but it also does not contradict the annotations.

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

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

The description is a single succinct sentence with no filler. It front-loads the action and immediately explains the coordinate options, making it easy to parse and 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?

The tool is simple, but all four parameters are optional and the description says 'either/or' without clarifying whether x/y and nx/ny are mutually exclusive, whether one set is required, or what happens if both are provided. This ambiguity leaves a meaningful 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?

The schema only provides names and numeric ranges, so the description adds valuable meaning by clarifying that x/y are absolute pixel coordinates and nx/ny are normalized 0..1000 coordinates. This is exactly the semantic information an agent needs beyond the raw 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 uses a specific action verb ('double tap') with a clear target ('a point') and explicitly names the two coordinate systems supported. This cleanly distinguishes it from sibling gesture tools like android_tap, android_long_press, and android_swipe.

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: use this tool when a double-tap gesture is needed. However, there is no explicit guidance on when to prefer this over android_tap or other gesture tools, nor any exclusion criteria or context such as 'for double-click actions, use this.'

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate the mutation risk. It adds the behavioral detail that both absolute and normalized coordinate systems are supported, but it does not disclose gesture mechanics (press-move-release), side effects beyond the annotation, or how normalized coordinates map to the screen.

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, focused sentence that front-loads the action and resource, then clarifies the coordinate systems. No redundant words or filler; 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?

For a tool with 9 optional parameters, no output schema, and destructive annotations, the description is workable but thin. It omits guidance on choosing between coordinate systems, whether mixing is allowed, and how durationMs relates to the drag behavior. Annotations cover the destructive nature, but an agent would still need to infer several invocation details.

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 meaning by explaining that x/y parameters are absolute pixels and nx/ny parameters are normalized 0..1000 values, which the bare schema does not convey. However, it does not clarify start/end point relationships, whether the two coordinate systems are mutually exclusive, or what durationMs controls.

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

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

The description uses a specific verb ('Drag') and resource ('between two points'), and immediately clarifies the two supported coordinate systems (absolute pixels vs normalized 0..1000). This clearly distinguishes it from sibling gesture tools like swipe, tap, long_press, and pinch.

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

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

The description gives no guidance on when to use this tool instead of alternatives such as android_swipe, android_scroll, or android_long_press. It does not state whether drag is preferred for particular UI interactions, nor does it mention any 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?

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior, so the description only needs to add extra context. It does so by disclosing that the feed is bounded, in-memory, and that event bodies are not persisted, which is meaningful behavioral information beyond the annotations.

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

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

The description is a single compact sentence with no filler. The most important behavior, reading the event feed after a cursor, is front-loaded, and the non-persistence caveat is added efficiently.

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

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

For a simple read-only tool with two optional parameters and rich annotations, this is mostly adequate. Still, it lacks detail about how the cursor/afterId semantics work, what the returned event feed includes, and the practical meaning of 'bounded'.

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 hints at afterId with the phrase 'after a cursor'. It says nothing about the limit parameter, its default, or the maximum, leaving real semantic gaps for the agent.

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 identifies the action ('Read'), the resource ('bounded in-memory UI/notification event feed'), and the access pattern ('after a cursor'). It is reasonably distinct from siblings like android_events_wait, which implies waiting rather than reading, but it does not explicitly name any of those 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?

The phrase 'after a cursor' implies this is for incremental/paginated reads rather than initial fetching or waiting for events, giving some usage context. However, the description gives no explicit guidance about when to prefer this tool over android_events_wait or android_notifications.

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

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

The read-only and idempotent annotations cover the safety profile, and the description adds useful details about long-polling and timeout expiry. It does not mention potential side effects or return behavior on timeout, but annotations already mitigate the main transparency concerns.

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 concise sentence with no redundant or ambiguous wording. It efficiently communicates the core behavior without unnecessary detail.

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 description explains the general behavior but omits critical details such as what the tool returns, how parameters interact, and what happens when no new event arrives before timeout. Without parameter documentation or an output schema, the agent cannot fully predict the tool's 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?

None of the three parameters (limit, afterId, timeoutMs) are described in the schema, and the description only vaguely hints at timeoutMs via 'timeout expires' and afterId via 'newer'. It does not clearly define the meaning or usage of each parameter, so the agent lacks sufficient guidance.

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 tool's purpose: it long-polls an in-memory event feed for newer UI/notification events with a timeout. This distinguishes it from related tools like android_events by emphasizing the blocking/waiting behavior.

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 clearly implies when to use this tool: when you need to wait for new events rather than simply fetching the current feed. However, it does not explicitly reference android_events as an alternative or state when not to use it, so it falls just short of full explicitness.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, covering the mutation and potential-destruction profile. The description adds useful context beyond annotations by limiting the operation to the same writable SAF root and conditioning it on provider support. It does not disclose overwrite behavior at the destination or partial-failure outcomes, which would be valuable given destructiveHint=true.

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 22-word sentence with the core action front-loaded ('Copy a file or directory to another directory') followed by the caveats. Every word earns its place; there is no repetition of schema fields 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?

The description covers the core copy scenario but omits operational details an agent would need: whether the source name is preserved in the destination, whether an existing destination file is overwritten, and what happens when targetDirectory is omitted. With no output schema, the agent also receives no indication of what the call returns.

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

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

With 0% schema description coverage, the description carries the full burden of parameter meaning: it loosely maps path to the file/directory being copied, targetDirectory to the destination directory, and rootId via 'writable SAF root.' However, it does not explain targetDirectory's optionality or what the default empty string means, leaving a meaningful gap for a required-vs-optional 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 states a specific verb ('Copy') with an explicit resource ('a file or directory') and destination ('to another directory'), which clearly differentiates it from sibling tools like android_file_move, android_file_rename, and android_file_delete. The added scope constraints ('same writable SAF root', 'when the provider supports it') further disambiguate the operation.

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

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

The description provides clear context for when the tool applies: duplicating files or directories within the same writable SAF root, with the provider-support caveat acting as an applicability condition. However, it does not explicitly name alternatives such as android_file_move or android_file_write, nor state when-not-to-use conditions, so some routing is left to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds a useful boundary condition (the authorized root cannot be deleted), but it does not disclose other behavioral details such as whether directory deletion is recursive, whether deletion is permanent, or what errors occur for non-empty directories. This is acceptable given the annotations but not fully transparent.

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 concise sentence that front-loads the core action and follows with the key constraint. Every word adds value, and there is no redundant or vague 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?

For a simple two-parameter destructive file operation, the description covers the essential behavior: what can be deleted, where deletion is allowed, and an important limitation. The absence of an output schema and lack of explicit error/return behavior are minor gaps because the annotations already signal the destructive nature and the operation is straightforward.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that rootId refers to an authorized SAF root and path refers to something inside that root, which gives some meaning beyond parameter names. However, it does not explicitly state that path is relative to the root or describe path formatting constraints beyond what the schema already provides.

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 ('Delete'), the target ('a file or directory'), and the scope ('inside a writable authorized SAF root'). It also distinguishes itself by noting the root itself cannot be deleted, which prevents confusion with broader deletion operations.

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

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

The description provides clear context about when the tool applies: deleting files or directories within a writable authorized SAF root. It does not explicitly name alternatives or exclusions, but the constraint about the root itself makes the intended usage reasonably 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?

The description mentions 'Does not use UI' which adds behavioral context beyond the readOnly/idempotent annotations. It does not describe output, errors, or side effects, but annotations already cover safety aspects, so the bar is lower.

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

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

The description is two succinct sentences, free of redundancy, front-loading the core action and key qualifiers.

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?

While the description communicates the essential operation, it omits output schema, error cases, and whether entries include files and directories. For a simple list operation without output schema, this is adequate but not fully complete for an agent to anticipate all responses.

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

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

With 0% schema coverage, the description carries param explanation. It clarifies that paths are relative to rootId (helping path and rootId), and 'paginated' implies limit/offset usage. However, no explicit details on default values or exact meaning of 'entries' are given.

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 tool lists directory entries, with pagination, distinguishing it from sibling file operations like read, write, and delete. The phrase 'authorized directory' and relative-path note clarify scope.

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

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

No explicit guidance on when to choose this over sibling tools such as android_file_search or android_file_stat. The note about not using UI hints at a non-UI approach, but does not provide direct alternative selection criteria.

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

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

Annotations already convey mutation and non-idempotence (readOnlyHint=false, destructiveHint=true, idempotentHint=false), and the description adds an operational auth prerequisite: the target must be a writable authorized SAF root. It does not describe edge cases like existing directories, but the annotation set lowers the bar.

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. Every word earns its place and the meaning is immediately clear.

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

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

For a two-parameter mkdir tool, this is mostly sufficient, but the absence of path semantics and failure behavior leaves minor gaps. The lack of an output schema is not a major issue for a creation command, so the tool remains usable.

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 weakly maps rootId to the SAF root and path to the directory to create, but it does not clarify path format, relative vs absolute resolution, or whether intermediate parents are created.

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, 'Create a directory', and a precise location, 'inside a writable authorized SAF root'. This clearly distinguishes it from file-focused siblings like android_file_write, android_file_delete, and android_file_list.

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 context is clear: use this tool when a new directory is needed under a writable authorized SAF root. It does not name explicit alternatives or exclusions, but the operation is specific enough that an agent can route to it without confusion.

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

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

Annotations already convey that this is a non-read-only, destructive operation, so the main burden on the description is additive context. It adds the useful constraint that moves stay within the same writable SAF root, but it does not explain overwrite behavior, what happens when targetDirectory is omitted, or whether the source is removed only after a successful move.

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 one short, front-loaded sentence with no filler or repetition. Every phrase earns its place: the action, the resource, and the key root constraint are all stated directly.

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

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

For a destructive, three-parameter tool with no output schema, this is under-specified. An agent cannot determine the meaning of the optional targetDirectory default or the path format, and the description does not mention return values or failure behavior, leaving important operational details to guesswork.

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 missing parameter explanations. It loosely suggests that rootId identifies the SAF root and that targetDirectory is the destination, but it does not clarify the expected format of path, what targetDirectory defaults to when empty, or how a move within the same directory is handled.

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 identifies the action ('move'), the resource ('file or directory'), and the destination constraint ('another directory in the same writable SAF root'). It does not explicitly contrast itself with sibling tools like android_file_copy or android_file_rename, 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?

The description gives no guidance on when to use this tool versus alternatives such as copy, rename, or delete. The only scoping hint is the 'same writable SAF root' restriction, which is a constraint rather than selection guidance.

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

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds value beyond that by disclosing the base64 return encoding, the offset/length pagination model, the no-UI behavior, and the security note that file contents should be treated as untrusted.

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 focused sentences, each earning its place: purpose, return/chunking behavior, and security guidance. The most important information is front-loaded and there is no filler or repetition of schema defaults.

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 strong read-only annotations and lack of output schema, the description covers the essential call behavior: what to read, how to read in blocks, what the response encoding is, and how to handle returned data. It is slightly incomplete on the rootId/path relationship, but overall it is sufficient for correct use in most 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%, so the description must compensate. It does add meaning for offset and length by explaining block-wise reading, and 'authorized file' hints at the rootId concept. However, it does not explicitly define rootId or the path relationship, which leaves part of the parameter semantics 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 names a specific verb and resource: 'Read bytes from an authorized file without UI.' It clearly distinguishes the tool from file metadata, search, write, and UI-based operations, and the chunked-read purpose is unmistakable.

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 this tool: for reading raw file content without UI, and for paginating with offset and length. However, it does not explicitly state when not to use it, nor does it route the agent to sibling alternatives such as android_file_list, android_file_stat, or android_file_write.

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

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

The description adds the constraint 'writable authorized' which clarifies the operational context, but it does not disclose side effects, error conditions, or return behavior. Since annotations already indicate it is destructive and not read-only, the description offers minimal additional insight.

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, clear sentence with no unnecessary words or complexity.

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 description explains the operation at a high level but lacks parameter details, output/error expectations, and any mention of side effects. Given the simplicity of the operation and the absence of an output schema, it is still 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?

The description provides no explanation of the parameters (rootId, path, newName). With zero schema description coverage, this leaves the agent without any guidance on what each parameter should contain.

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 (rename) and the resource (file or directory within a writable authorized SAF root). It distinguishes from sibling file operations like move, copy, and delete.

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

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

The description provides context that the operation requires a writable authorized root, but it does not explicitly guide when to use this tool versus alternatives or mention prerequisites like permissions beyond the root being writable.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: the roots are 'currently authorized' and the tool has no prerequisite of Accessibility or a file manager. This helps the agent understand prerequisites and dynamic 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 exactly two sentences with no filler. The primary purpose is front-loaded, and the additional prerequisite clarification is concise and valuable.

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

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

For a zero-parameter, read-only listing tool, the description is sufficient. It tells the agent what the tool returns conceptually, that no special prerequisites exist, and annotations cover the safety profile. No critical missing context prevents 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 tool has zero parameters, so there is no parameter meaning to elaborate. Baseline for zero-parameter tools is 4, and the description appropriately avoids inventing parameter details that do not exist.

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 ('List') and a precise resource ('currently authorized storage roots'), making the tool's purpose immediately clear. It also distinguishes itself from sibling file tools by emphasizing what it lists rather than operating on files or directories.

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

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

The description provides clear context: it lists authorized storage roots, and explicitly notes that it does not require Accessibility or opening a file manager. This implies when to use this tool versus other file-related tools, though it does not explicitly name alternative tools or exclusion conditions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat those. It adds useful behavioral context about recursion and non-UI execution, but it does not disclose important behaviors such as return format, traversal order, or what 'authorized directory' means in practice.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose and differentiating context, making it easy to parse quickly.

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

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

With no output schema, no parameter descriptions, and five parameters, the description is too sparse to be fully actionable. An agent still cannot determine what rootId should reference, how query patterns are matched, what path is relative to, or what the returned data looks like.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the five parameters. It only vaguely hints at 'names' (query) and 'authorized directory' (rootId), and says nothing about path, limit, maxDepth, or how query matching works. The property names and defaults help, but the description adds very little semantic 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 clearly states a specific verb ('search'), a specific resource ('names below an authorized directory'), and a method ('recursively ... without using the UI'). This differentiates it from UI-based search tools like android_ui_find and from simple listing tools like android_file_list.

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 'without using the UI' implies this tool is the non-UI path for finding files, but it does not explicitly state when to choose this over android_file_list, android_ui_find, or other search approaches. The usage context is somewhat clear, but no alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, but the description adds behavioral context beyond that: 'without UI' implies no screen interaction, and 'authorized root' suggests permission constraints. These are useful and not present in annotations.

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

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

The description is a single, tight sentence with zero fluff. Key action ('Read') is front-loaded, and the essential context (metadata, authorized root, no UI) is packed efficiently. 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?

For a simple read-only stat operation with only two parameters, the description gives the core purpose, but it omits what metadata is returned (no output schema) and does not explain parameter roles or edge cases (e.g., missing file). Given the lack of schema descriptions, this is a minimal but incomplete context for an agent.

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 adds no parameter-specific meaning. It mentions 'authorized root' which loosely relates to rootId, but gives no details on path or rootId semantics, units, or expected values. The description completely fails to compensate for the schema's lack of 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 description 'Read file or directory metadata within an authorized root without UI' uses a specific verb (read) and resource (file/directory metadata), and clearly distinguishes from siblings like file_read (content) and file_list (listing). The 'authorized root' context further clarifies scope.

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 usage context is implied – you'd use this when you need metadata rather than content or listing – but there is no explicit guidance on when to prefer this over other file tools or any exclusion criteria. No alternatives are named, leaving the agent to infer from the sibling set.

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

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

The description aligns with the destructiveHint annotation by explaining truncation behavior for the first block. It transparently indicates that writing can replace content (via truncate) and that later writes use offsets. There is no contradiction with the annotations.

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

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

The description is concise, consisting of two sentences that efficiently convey the core operation and key usage notes. No superfluous information is included.

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 description covers the main write operation and chunking strategy but does not mention potential side effects (beyond truncation), error conditions, or whether parent directories are created. Given the absence of an output schema, some behavioral expectations remain implicit, though not critical for basic usage.

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

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

With zero schema description coverage, the description must clarify parameters. It explains 'data' as a base64 block, 'truncate' for replacement, and 'offset' for positioning, but it does not explain 'rootId', 'path', or 'mimeType'. These are somewhat inferable from context but not explicitly described, leaving partial 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 clearly states the tool's purpose: to create or write a base64 block to a file within a SAF root. It uses a specific verb ('write') and identifies the resource (file in SAF root), distinguishing it from sibling file operations like read, copy, or delete.

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

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

The description provides parameter-level guidance (using truncate for the first block and offsets for subsequent blocks) but does not explicitly state when to use this tool versus alternatives. Since it is the only file-write tool among siblings, the absence of alternative comparison is acceptable, but the guidance focuses on how rather than when.

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

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

The description adds meaningful behavioral context beyond the annotations: execution is local, bounded to 1..40 steps, capped at 20 seconds, and excludes shell/file mutation. It also mentions guards, captures, and trace output. It does not contradict the destructiveHint or other annotations.

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

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

Two sentences, no filler, with the core action front-loaded and the key limitation stated immediately after. Every clause adds useful information.

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

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

This is a complex tool with a nested step schema, no output schema, and no documentation of what values the required 'type' field accepts. The description gives a good high-level summary, but an agent still lacks enough information to correctly construct steps, interpret guards/captures, or understand error/fallback 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?

With 0% schema description coverage, the description compensates by explaining that 'steps' are UI steps bounded to 1..40 and that the deadline is 20 seconds, mapping to steps and timeoutMs. It also hints at step-level concepts like guards and captures. It does not enumerate valid step 'type' values, but the schema still provides the structural shape.

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 'Execute 1..40 bounded UI steps locally on the phone', naming a specific verb, resource, and scope. It also distinguishes the tool from shell/file siblings by explicitly stating 'Shell and file mutation are not available inside flows.'

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 clearly implies use for bounded, local UI automation sequences and explicitly says shell and file mutation are not available, giving a useful when-not signal. However, it does not name sibling alternatives such as android_batch or android_act_and_observe, so the routing guidance is not fully 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral context: the Shizuku authorization requirement and the self-force-stop limitation. It does not contradict the annotations.

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

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

Two short, purposeful sentences with the action front-loaded and constraints immediately after. There is no filler, and the self-exclusion statement earns its place by preventing a plausible wrong invocation.

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

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

For a destructive operation with one parameter and no output schema, the description covers the critical authorization gate but leaves 'validated package' undefined and does not explain what happens to the target app when force-stopped or when the call would fail. It is adequate but not rich enough for fully confident 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 needed to explain packageName, but it only refers to 'a validated package,' which is vague. The schema's regex and maxLength carry the entire burden of parameter meaning; the description does not meaningfully compensate.

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

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

The description names a specific action ('force-stop') and a specific resource ('a validated package'), which clearly differentiates this tool from the many Android companion tools in the sibling list. It also adds a meaningful scope note that MCP Android cannot force-stop itself.

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

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

The description clearly states the tool is only usable through 'explicitly-authorized Shizuku only,' giving the agent a concrete precondition and limiting when the tool should be attempted. It also states one exclusion (cannot force-stop itself), but it does not mention alternatives or broader when-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?

The annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not elaborate on side effects (e.g., changing screen state, exiting apps). It only says 'perform a navigation action,' leaving behavioral details unexplained beyond the annotation flags.

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, concise sentence with no redundant wording. It directly states the tool's purpose without fluff, achieving high efficiency.

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's simplicity and the enum schema, the description is minimally sufficient. However, it omits any mention of return values or side effects per action, and it assumes the agent knows what each navigation action does. A slightly richer description would improve completeness.

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 fully covers the parameter with an enum of possible actions (home, back, recents, notifications, quick_settings), so the baseline is 3. The description adds no extra meaning to the parameter values—it doesn't explain what each action does—but the enum is self-explanatory for a basic level.

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 a specific verb ('Perform') and resource ('native Android navigation action'), distinguishing it from UI interaction tools like android_ui_click and android_tap. It could be more specific by enumerating the actions, but the enum schema fills that gap.

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

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

The description implies usage for navigation actions but does not explicitly contrast with alternative tools. An agent can infer when to use this tool from the enum values (home, back, etc.), but no explicit guidance is given for choosing between this and other navigation-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?

The description adds context about operating on the focused field, which goes beyond the annotations. It implies a destructive replacement (consistent with destructiveHint=true). However, it does not specify whether 'replace' means replacing the entire field content or only a selection, and it does not discuss failure modes or side effects beyond the focus requirement.

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

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

The description is two short, direct sentences with no unnecessary words or redundancy. It conveys the essential information efficiently, making it highly concise and well-structured.

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 description covers the main prerequisite (focus) and the core action, but lacks details about edge cases such as whether the text replaces the entire field or only selected text, what happens if no field is focused, or any error conditions. Given the absence of an output schema, the description is adequate but not fully comprehensive for an agent to handle all scenarios 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?

The sole parameter 'text' is not described in the schema, but the tool description implicitly clarifies it as the replacement text. The meaning is clear from the context of 'Replace text' and the parameter name. This effectively compensates for the 0% schema coverage, though it is not explicit about the parameter's intended use.

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 ('Replace text') and the target ('currently focused editable field'). It implies a specific resource and operation, making the tool's purpose unambiguous. However, it does not explicitly differentiate from sibling tools like android_ui_set_text, so it loses one point for not naming 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?

The description provides a prerequisite ('Focus the intended field first'), which gives some usage guidance. However, it does not explicitly address when to choose this tool over alternatives such as android_ui_set_text, nor does it mention conditions like field visibility or editability beyond what is implied. Guidance is present but not comprehensive.

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?

Does not disclose potential side effects, such as bringing an app to foreground, error conditions when app is missing, or any implications of the destructiveHint annotation; description is minimal.

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

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

One sentence, no redundant wording, perfectly sized.

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?

Sufficient for a simple launch action, but lacks any mention of expected behavior or error handling; still, it's clear enough given the sibling 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?

The description clarifies that packageName must be an exact package name, supplementing the schema's regex pattern; however, it doesn't explain why the regex is structured that way.

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?

Clearly states the action (open), the target (installed application), and the criterion (exact package name), distinguishing it from URI-based opening tools.

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

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

Provides no explicit guidance on when to choose this tool over alternatives like android_open_uri or android_apps; the only implicit hint is the requirement of an exact package name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the bar for added value. The description adds two behaviors not captured by annotations: output is redacted (privacy filtering applied) and access requires explicitly-authorized Shizuku (an auth precondition). It also discloses boundedness, setting expectations that results are volume-limited rather than complete log streams.

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 zero waste: the first front-loads the core action and scoping guardrails, the second covers capabilities. Every qualifier ('bounded', 'redacted', 'explicitly-authorized', 'optional') carries operational meaning for the agent.

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

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

For a simple 5-parameter read-only tool with no required params and strong safety annotations, the description adequately covers purpose, filter options, the auth precondition, and output characteristics (bounded, redacted). It does not specify what redaction removes or the failure mode when Shizuku is unauthorized, but these are minor gaps for a diagnostic read operation.

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

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

Schema description coverage is 0%, so the description carries the compensation burden. It maps three of five parameters to concepts — package→packageName, tag→tag, time→sinceSeconds — and states they are optional, which matches the zero required parameters. However, it offers nothing on level (the priority enum) or lines (count bounds), leaving those to be inferred from names and defaults.

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 — 'Read... logcat output' — with sharp scoping qualifiers ('bounded, redacted', 'through explicitly-authorized Shizuku') that separate it from generic shell tools like android_shizuku_shell or android_shell, even though no sibling is named. No other sibling targets logcat specifically, so an agent can identify this tool's role without opening the schema.

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

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

The description implies when to use it: when bounded, redacted logcat output is needed and Shizuku authorization is available. The phrase 'explicitly-authorized Shizuku' signals a prerequisite, and 'Supports optional...filtering' indicates the tool handles filtering internally. However, it never names an alternative or states an explicit when-not-to-use condition, so the routing guidance is left to inference.

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

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

Annotations already signal the operation is non-read-only and destructive, and the description adds no context about what a long press physically does — e.g., that it simulates a device-level touch-and-hold that may trigger context menus, enable drag-and-drop, or rearrange launcher icons depending on what sits at the coordinate. There is no annotation contradiction, but no behavioral value is added beyond the structured hints.

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

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

A single sentence with zero waste and the key action front-loaded. However, the extreme brevity borders on under-specification: it omits behavioral and parameter context that the surrounding schema lacks, so it is concise at the cost of usefulness.

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

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

With no output schema and 0% parameter description coverage, this description is the only prose an agent receives. It fails to mention coordinate units/origin, durationMs meaning, expected return value, or the side-effect profile beyond the annotations' flags. For a gesture tool with destructiveHint=true and 40+ siblings, this 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%, so the description must carry parameter meaning. It confirms x/y are screen coordinates but does not explain units (pixels), coordinate origin (top-left), or — most importantly — that durationMs is the hold duration in milliseconds. The constraints (400–3000 ms) are meaningful without semantic grounding.

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

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

The description names a specific gesture type ('Long press') and a target resource ('screen coordinate'), which is a clear verb+resource pairing. The gesture is inherently distinct from sibling actions like android_tap, android_swipe, android_scroll, and android_ui_click. However, it does not explicitly contrast with its closest neighbor android_tap, so the differentiation is implicit rather than stated.

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

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

The description offers no guidance on when to long-press versus when to tap, click, swipe, or scroll. With 40+ sibling tools including several gesture actions, the absence of any selection guidance, exclusions, or mention of alternatives leaves the agent to guess which tool fits the situation.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description is not required to restate that this mutates state. The description adds only the minimal context that an active media session is the target. It does not explain side effects of individual actions, such as stop vs pause, or what happens if no session is active, but the annotations cover the safety profile.

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 wasted words. It is concise, though it could have added valuable behavioral or usage detail without becoming overly long.

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 only two parameters, the description plus schema provides a baseline understanding: choose an action and optionally a package name. However, it leaves key operational details unspecified, such as how packageName disambiguates between multiple active sessions and what happens when packageName is omitted.

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, but it mentions neither 'action' nor 'packageName'. The action enum is reasonably self-explanatory, and 'packageName' is recognizable, but the description adds zero semantic detail about how the parameters interact or when packageName is needed.

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

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

The description uses a specific verb ('Control') and a resource ('active media session'), clearly indicating that this tool operates on media playback rather than querying it. The distinction from the sibling android_media_sessions is implicit—one lists sessions, the other controls them—though the description does not explicitly name the alternative.

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

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

There is no guidance about when to use this tool versus alternatives like android_media_sessions, volume controls, or UI-based interaction. The description implies 'when you want to control media playback' but provides no context on prerequisites such as needing an active session, or when to provide packageName.

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

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

The annotations already declare read-only, idempotent, and non-destructive traits, so the description's additional 'Requires notification access' adds useful behavioral context. It could mention the consequence of missing access, but the existing information is sufficient.

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, concise sentence that includes the essential action and the key requirement. It is well-structured and free of unnecessary 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?

The description gives the purpose and a prerequisite, which is adequate for a simple listing tool. It does not specify the return format, but 'List' implies a list of sessions, and the lack of an output schema means this is a minor omission.

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

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

The tool has no parameters, so the schema is fully covered. The description does not need to describe any inputs, and the absence of parameters is evident from the schema itself.

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 ('List') and the resource ('active media sessions'), using a specific verb that distinguishes it from sibling tools. It is immediately obvious what the tool does, and no other sibling tool appears to handle listing media sessions.

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

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

The description provides a prerequisite ('Requires notification access'), which is useful context. It does not explicitly contrast with alternatives like android_media_action, but the sibling context makes the differentiation clear, so the guidance is adequate if not exhaustive.

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

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

The annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the 'active' precondition and the reliance on a key, but does not disclose additional behavioral details such as permission requirements or what happens if the key is invalid.

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

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

The description is a single, front-loaded sentence with no filler. It directly states the action, target, and required parameter, making it efficient and easy to parse.

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

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

For a one-parameter tool, the core mechanics are present, and the destructive annotation covers the mutation risk. However, the description omits how the notification key is obtained, whether special permissions are required, and what the tool returns or does on failure. Given no output schema or parameter descriptions, this leaves some uncertainty.

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

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

Schema description coverage is 0%, so the description must carry the semantic load for the key parameter. Saying 'by key' identifies the parameter but does not explain what a notification key is, where to obtain one, or how it should be formatted. This is minimal compensation for an undocumented schema.

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

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

The description uses a specific verb, 'Dismiss', names the resource, 'active notification', and specifies the mechanism, 'by key'. This clearly distinguishes it from sibling tools like android_notification_open and android_notification_reply.

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 by the verb and resource: use this when you want to dismiss an active notification. However, the description does not explicitly state when not to use it or mention alternatives such as opening or replying to a notification.

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

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

The description says only 'open' and does not disclose side effects, such as launching an app or changing foreground state, beyond the coarse destructiveHint annotation; no additional behavioral context is provided.

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 concise sentence with no redundant or irrelevant 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?

Key contextual information is missing: how to retrieve the notification key, what the tool returns, and when to use it instead of notification dismissal or reply, leaving the description incomplete for reliable 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 schema only defines 'key' as a required string, and the description does not explain what the key represents, where to obtain it, or its format, so parameter meaning is largely under-specified.

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

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

The description clearly states the specific action—opening an active notification—and the required identifier, distinguishing it from related tools like dismiss or reply.

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 about when to choose this tool over alternatives such as android_notification_dismiss or android_notification_reply; the description states the operation but not the intended use context.

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

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

The description adds a useful precondition (RemoteInput) that is not present in annotations. Annotations already signal mutation (readOnlyHint=false, destructiveHint=true, idempotentHint=false), so the description does not need to restate those. It does not disclose side effects such as whether the notification is dismissed or the reply is delivered, but the precondition is meaningful beyond structured data.

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 sentence that states the operation and its key precondition without unnecessary words. 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 mutating tool with no output schema, the description is too sparse. It does not explain how to obtain the 'key', what happens after the reply is sent (e.g., notification dismissal), or what success/failure looks like. The sibling android_notifications likely provides the key, but this connection is not stated. An agent would need to make assumptions.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining parameters. It does not define 'key' or 'text', nor does it clarify that 'key' refers to a notification identifier and 'text' to the reply content. The tool name and description imply this mapping, but the description itself provides no explicit parameter semantics.

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

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

The description names a specific operation ('direct reply') and a specific resource ('a notification that exposes RemoteInput'), which clearly sets it apart from sibling tools like android_notification_open and android_notification_dismiss. An agent can immediately understand what action this tool performs and on what kind of target.

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 explicitly states the precondition for use: the notification must expose RemoteInput. This gives the agent a clear condition to check before calling. However, it does not explicitly list alternatives or when not to use it, though the sibling set implies the distinction.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds useful behavioral context beyond those: it requires prior user grant of notification access and warns that notification text is untrusted data. There is no contradiction with the annotations.

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

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

The description is two tight sentences. The main action and scope are front-loaded, and the security warning about untrusted notification text is a concise, valuable addition with 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?

For a simple read-only list with one optional parameter, the description covers the key operational facts: permission prerequisite and untrusted data. It does not describe the return shape, but with no output schema and the verb 'list,' the returned data type is reasonably inferable.

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 fully constrains the single 'limit' parameter with type, default, minimum, and maximum, but provides no description. The tool description does not mention 'limit' at all or explain how it affects results, so with 0% schema description coverage the description fails to compensate for this 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 starts with the specific verb 'List' and the resource 'active notifications,' which clearly states what the tool does. It also distinguishes itself from sibling tools like android_notification_open, android_notification_dismiss, and android_notification_reply by focusing on listing rather than acting on notifications.

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

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

The description provides a clear precondition: use after the user grants Android notification access. It does not explicitly name alternatives or exclusions, but the sibling tool names make the read-only listing vs. action distinction reasonably obvious.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context such as navigating away from the current screen, requiring the package to be installed, or potential side effects. It merely restates the action with no additional transparency.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core action efficiently and is appropriately sized for a simple 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?

The tool is simple and the description covers the basic action, but it omits information that would help an agent understand behavior around the destructive annotation, what happens on failure, and how this differs from closely related sibling tools. Some completeness is provided by the schema's required parameter, but not enough for full clarity.

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 only vaguely references 'an installed package,' which adds minimal meaning beyond the parameter name and pattern in the schema. It does not explain the expected format, validation, or requirements for packageName in any useful detail.

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 clear verb and resource: 'Open Android application details/settings for an installed package.' This distinguishes it from launching the app itself (android_launch_app) and from reading app information (android_app_details), although it does not explicitly name these siblings.

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

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

No guidance is given about when to use this tool versus alternatives such as android_app_details or android_launch_app. The description simply states the action, leaving the agent to infer the appropriate context.

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?

Given the annotations already include destructiveHint=true, the description adds non-obvious behavioral context: the tool uses Android intents and does not directly place a call even for tel URIs. This helps the agent understand the side-effect profile beyond what annotations alone convey. No contradiction with annotations exists.

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 only two sentences long, with no filler. The action and accepted URI schemes are front-loaded, and the important behavioral caveat about not placing a direct call is placed at the end.

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

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

For a single-parameter tool with no output schema, the description fully covers what the tool does, what inputs it accepts, and a key behavioral nuance. An agent has enough information to select and 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?

The schema only defines uri as a string with length limits, so the description adds essential meaning by enumerating allowed URI schemes: http(s), geo, tel, mailto, and sms. It tells the agent what kind of value to supply, though it could have included concrete 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?

The description uses a specific verb plus resource: 'Open an http(s), geo, tel dialer, mailto or sms URI using Android intents.' It clearly distinguishes this from sibling tools like android_launch_app or android_share_text by defining exactly which URI schemes it handles.

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 clearly communicates when to use the tool: when the target is a supported URI scheme. It also provides a useful exclusion by stating 'This does not directly place a call,' which prevents the agent from using it to place calls directly. It does not explicitly name alternatives or sibling 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds scoping context with 'bounded' and 'around a point', but does not explain side effects, screen limits, or whether this triggers zoom behavior. It does not contradict the annotations, and the added context is modest yet still useful.

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 sentence with zero filler, front-loading the action and its key variants. Every word contributes meaning, making it highly efficient for quick reading.

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

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

With 7 parameters, 0% schema coverage, and no output schema, the description is not sufficient for correct invocation. It does not clarify the distinction between x/y and nx/ny, the meaning of amount, or the expected outcome. While the gesture concept is simple, the parameter ambiguity is a significant gap.

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

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

Schema description coverage is 0%, so the description must compensate, but it only hints at direction and the center point. Parameters nx, ny, amount, and durationMs are left unexplained, and their meaning is not self-evident from names alone. An agent would be uncertain how to set these values correctly for a bounded pinch.

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 ('perform'), a clear resource ('two-finger pinch'), and the direction options ('in or out') around a point. It is easily distinguishable from sibling gesture tools like android_tap, android_swipe, and android_scroll, which do not involve pinching. The 'bounded' qualifier adds useful precision without obscuring the purpose.

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

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

No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. The use case is implied by the name and phrase 'two-finger pinch', but the description does not explain how this differs from related gestures or in which scenarios it is appropriate. This is adequate but leaves the agent to infer context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds valuable behavioral context beyond annotations by disclosing the two execution mechanisms (Accessibility vs Shizuku) and the authorization requirement.

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

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

Two short sentences with no filler. The core action is front-loaded, and the important authorization caveat is delivered in the second sentence without redundancy.

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

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

For a single-parameter tool with a self-explanatory enum and annotations covering safety, the description is nearly complete: it states what the tool does and the prerequisite for use. It does not describe return values or detailed side effects, but the tool's low complexity and lack of output schema reduce the need for that.

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 bare enum. It adds meaning by classifying the key as navigation/input/media and by explaining that home/back behave differently from the other keys in terms of required authorization.

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 ('Press') and a specific resource ('a named navigation/input/media key'), which is immediately distinguishable from coordinate-based touch tools like android_tap, android_swipe, and android_double_tap. The key enum further pins down exactly what can be pressed.

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 clear usage context: press a named key, with Home/back using Accessibility and all other keys requiring explicitly authorized Shizuku. It does not explicitly name alternative tools or say when not to use this tool, but the authorization caveat is practical 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?

Beyond the readOnly and idempotent annotations, the description adds a key behavioral detail: 'No automatic privilege fallback is performed.' This discloses that the tool will not attempt to downgrade or switch privileges, which is useful for callers to understand its limits. However, it doesn't elaborate on what specific permissions or backends are checked.

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

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

The description is two sentences, providing the essential information without any filler. It is concise and well-structured, front-loading the primary purpose and then adding the important behavioral note.

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 description names the key elements of the report (backends and permissions) but does not specify the exact format or level of detail. Since there is no output schema, the description is mostly sufficient, though an agent might want to know whether the report is a list, a status flag, or a detailed breakdown. Still, it covers the core 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?

The tool has no parameters, and the schema correctly reflects that with an empty properties object. Since there are no parameters to describe, the baseline score of 4 applies. The description adds nothing about parameters because none exist, which is appropriate.

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

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

The description clearly states the tool's purpose: to report optional Termux and Shizuku backends and permissions. The verb 'Report' is specific, and the resource is well-defined, distinguishing it from the many action-oriented sibling tools.

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 explicitly state when to use this tool versus others. It implies that it should be used to check backend availability and permissions before relying on them, but this is not stated directly. The note about no automatic privilege fallback hints at usage context but lacks explicit 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?

The annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds the opt-in nature of the screenshot, which is a behavioral detail not covered by the schema. However, it does not clarify potential side effects (e.g., whether it accesses accessibility services) or resource usage.

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 to the point, but the phrasing 'Preferred agent observation' and 'compact semantic screen context' is somewhat cryptic and could be more straightforward. It does not waste words, but the structure is not optimally clear for an agent.

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 lacks an output schema, and the description does not explain the return format or content beyond 'semantic screen context'. There is no mention of whether the result includes UI elements, coordinates, or just a summary. This leaves significant ambiguity about what the agent will receive.

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?

None of the four parameters (maxNodes, treeMode, screenshot, includeInvisible) are explained in the description. The schema provides defaults and constraints, but the description offers no semantic meaning for these options, leaving the agent to infer their purpose.

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 indicates the tool provides a compact semantic screen context, distinguishing it from raw UI tree tools like android_ui_tree. It also mentions the opt-in screenshot and snapshot/hash, which hints at its primary use for observation. However, 'preferred agent observation' is a bit vague and could be more explicit about the exact output.

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 android_screen_diff, android_ui_tree, or android_screenshot. The description implies it is for observation but does not specify conditions or scenarios where this tool is preferred over its siblings.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds that the tool returns diff results (added, removed, changed nodes), which is useful. However, it does not disclose any edge cases, error conditions, or side effects beyond the basic 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?

The description is a single, focused sentence with no filler. It directly states the action and expected output, making it highly efficient and easy to parse.

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

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

No output schema, no parameter descriptions, and no usage context are provided. The description assumes the agent already knows what 'semantic screen snapshots' are and how to obtain the IDs. Missing details about snapshot recency or source limit the completeness.

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 description does not explicitly explain fromSnapshotId and toSnapshotId. The names are somewhat self-explanatory, but no details are given about ordering, format, or how snapshots are referenced. Schema coverage is 0%, so the description carries full responsibility and falls short.

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 tool's function: comparing two semantic screen snapshots and returning added, removed, and changed nodes. It uses a specific verb and resource, and the purpose is immediately understandable. This distinguishes it from related tools like android_screen_context or android_ui_tree.

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 about when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or contrasting sibling tools. Usage must be inferred entirely from the name and brief description.

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

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

The description discloses an important behavioral caveat: protected windows may deny capture. This aligns with the readOnlyHint and idempotentHint annotations and adds useful transparency about potential failures.

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 extremely concise, using a single sentence that communicates both the core action and an important limitation without unnecessary detail.

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 description is adequate for a parameterless screenshot tool, including a relevant caveat. However, since no output schema is provided, it leaves the exact return format unspecified, though 'as an image' gives a general expectation.

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

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

The tool has no parameters, so no parameter descriptions are needed. The schema already covers this completely.

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 tool's purpose with a specific verb and resource: 'Capture current display as an image'. It is easily distinguished from sibling tools like android_ui_tree or android_shell.

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 the tool is for capturing the display, but it does not explicitly state when to prefer it over alternatives or when not to use it. The purpose is clear enough for basic selection, but no direct usage guidance is provided.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the side-effect profile is known. The description adds no extra behavioral context, but it does not contradict the annotations either.

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 clear sentence with no redundant words. It is appropriately concise and front-loaded for a simple scrolling action.

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

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

For a simple tool, the description is adequate, but it lacks broader context such as how scrolling interacts with the UI hierarchy or when to prefer this over gestures like swipe. It is not fully self-contained in the tool ecosystem.

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 defines the direction enum but provides no description for the parameter. The description only says 'specified direction' without explaining scroll behavior (e.g., amount, viewport, or edge cases), so parameter semantics are minimally covered.

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 ('scroll content') and the key variable ('specified direction'), which is sufficient to understand the tool's basic purpose. It is not overly generic and aligns with the enum-based direction parameter.

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 about when to use this tool versus related tools like android_swipe or android_ui_click. The description does not mention suitable contexts, limitations, or alternatives.

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

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

The description mentions 'bounded steps' and 'UI stops changing', giving some insight into iterative behavior and termination criteria. However, it does not explain side effects, failure behavior, or how it interacts with the destructiveHint annotation, which remains unexplained.

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, concise sentence with no redundant info. It follows a clear structure but could be slightly more specific about the selector criteria without becoming verbose.

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 description is minimal and does not cover important context such as default selector matching behavior, timeout handling, or what constitutes a 'bounded step'. Given the high parameter count and no output schema, this leaves significant 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?

The description provides no mapping between the 15 parameters and the concept of a 'semantic selector'. Since the schema has zero descriptions, the description fails to compensate and leaves parameter meaning ambiguous.

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 (scroll) and the termination condition (until a semantic selector becomes visible or UI stops changing). However, the term 'semantic selector' is vague and not explicitly tied to the parameter set, so it could be clearer.

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 provide any guidance on when to use this tool versus alternatives like android_scroll or android_ui_find. It implies usage for scroll-to-element scenarios but does not state explicit conditions 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?

Annotations mark destructiveHint true and openWorldHint true, but the description does not disclose possible side effects such as launching external apps, user interaction requirements, or data leaving the device.

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

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

The description is a single focused sentence with no redundant words or repetitive information.

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

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

For a simple two-parameter tool with no output schema, the description is minimal but still omits important context around title usage and side effects, so completeness is only moderate.

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 has no parameter descriptions and tool description only explains text; the optional title parameter's purpose is entirely unspecified.

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?

Clearly states the action (open share sheet) and payload (plain text), distinguishing it from sibling tools like android_open_uri and android_clipboard_set.

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

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

Provides no guidance on when to use this tool versus alternatives such as clipboard_set or open_uri, and no mention of prerequisites or fallback behavior.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds the permission requirement but does not elaborate on side effects, error behavior, or state changes beyond what annotations imply.

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 concise—two sentences—and directly states the core action, environment, and permission. No unnecessary words or redundancy.

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

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

While there is no output schema, the description states that stdout/stderr are returned, which covers the basic expectation. It also mentions the permission prerequisite. However, it lacks details on exit codes, timeout handling, or edge cases like empty script.

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 zero parameter descriptions (0% coverage), and the description does not explain any parameters beyond mentioning 'script' and return values. stdin, workdir, and timeoutMs are completely 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 clearly states the verb 'Execute' and the resource 'shell script in the user-installed Termux environment', distinguishing it from sibling tools like android_shizuku_shell. The scope 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 is provided on when to use this tool versus alternatives such as android_shizuku_shell or android_shell_status. The only context is the permission requirement, which does not help with tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds useful context by specifying what is being verified (installation and authorization), but it does not disclose additional behavioral details such as what a successful or failed check implies for subsequent shell usage.

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, focused sentence with no filler. It front-loads the action ('Report') and delivers the essential qualification 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 zero-parameter status check with strong read-only annotations, the description is nearly complete. It conveys that the result is a yes/no determination about installation and authorization; a slightly richer description could clarify the exact return shape, but this is a minor gap.

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

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

The tool has zero parameters, so the input schema fully covers this dimension. The description adds the relevant semantic context by explaining what state the tool reports, which is sufficient given the empty schema.

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

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

The description uses a specific verb ('Report') and names the exact resource (optional Termux RUN_COMMAND shell backend) and the status dimensions being checked (installed and authorized). This clearly distinguishes it from sibling tools like android_shell (which executes commands) and android_shizuku_status (which checks a different backend).

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 makes the tool's purpose obvious: check whether the Termux RUN_COMMAND backend is available and authorized before relying on shell execution. It does not explicitly name alternatives or state 'use this instead of X,' but the context is clear enough for an agent to choose this tool when a pre-flight shell-backend check is needed.

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

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

Annotations already mark this as destructive and non-idempotent. The description adds useful behavioral context beyond that: it runs as UID 2000 and only gains root if the user explicitly started Shizuku as root. It also clarifies that explicit authorization is required, which is valuable for an agent deciding whether to invoke it.

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 focused sentences convey the core action, authorization model, and privilege behavior with no filler. The most important security boundary (shell UID vs root) is clearly stated.

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 description covers the essential execution model and privilege context, but it does not mention return behavior, stdout/stderr, exit codes, or how stdin/timeout/workdir affect execution. With no output schema, an agent still has to guess what the tool returns after running a script.

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 any of the four parameters. Although names like script, stdin, workdir, and timeoutMs are somewhat self-explanatory, the description provides no extra guidance on how they interact or what values are expected, so the schema's lack of descriptions is not compensated.

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

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

The description names a specific action ('Execute /system/bin/sh') and a specific resource/environment ('explicitly-authorized Shizuku UserService'). The UID/root clarification also distinguishes this from the plain android_shell sibling, so an agent can tell them apart.

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 this tool: when an authorized Shizuku shell is needed and potentially root-level execution is acceptable. However, it does not explicitly name alternatives like android_shell or state conditions under which one should prefer one over the other.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructiveness. The description adds value beyond these by specifying the exact status dimensions reported and, importantly, that Shizuku is never selected implicitly—a behavioral constraint not captured by the annotations. No contradiction exists.

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

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

A single, dense sentence front-loads the purpose and enumerates the reported state components, followed by one short high-value clarifier about implicit selection. Every word earns its place; there is no fluff or repetition.

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

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

For a stateless, zero-parameter, read-only status tool with rich annotations, the description is complete. It tells the agent what is reported, that it is safe and idempotent via annotations, and that it will not happen implicitly. No output schema exists, but the agent knows what to expect conceptually.

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

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

The tool has zero parameters, so the schema fully covers the input surface. The description correctly focuses on what the tool reports rather than parameter details, making the baseline 4 appropriate; there is no parameter semantics gap to compensate for.

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

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

The description uses a specific verb ('Report') and clearly identifies the resource: Shizuku binder, permission, server UID/mode, and UserService state. It is immediately distinguishable from sibling status tools like android_shell_status or android_privileged_status because it is Shizuku-specific and enumerates exactly what is reported.

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 statement 'Shizuku is never selected implicitly' gives an explicit selection constraint: this tool should only be used when Shizuku status is explicitly requested, never as an automatic prerequisite. It does not name alternative sibling tools or describe scenarios where another status tool should be preferred, so it stops short of full when-to-use-versus-alternatives 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?

The annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description does not need to repeat these. The description adds useful context about what information is exposed, aligning with the annotations without contradiction.

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 extremely concise, listing three key data categories in one line and adding the actionable hint 'Start here.' Every word contributes to understanding 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?

For a simple status-gathering tool with no parameters and no output schema, the description adequately covers the kind of information returned (state, capabilities, display geometry). The 'Start here' hint adds helpful context for an agent deciding where to begin.

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

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

The tool takes no parameters, and the schema confirms this. With zero parameters, the baseline is 4, and the description correctly omits parameter details since none exist.

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 specifies the tool's purpose: reporting phone state, enabled capabilities, and display geometry. 'Start here' signals its role as an entry point, distinguishing it from more specific sibling tools like android_device_info or android_ui_tree, though it lacks an explicit verb.

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?

'Start here' implies this tool should be called early to discover device state and capabilities, but it does not explicitly contrast with alternatives or state when not to use it. The guidance is present but minimal.

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

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

Annotations already flag the tool as not read-only, destructive, and non-idempotent, so the description is not burdened with safety disclosure. It adds the behavioral detail that the gesture is expressed in raw screen coordinates, but it does not mention possible effects such as navigation, dismissal, or destructive actions.

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

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

One short sentence with no filler, and the core action is front-loaded. It is efficient but so terse that it omits useful qualifiers; still, this is conciseness rather than bloat.

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

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

With five parameters, no output schema, and no parameter descriptions, a four-word description is insufficient. The agent is left without usage guidance, duration semantics, coordinate-system details, or disambiguation from android_scroll.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. 'Screen coordinates' clarifies that x1/y1/x2/y2 are raw screen positions, but it does not explain durationMs, units, coordinate origin, or that the swipe goes from (x1,y1) to (x2,y2).

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

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

The description names a specific verb (Swipe) and resource (screen coordinates), making it clear this is a coordinate-based gesture tool. It is distinguishable from taps and long-presses, though it does not explicitly differentiate itself from the sibling android_scroll.

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

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

No guidance is provided about when to use this tool rather than android_scroll, android_ui_click, or other gesture tools. The one-line description leaves the selection decision entirely to the agent.

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

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

The annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't need to repeat that. It adds no extra context about potential side effects (e.g., triggering navigation, changing state) beyond the suggestion to inspect the UI first. This is acceptable but not enriching.

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 extremely concise, containing only two short sentences. Every word serves a purpose: the first states the action, the second provides a caution. No fluff or redundant information.

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

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

For a simple tool, the description covers the essential action and a precaution, but it lacks important context such as coordinate system details, whether the tap is absolute or relative, and how this differs from similar tools. Given the simple nature, a 3 is appropriate.

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 description does not explain the meaning of x and y beyond 'screen coordinate.' It does not specify units (pixels), origin (top-left), or any coordinate system details. The schema only provides numeric bounds, leaving the agent to infer the semantics from the name alone.

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: 'Tap a screen coordinate.' It is specific and aligns with the tool name. The additional instruction to inspect UI or screenshot first adds context but doesn't obscure the purpose.

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

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

It provides a general guideline to inspect the UI or screenshot before tapping, which implies you need visual context. However, it does not explicitly compare with alternative tools like android_ui_click or android_long_press, leaving the choice to the agent based on implicit differences.

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

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

Annotations already supply destructiveHint:true, readOnlyHint:false, and idempotentHint:false, so the safety profile is covered. The description adds a non-obvious behavioral trait: if the matched element is not clickable, the tool falls back to the nearest clickable ancestor. This is genuine context an agent cannot infer from the annotations or schema alone. No contradiction with annotations exists.

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 tightly-written sentence with the action verb ('Click') front-loaded, followed by the selection scope ('Nth accessibility element matching a selector') and the key fallback behavior ('nearest clickable ancestor'). Every clause earns its place; there is no filler or repetition of schema or annotation 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 description covers the core action and the most important behavioral nuance, but the tool has 13 optional, undocumented parameters and no output schema. It leaves unanswered questions an agent will face when invoking it: what happens on no match, whether any result is returned, whether the tool waits for UI stability, and how filters combine. For a tool of this complexity, additional guidance would meaningfully improve call success.

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 13 undocumented parameters, but it only loosely maps 'Nth' to the index field and 'selector' to the filter fields generically. It does not explain how multiple selector fields combine (AND vs OR), which fields caseSensitive applies to, the meaning of enabled/visible/editable as filters, or what happens when no selector is provided. With 13 parameters, this is insufficient.

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 ('Click'), a specific resource ('accessibility element'), and a distinguishing selection mechanism ('matching a selector', 'Nth'). The 'nearest clickable ancestor when necessary' clause further separates it from coordinate-based clicks like android_tap and from read-only query tools like android_ui_find. An agent can tell exactly what this tool does and how it differs from siblings.

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

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

The description implies usage context: this is the selector-based clicking tool rather than a coordinate-based tap (android_tap) or a pure query tool (android_ui_find). However, it never explicitly names alternatives, states when to prefer this over android_tap/android_ui_find, or gives exclusion conditions such as 'use this only when you have an accessibility selector rather than screen coordinates.' The guidance is implied, not stated.

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