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

No annotations are provided, so the description carries the full burden. It explains the core behavior (forwarding a port) and warns about silent fallback in React Native development. However, it does not disclose what happens if the forward already exists, error handling, or required permissions. This is adequate but not complete.

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

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

The description is two sentences plus a final clause, all contributing useful information. It is slightly verbose but not overly long. The key points are front-loaded (purpose, canonical use) and then warning and parameter note follow.

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 no output schema and no annotations, the description is fairly complete. It covers the purpose, usage context, key parameter (remove), and even references a related tool (app_state). It does not describe return values, but that is acceptable without an output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context: 'canonical use is tcp:8081 for Metro' for device_port and mentions remove=true behavior. However, it does not add significant meaning beyond the schema descriptions, which already cover all 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 clearly states the tool forwards a DEVICE TCP port to a HOST port (adb reverse). It specifies the canonical use case (tcp:8081 for Metro), distinguishing it from other adb tools like list_devices or logcat. The verb 'forward' and resource 'TCP port' are explicit.

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 says this is 'CRITICAL for RN/Expo dev clients' and explains when to use it (before a dev-client session) and what to suspect if edits have no effect. It also mentions the remove parameter to undo the forward. It does not explicitly state when not to use it, but the context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains what is reported, what happens with Metro vs embedded bundles, the concrete pitfall of a wrong dev server on port 8081, and the guarantee that source_path always yields a stale_verdict with a reason and 'never silence.'

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 longer than average, but every section earns its place: the report contents, the Metro/embedded distinction, the stale-server failure mode, the source_path contract, and the recommended first-use scenario. It is slightly dense and stylistically emphatic, which prevents a 5, but it remains front-loaded with the core purpose.

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

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

There is no output schema, so the description must explain return value semantics itself. It does so in detail: runtime states, process details, Metro server identification, and the exact stale_verdict enum with its guarantee of a reason. Given the tool's complexity and lack of annotations, this is a complete and self-sufficient definition.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics for source_path by explaining the mtime comparison and Metro-root check, and clarifies the stale_verdict values. It does not add much beyond the schema for serial and package, but those are already adequately documented and simple.

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: 'Report an app's RUNTIME state' and then enumerates exactly what that includes (installed, running, foreground, pid, Metro vs embedded, etc.). This clearly separates it from sibling tools like get_app_details or launch_app by focusing on runtime diagnostics rather than metadata or actions.

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 explicit actionable guidance: 'Run this FIRST when JS edits seem to have no effect' and tells the caller to pass source_path to obtain a stale_verdict. It does not name specific sibling tools or state when not to use it, but the use case is clearly scoped.

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

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

No annotations are provided, so the description carries the full burden. It reveals that operations are run via 'adb emu avd snapshot', which implies device-specific behavior. It explains the purpose of snapshots ('deterministically reset the device') and notes the emulator-only constraint. A minor gap: it doesn't mention potential side effects (e.g., data loss on delete) or permission requirements.

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

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

The description is extremely concise: two sentences with zero waste. The first sentence defines the tool and its actions, the second provides usage guidance. 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?

Given the tool's moderate complexity (3 params, 4 actions), the description is nearly complete. It covers purpose, usage scenarios, and device constraints. Lacking: mention of return values (e.g., list returns a list of snapshots) or error cases (e.g., what happens if name doesn't exist on load). The absence of an output schema makes this a small gap.

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

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

Schema description coverage is 100%, meaning the schema already documents all parameters. However, the description adds substantial value by clarifying the action list, explaining that 'name is required for save/load/delete; ignored for list', and noting the serial is optional when only one device is attached. This enhances understanding 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 clearly states the verb 'Manage' and the resource 'emulator AVD snapshots', and specifies the exact actions (save, load, delete, list) with concrete examples like saving a known-good state and resetting the device. It distinguishes itself from siblings like boot_emulator and shutdown_emulator by focusing on snapshot operations rather than device lifecycle.

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 usage context: 'Save a known-good state, then load it to reset the device deterministically between runs' and highlights when this is better than alternatives ('faster than a wipe_data cold boot'). It also notes 'Emulator-only', implying it's not for physical devices. However, it does not explicitly state when not to use it or name alternative tools for related tasks.

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

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

With no annotations provided, the description must disclose behavioral traits. It does well by noting that the emulator launches detached and waits for full boot by default. However, it omits details about error handling, what happens if the AVD does not exist, or the potential destructiveness of the 'wipe_data' parameter (though that is in the schema).

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

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

The description is three sentences, front-loaded with the core purpose, followed by behavioral details and a usage hint. Every sentence adds value and there is no redundancy.

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

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

Given the tool has 5 parameters and no output schema, the description covers the main aspects: what it does, what it returns, how it behaves (detached, waits), and a usage hint. It does not cover edge cases like multiple boots or error states, but it is sufficient for typical use.

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

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

Schema coverage is 100%, so the base score is 3. The description does not add significant new information about parameters beyond what the schema already provides. It mentions the return value (serial) but that is not a parameter 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 clearly states the action ('Boot an AVD by name'), the resource ('AVD'), and the output ('return its device serial'). It distinguishes from siblings like 'list_avds' (which lists but does not boot) and 'shutdown_emulator' by specifying the boot and launch 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 provides context on when to use the tool (e.g., 'Use the returned serial for later tools if you boot more than one device') and sets expectations about boot duration. However, it does not explicitly state when not to use it or mention alternatives like 'list_avds' to check existing devices.

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

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

No annotations are provided, so the description carries full burden. It discloses the default Gradle task (assembleDebug), the APK selection heuristic (newest non-test APK), and the overall pipeline. However, it omits details like error handling, blocking behavior, or prerequisite checks, which are important for a composite tool.

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

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

Three sentences: first states the core action, second provides sibling equivalence, third adds a critical nuance about multi-APK handling. Every sentence adds value; no wordiness or redundancy.

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

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

Given the tool's complexity (three-step process) and absence of an output schema, the description covers the main flow but lacks information on return values, success/failure indicators, or error behavior. More detail on what the agent can expect after execution 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?

Schema description coverage is 100%, so baseline is 3. The description does not add meaningful new semantics beyond what the schema already provides (e.g., default task, optional project_dir). It mentions the default task again but no extra depth or context for parameter usage.

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 does a one-shot build, install, and launch sequence. It uses specific verbs and resources ('runs Gradle', 'installs resulting APK', 'launches package') and explicitly distinguishes itself from sibling tools gradle_build, install_app, and launch_app by noting equivalence but single-call convenience.

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 explains that the tool is equivalent to three separate steps performed together, which implicitly guides agents to use it when a combined operation is desired. However, it does not explicitly state when not to use it (e.g., needing custom build flags or selective steps), leaving some ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates this is an emulation-only tool that affects radio state (which can disrupt connectivity), and that every field is optional. It does not disclose whether changes are reversible, what happens if two serials are attached, or if there are side effects like dropping ongoing calls. While reasonably transparent, there is room for more detail.

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 paragraph of about 60 words, front-loading the core action first. Every sentence adds information: purpose, parameters, use cases, constraints. It avoids redundancy but could be slightly more structured (e.g., separate sentences for each aspect) without adding length.

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 there is no output schema and no annotations, the description covers the essential purpose, parameters, use cases, and constraints (emulator-only) adequately for a tool with 6 optional parameters. It explains how to specify throughput and latency both as named profiles and raw values. It could be more complete by mentioning that changes may affect other running apps or that serial is required when multiple devices are attached.

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 already provides full (100%) coverage with descriptions for each parameter, so the baseline is 3. The description adds value by explaining the meaning of signal strength values and giving examples for network_delay and network_speed (e.g., 'lte', '<up>:<down> kbps'), which enriches understanding beyond the schema. However, it does not explain the enum values for data/voice or the effect of profiles like 'full'.

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 specific verbs ('Shape the emulated cellular radio') and clearly identifies the resource (cellular radio on an emulator). It enumerates the three controllable aspects (registration state, signal strength, throughput/latency) and distinguishes it from sibling tools like phone_call or send_sms which are also telecom-related but perform different actions.

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 tool is 'Emulator-only', which is crucial for knowing when not to use it (e.g., on physical devices). It also provides example use cases ('Test offline/roaming/weak-signal and slow-network behaviour deterministically'), giving clear context. However, it does not mention alternatives or explicitly say when to avoid this tool in favour of others.

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

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

With no annotations provided, the description carries the full burden of disclosure. It clearly states the tool is destructive ('Wipe an app's data and cache'), implies no rollback, and uses the phrase 'from scratch' to convey irreversibility. A 4 is appropriate because it effectively communicates the mutation behavior, though it could mention potential side effects (e.g., login tokens lost).

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 that conveys purpose, mechanism, effect, and use case without any wasted words. It is front-loaded with the key action and parenthetical command, making it immediately scannable.

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

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

Given no output schema, the description could mention what the tool returns (e.g., success/failure message), but for a destructive command like 'pm clear', the effect is the primary concern. The description completely covers intent and behavior for an agent, earning a 4 for being nearly complete in context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose ('reset to first-launch state') and the underlying command ('pm clear'), but it does not elaborate on parameter details beyond what the schema provides, such as the optional nature of 'serial' or format of 'package'.

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-resource pair ('Wipe an app's data and cache') and clearly identifies the tool as a 'pm clear' equivalent. It explains the effect ('reset to a first-launch state') and the use case ('reproduce onboarding/permission flows'). This distinguishes it from siblings like 'uninstall_app', 'stop_app', 'clear_logcat', and 'clear_device_lock'.

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 use case ('fastest way to reproduce onboarding/permission flows'), providing clear context for when to use this tool. However, it does not mention when not to use it or explicitly name alternatives among the siblings, such as 'uninstall_app' or 'stop_app' for less destructive resets.

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?

Since no annotations are provided, the description carries full burden for behavioral disclosure. It clearly states this is a destructive action ('Remove the secure lock screen') and explains the dependency on providing the current credential. It also specifies the post-condition ('restore a clean state'), which adds useful behavioral context beyond just naming the 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 two sentences with zero wasted words. First sentence front-loads the core action and required input. Second sentence provides usage context. Every sentence earns its place. No extraneous 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 tool with only 2 parameters (both well-documented in schema), no output schema, and no annotations, the description adequately covers what the tool does, what input is required, and the typical usage scenario. It could mention what happens if the credential is wrong (error behavior) to be fully complete, but the existing information is sufficient for correct selection and invocation 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 100%, so baseline is 3. The description adds value by explaining the semantics of 'old_value' as 'the current credential, needed to clear the lock', which reinforces the schema description. For 'serial' it does not add new details, but the schema already adequately defines its optionality and purpose, so the overall contribution lifts the score slightly.

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 ('Remove') and resource ('secure lock screen'), clearly linking to credential parameter 'old_value'. It also distinguishes from its sibling 'set_device_lock' by indicating this is the reverse operation, and frames the purpose within a testing context.

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 ('after testing a Keystore flow') but does not provide explicit when-not-to-use guidance or contrast with other lock-related tools like 'set_device_lock', 'prefer_pin', or 'enter_pin'. Without sibling differentiation or alternative recommendations, usage guidance is adequate but incomplete.

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

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

No annotations exist, so description carries full burden. It honestly describes the destructive effect (empties buffer) and the impact on subsequent logcat reads (every line read is caused by the action). Does not mention prerequisites (adb connection) but is otherwise transparent for this simple mutation.

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 concise sentences plus a parenthetical alternative. Front-loaded with action, no filler words. 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?

Given the simple tool (1 optional param, no output schema), the description covers purpose, usage, effect, and alternative. No gaps. The isolation primitive analogy provides rich context.

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

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

Schema description coverage is 100% for the single 'serial' parameter, with adequate explanation in schema. Description does not add parameter-specific semantics beyond the schema, so baseline 3 is appropriate.

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

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

Description uses specific verb 'Empty' and resource 'logcat ring buffer', clearly stating the action. It distinguishes from sibling tools like logcat (read) and start_logcat_capture (capture to file) by focusing on clearing the buffer as an isolation primitive.

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

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

Explicitly explains when to use: as the sharpest isolation primitive for a press→observe loop. Provides when-not-to-use context (filter hits may be seconds old, empty result may mean buffer rotated). Names an alternative: 'use logcat's since param' for reaching back in time.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two-step process (pair then connect) and the roles of host:port, pair_address, and pairing_code. However, it does not mention what happens on failure, network prerequisites, or the state of previous connections, which would be helpful.

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 at two sentences with no filler. It front-loads the core action and covers the key parameters efficiently. Every sentence adds value.

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 moderate complexity (3 parameters, no output schema, no annotations), the description adequately explains the tool's purpose and workflow but does not specify return values or error handling. It is sufficient for a basic connection tool but could be improved.

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 already provides 100% coverage with clear descriptions for host_port, pair_address, and pairing_code. The description adds minimal extra meaning beyond the schema, primarily clarifying the workflow (pairing code from Android 11+). Baseline 3 is appropriate.

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

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

The description uses the specific verb 'connect' and resource 'device over Wi-Fi/TCP', and distinguishes the tool from sibling tools by mentioning ADB operations. It contrasts with siblings that are unrelated to wireless connectivity.

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 explains when to use the tool (for Wi-Fi/TCP connections) and provides explicit instructions for pairing with the 6-digit code from Android 11+ Wireless debugging. It does not directly name alternative tools for other connection methods, but the context is clear 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals critical behaviors: focused-window detection including system overlays, hidden-node count in the response header, viewport scoping for all modes, Android's omission of off-screen ScrollView children, and complete invisibility of canvas-drawn content. This is rich, non-obvious 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 dense but every sentence carries distinct operational value: output contents, aiming rule, screenshot warning, response header, filter modes, viewport limitation, and canvas limitation. The structure front-loads the core purpose and progressively adds edge-case warnings without 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?

Since there is no output schema, the description must explain what the tool returns, and it does: per-element fields, header contents, compact format, and all critical limitations. It also tells the agent how to interpret absence and when to delegate counting to render_stats. Nothing needed for correct invocation and interpretation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces filter semantics and the viewport caveat, but the schema already explains query, filter, serial, compact, and package in comparable detail. The description adds no substantial parameter-level meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Read the on-screen UI hierarchy as a list of elements' followed by the exact fields returned. It explicitly differentiates from screenshots by calling itself the 'source of truth for AIMING' and warns against guessing coordinates from the downscaled screenshot, clearly separating it from sibling tools like screenshot and render_stats.

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 explicit when-to-use and when-not-to-use guidance: use render_stats instead for counting long lists, scroll before concluding absence, filter='all' to prove absence in the current viewport, and compact mode for repeated look-drive loops. It also names the screenshot alternative to avoid. This is far beyond implied 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?

With no annotations, the description carries the full behavioral burden. It conveys a read-only diagnostic intent ('Diagnose') and details what is inspected: SDK path, tools, AVDs, devices, accessibility bridge status, and build tools. It does not explicitly promise zero side effects, but 'diagnose' and the absence of any fix/update language strongly imply it is a non-mutating inspection.

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 dense but well-organized: it front-loads the purpose, uses a colon to launch the checklist, and adds an em-dash rationale for the gradle requirement. There is minor repetition between 'first call of any session that isn't going well' and 'Run this first when something isn't working', so it is not maximally tight.

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 diagnostic tool, the description is complete: it tells the agent when to run it, what subsystems it inspects, and even explains why a system gradle matters. No output schema exists, but the enumerated diagnostic areas give sufficient context for what kind of results to expect.

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 and an empty schema, so there is nothing for the description to explain. The description correctly does not invent parameters, and the 0-parameter baseline of 4 applies because no semantic gap exists.

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

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

The description opens with a specific verb and resource: 'Diagnose the local toolchain' and then enumerates exactly what is checked — SDK path validity, adb/emulator availability, AVDs, devices, accessibility bridge, JDK, and system gradle. This clearly distinguishes it from sibling tools like list_devices or list_avds because it is an aggregated diagnostic rather than a single-feature listing.

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 says to run this tool first when something isn't working, and gives a concrete trigger: a Gradle tool failing with 'SDK location not found'. It does not name alternatives or exclusion cases, but for a diagnostic first-stop tool this context is clear 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?

With no annotations provided, the description carries the full burden. It explains the gesture sequence (press-hold-move-release), the hold-at-start distinction, and the underlying Android API. However, it does not disclose whether the operation is blocking, what happens on invalid coordinates, or any side effects. The given detail is good but not exhaustive.

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, front-loaded with the action and then the usage context. Every sentence is informative with no fluff. It is well-structured 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?

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is reasonably complete. It covers the gesture mechanics, use cases, and sibling differentiation. It lacks details on error handling, device state prerequisites, or return behavior, but for a drag gesture these are not critical omissions.

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

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

Schema coverage is 100% with all 6 parameters documented in the input schema. The description adds minimal value beyond the schema: it mentions 'true device pixels' (already in schema) and the default duration (already in schema). Baseline 3 is appropriate as the description does not introduce new semantic information.

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 ('Press-hold-move-release drag'), the resource (coordinates in true device pixels), and the specific Android input method ('input draganddrop, Android 11+'). It explicitly distinguishes from the sibling tool 'swipe' by noting the hold-at-start behavior, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool: 'use it for drag handles, long-press-to-reorder lists, and drag-and-drop targets a quick swipe skips.' It directly contrasts with 'swipe' (which flings) and gives concrete use cases, though it does not mention alternatives like 'long_press' or 'tap'.

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

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

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait: 'with a settle delay' between taps. It explains the internal logic for detecting native vs. canvas-drawn pads and the corresponding parameter strategies. While it does not specify return values or error conditions, the behavioral description is thorough for a tap-input tool.

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

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

The description is moderately lengthy but every sentence contributes necessary information. It is well-structured: opening with the core purpose and usage trigger, then progressively detailing the pad-type logic and parameter modes. While not ultra-condense, the length is justified by the complexity of the two-path behavior.

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

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

Given the tool's moderate complexity (4 parameters, two modes, no output schema), the description provides a complete workflow: identify pad type via describe_ui, determine parameter requirements, read bounds from screenshot if needed. It does not mention return values or failure modes, but covers the essential user/agent actions for correct invocation.

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

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

Schema description coverage is 100% with well-documented parameters. The description adds significant value beyond the schema by explaining the conditional logic: when to use 'grid' vs 'coords' vs default, and how to obtain the bounding box or coordinates (e.g., 'read those bounds off a screenshot'). This contextual guidance helps the agent decide parameter values.

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 enters digits on a numeric PIN pad by tapping each key with a settle delay. It explicitly distinguishes from sibling 'input_text' by specifying when to use this tool ('Use when input_text does nothing because the pad renders its own key views'). The verb 'enter', resource 'digits on a numeric PIN pad', and method 'tapping each key' combine for a specific, actionable 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?

The description provides explicit when-to-use guidance: 'Use when input_text does nothing'. It also details how to choose between default, 'grid', and 'coords' parameter modes based on the pad type (native vs. canvas-drawn), instructing the agent to first run 'describe_ui' and potentially read bounds off a screenshot. This offers clear decision criteria and 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?

With no annotations provided, the description fully carries the behavioral burden. It discloses that the command reports OK even on failure, explains the enrollment ID increment issue, and details edge cases like indefinite hanging without enrollment. This goes beyond what annotations could convey.

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 moderately concise for the complexity it covers. It front-loads the core action and then adds important gotchas and troubleshooting. While thorough, it could be slightly more streamlined, but every sentence earns its place for a tool with no annotations and complex behavior.

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

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

Given no output schema and no annotations, the description is remarkably complete. It covers prerequisites, failure modes, troubleshooting, and device constraints. For a tool with high behavioral nuance (2 params, but many edge cases), this provides all necessary 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 schema covers 100% of parameters, so baseline is 3. The description adds meaningful value by explaining the semantics of finger_id (must match enrolled finger, default 1, suggestion to try multiple values) and serial (target device, optional). This elevates it above baseline.

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

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

The description clearly states the tool simulates a fingerprint-sensor touch on an emulator, specifies it drives the real biometric unlock path, and distinguishes it from alternatives like PIN fallback. The verb 'Simulate' and resource 'fingerprint-sensor touch' are specific, and the context of BiometricPrompt sets it apart from 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 explicitly instructs to check has_biometric_enrolled FIRST, warns about the GOTCHA with non-matching finger_id, and provides concrete troubleshooting steps (try ids 2..5, second touch, re-enrollment). It also states the tool is emulator-only, guiding when not to use it.

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

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

With no annotations provided, the description bears full responsibility for disclosing behavior. It reveals the underlying ADB command, confirms it is a simulation action, and notes the emulator-only restriction. For a simple one-parameter tool, this is sufficient to understand what the tool does and its context, though it could mention that it requires a prior fingerprint touch to be meaningful.

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: two sentences that get straight to the point. The first sentence states the action and underlying command, the second provides usage context and restrictions. No filler 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 with one optional parameter and no output schema, the description covers all essential context: what it does, how it relates to a sibling tool, when to use it (finger-up event flows), and the emulator-only constraint. There are no gaps in completeness for this tool's complexity.

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

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

The input schema has 100% coverage for the single optional 'serial' parameter, so the schema already documents its meaning. The description does not add any additional context or nuance about the parameter beyond what the schema provides, meeting the baseline expectation.

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 ('lift the simulated finger off the sensor') and the resource (finger on sensor). It explicitly positions itself as the complement to 'fingerprint_touch', distinguishing it from that sibling tool. The verb and resource are specific and unambiguous.

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

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

The description states it is for 'flows that watch for the finger-up event' and notes it is 'emulator-only'. This gives clear context for when to use it, though it does not explicitly list conditions where it should not be used or mention alternatives beyond the stated complement.

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

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

With no annotations provided, the description must disclose behavioral properties fully. It mentions the underlying commands (dumpsys package + resolve-activity), which is helpful for understanding scope and side effects. However, it does not disclose whether the tool modifies state, requires specific permissions, or has rate limits.

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 minimal words, front-loads the key output, and appends the implementation hint in parentheses. 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?

Given the tool's moderate complexity (2 params, no nested objects, no output schema), the description adequately covers what the agent needs: what it reports and how it works. Still, without output schema, a brief note on return format 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?

Schema coverage is 100%—both parameters (serial, package) have descriptions in the schema. The description adds context about what the tool reports (version name/code, launchable activity) but does not elaborate on the parameters beyond what the schema provides. Since coverage is complete, the baseline is 3; the slight additional context justifies a 4.

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

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

The description clearly identifies a specific verb-resource pair: 'Report an installed app's version name/code and its launchable activity'. It distinguishes from sibling tools like list_packages (which lists packages) and launch_app (which launches), providing a clear, unique 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?

The description implies usage context—confirming what build is installed and finding the launch activity—but does not explicitly state when to use this tool versus alternatives like list_packages, launch_app, or stop_app. It gives no guidance on when not to use it.

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

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

with no annotations provided, the description carries full burden and meets it: it discloses that the default task runs jvm unit tests first, that in multi-module builds reports are merged, and the json option for structured output. it also explains the caveat about task availability and fallback, providing complete 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?

description is relatively compact for the amount of detail provided; front-loaded with the main action. the important caveat section is capitalized. one minor improvement: the fallback instructions could be slightly more succinct.

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 moderate complexity (4 params, no output schema, no annotations) the description leaves no essential gaps. it explains default behavior, multi-module handling, fallback for missing tasks, scope limits (jvm only), and output format options. no need for more.

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

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

schema coverage is 100% so baseline is 3. the description adds some context for the task parameter (explaining the non-default nature of jacocoTestReport and fallback task) but the other parameters (args, json, project_dir) are adequately described in the schema already. no significant extra value beyond 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?

description clearly states the tool runs a specific gradle task and summarizes code coverage with detailed metrics (line/branch/method/class percentages, per-package breakdown). it distinguishes itself from similar sibling tools like get_file_coverage or run_unit_tests, covering a distinct 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?

description explicitly tells when to use this tool, warns that jacocoTestReport is not an android gradle plugin default, and tells the agent to fall back to list_gradle_tasks and pass the built-in createDebugUnitTestCoverageReport instead. also clarifies it covers only jvm unit tests, not instrumented tests, and states there is no on-device analogue.

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

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

No annotations are provided, so the description carries full burden. It discloses the underlying JaCoCo task and fallback, the file matching algorithm, the output format options (text vs JSON), the scope (JVM unit tests), and the relationship to get_coverage_report. It is non-destructive, but this is not explicitly stated; however, the read-only nature is implied by the coverage analysis 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 well-structured paragraph that packs essential information without redundancy. It starts with the core purpose, then flows into usage guidance, file matching details, and output options. It is concise but could benefit from slight formatting (e.g., bullet points for clarity), though current structure is effective.

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 complexity (5 parameters, no output schema, no annotations), the description covers all key aspects: purpose, usage relation to sibling, parameter behavior, file matching edge cases, and output format options. It does not describe the exact structure of the JSON/text output, but the details provided are sufficient for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains the default task behavior and fallback, clarifies that file matching is by suffix, describes handling of ambiguous names and misses, and notes the optionality of project_dir. This extra context justifies a score above baseline.

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

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

The description clearly states the tool's purpose: a JaCoCo coverage report scoped to one source file, providing line/branch coverage, missed lines, and per-method detail. It distinguishes itself from the sibling get_coverage_report by explaining that it operates at the file level with per-function breakdown, not package-level summary.

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

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

Explicitly guides when to use this tool: 'Use it to find WHICH lines to write a test for, after get_coverage_report says which package is weakest.' It also explains file matching behavior (suffix match, ambiguous names return all matches, misses list available data) and the scope (JVM unit tests only), providing clear context for selection.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior (build, report APK paths, default task, host execution) and a prerequisite. It does not mention potential side effects, error conditions, or execution time, but the disclosed information is sufficient for basic understanding.

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 three concise sentences with no fluff. Each sentence adds essential information: purpose and default, prerequisite, and host-vs-device distinction. The structure is logical and front-loaded.

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 basic purpose, default, prerequisite, and host execution. However, it lacks details on the return format of APK paths, error handling, and potential timeouts. With no output schema, more explanation of the return value 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?

Schema coverage is 100%, so baseline is 3. The description adds value by stating the default task (assembleDebug) and clarifying that the json parameter is ignored by this tool. This goes beyond the schema descriptions.

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

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

The description clearly states the tool builds the app with Gradle, specifies the default task assembleDebug, and reports produced APK paths. It distinguishes from siblings like build_and_run by noting it runs on the host, not a device.

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 prerequisite (project_dir must contain gradlew) and a key usage distinction (runs on host, not device). However, it does not explicitly name alternative tools or state when not to use this tool.

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

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

With no annotations, the description carries full weight. It discloses the scope (one module), the fact that it returns the full effective property set (like ./gradlew properties), and importantly warns that credentials may be included but are redacted for secret-shaped keys. This is thorough behavioral documentation.

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 four sentences, each adding essential information. It is front-loaded with the core purpose, then usage context, then behavioral details. No wasted 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?

Given the lack of an output schema, the description does a good job clarifying what the agent will receive (full property set, redacted secrets). It covers sensitivity and scope. However, it could mention the output format (e.g., key-value pairs) for even better 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?

Schema coverage is 100% for both parameters, so the baseline is 3. The description reinforces that module uses the ':app' format and that project_dir is optional (possibly set by session_set_defaults), but does not add significant information 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 uses a specific verb ('Dump') and resource ('Gradle's evaluated properties for one module'), clearly distinguishing the tool from siblings like list_gradle_projects. It explicitly contrasts the output (effective configuration vs. task/variant names), making the purpose unambiguous.

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

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

The description explicitly states when to use this tool ('Use after list_gradle_projects when you need the module's namespace...') and what alternative provides ('rather than just its task/variant names'). This gives the agent clear context for selection among related tools.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It reveals the key behavior of bypassing the permission dialog, but omits other important traits: what happens if the permission is already granted, whether the tool requires root or specific Android version, error handling, or side effects on other apps. The disclosure is partial and insufficient for a system-mutating tool.

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

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

The description is a single sentence with a dash and an example, front-loading the core action. Every word earns its place: the verb, the resource, the implementation hint ('pm grant'), the example, and the user benefit. No redundant text or unnecessary details.

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 absence of an output schema, the description should describe what the tool returns or error behavior. It does not mention success/failure responses, side effects, or status codes. The tool modifies system permissions, yet the description omits critical context about return values, error cases, and post-conditions.

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

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

Schema description coverage is 100% (all three parameters have descriptions in the schema). The description adds only a reinforcing example ('android.permission.CAMERA') and implicitly notes that serial is optional (since it is not required in the schema). This meets the baseline but does not provide additional meaning beyond the schema.

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

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

The description clearly states the action ('Grant a runtime permission'), specifies the target resource ('an app'), provides a concrete example ('android.permission.CAMERA'), and distinguishes the tool from the sibling 'revoke_permission' by its verb. It also explains the practical benefit of skipping the dialog, making the purpose 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 the tool ('skip the in-app permission dialog so you can drive straight to the feature') but does not explicitly state when not to use it, mention alternatives like 'revoke_permission', or note prerequisites (e.g., device debug mode). The context is adequate but lacks exclusions or boundary 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?

No annotations are provided, so the description must carry the full burden. It discloses key behaviors: works on emulators and physical devices, the framework only exposes an enrolled count (never which finger id), and that a wrong fingerprint_touch id trips a HAL lockout after a few tries. It also advises enrolling deterministically. While it covers most behavioral traits, it does not mention whether the tool requires any special permissions or adb setup, leaving a minor gap.

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 three sentences: the first states the core function, the second provides critical usage guidance, and the third adds behavioral nuances. Every sentence serves a distinct purpose without redundancy or fluff. It is well-front-loaded and concise.

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

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

Given the simplicity (1 optional parameter, no output schema, no nested objects), the description is fully adequate. It provides purpose, usage context, behavioral insights, and practical advice. There is no missing information needed for an agent to correctly select and invoke this tool.

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

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

Schema description coverage is 100%, so the schema already documents the single optional 'serial' parameter. The description does not add additional meaning about the parameter beyond the schema. Baseline 3 is appropriate.

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

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

The description explicitly states the tool reports whether any fingerprint is enrolled and how many, from 'dumpsys fingerprint'. The verb 'Report' and resource 'biometric enrollment' are specific. It clearly distinguishes from siblings like 'fingerprint_touch' (which performs a touch) and 'finger_remove' (which removes enrollment), making its purpose unique.

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 when-to-use guidance: 'Check this BEFORE a biometric flow'. It explains the consequence of not checking (fingerprint_touch can never satisfy BiometricPrompt and just sits on 'Touch the sensor') and gives explicit branching alternatives ('branch to enrolling one or to the PIN path instead of guessing'). This is exemplary usage guidance.

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

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

No annotations exist, so the description carries full burden. It explains key ordering, modifier priority, and preset expansion. Lacks details about error handling or return values, but provides sufficient behavioral context for a chord press.

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?

Single dense paragraph is efficient and front-loaded with key info (chord, Android 11+). Could benefit from bulleted examples, but 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 three-parameter tool with no output schema, the description covers usage, parameter selection, and alternatives. It is complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100% with descriptions, but the tool description adds extra meaning: examples like ["ctrl","a"], explicit ordering 'modifier(s) first', and listing preset names. This goes beyond the schema 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?

Description clearly states it presses several keys together as a chord on Android 11+. It explicitly contrasts with press_key for single keys, distinguishing itself from a sibling tool.

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

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

Provides explicit guidance on when to use preset vs keys, and directs users to use press_key for a single key. Also notes the Android 11+ requirement, giving clear context for 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?

With no annotations provided, the description fully bears the burden of behavioral disclosure. It discloses all key behaviors: the IME mechanism, the prerequisite focus requirement, the side effect of keyboard obstruction, the suggested mitigation, and the specific failure case (native PIN pads). No contradictions present.

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 3 sentences, front-loaded with the primary action, 135 characters per sentence average. Every sentence provides distinct value: primary action, prerequisite, and post-action guidance with alternative tool reference. Slightly longer than strictly necessary but no wasted words.

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

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

Given the complexity of text input on mobile devices (IME vs native, keyboard obstruction), the description is complete. There is no output schema, but the side effects and failure modes are well documented. The description covers prerequisite, mechanism, side effect, mitigation, and the known exception case comprehensively.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: 'serial' is documented in the schema, but the description adds the 'via the IME' mechanism and keyboard dismissal context for 'text'. The description does not repeat the schema's parameter definitions verbatim but adds operational context that clarifies the intended usage of the 'text' 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 uses a specific verb ('type text') and identifies the target resource ('currently focused input field') with a clear mechanism ('via the IME'). It also explicitly distinguishes itself from the sibling tool 'enter_pin', which handles native PIN pads, preventing confusion.

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 explicit step-by-step guidance: tap the field first for focus, and dismiss the keyboard with press_key escape/back before tapping other buttons. It also explicitly states when NOT to use this tool (for native non-IME PIN pads) and directs to the alternative 'enter_pin'.

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

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

No annotations are provided, so the description carries full burden. It only mentions install/reinstall but lacks details on side effects, permissions, multi-device behavior, or completion status. This is insufficient for safe autonomous use.

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

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

Two short sentences, no redundant words. The core action and purpose are front-loaded, 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 simple install tool with no output schema and no annotations, the description covers the basic purpose but omits crucial details like error handling, timeout behavior, return format, and device selection fallback. It is adequate but not fully complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaningful information beyond the schema; it repeats 'local file path' which is already in the apk_path parameter description. No extra 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?

Description clearly states the verb 'Install (or reinstall, -r)' and the resource 'APK from a local file path onto the device', making the tool's action unambiguous. It distinguishes from siblings like launch_app by specifying deployment of a local build for testing.

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 'Use to deploy a build you want to test' provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives like uninstall_app or launch_app, leaving room for improvement.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool reports a boolean state and frames it as a verification step, adding context beyond a bare API name. It does not mention side effects (likely none), but for a simple read-only query, this level of transparency 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?

Two sentences: the first states the core function and API, the second gives a concrete use case. Every word earns its place, and the front-loaded structure makes the tool's purpose 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 simple query tool with one optional parameter, the description fully covers what the tool does, when to use it, and its relationship to set_device_lock. No output schema exists, but 'Report whether' already conveys the return type. The context is complete for an agent to select and invoke it correctly.

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

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

The schema has 100% description coverage for the single optional 'serial' parameter, so the schema already documents its meaning. The description adds no additional parameter semantics, which is acceptable since schema coverage is high.

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

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

The description uses a specific verb ('Report') and resource ('secure lock screen'), and specifies the underlying API (KeyguardManager.isDeviceSecure). It clearly distinguishes from sibling tools like has_biometric_enrolled by focusing on lock-screen security rather than biometrics.

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

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

It explicitly says 'Use it to verify set_device_lock worked before running a Keystore-gated flow,' providing a clear when-to-use scenario. It does not explicitly mention when not to use or list alternatives, but the directive is unambiguous for common cases.

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

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

No annotations are provided, so the description fully covers behavioral aspects: it describes the data source (dumpsys dropbox), types of crashes (JVM/React-Native and native), and that it returns full exception headers and stacks. The only minor gap is not mentioning that the operation is read-only or any impact on system state, but it clearly implies a read 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 two sentences, each earning its place: the first sentence states the tool's capability and source, the second provides usage guidance and rationale. It is front-loaded with the essential purpose.

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 that there are only 2 parameters, no required parameters, no output schema, and no annotations, the description is adequately complete. It explains the tool's purpose, usage advice, and filtering option. The only missing aspect is specifying the return format, but without an output schema 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?

Schema description coverage is 100%, so baseline is 3. The description adds context for the 'package' parameter (how to filter) but does not add meaning beyond what the schema already provides. The 'serial' parameter is standard across sibling tools and requires no additional explanation.

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

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

The description states the tool returns the most recent app crash from the system DropBox, specifying the source (dumpsys dropbox) and type (JVM/React-Native and native crashes). It distinguishes itself from siblings like logcat by explaining it retrieves full exception headers and stacks in one call.

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

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

The description explicitly states when to use this tool: 'Use this instead of grepping logcat when an app just crashed', and gives a clear alternative (logcat). It also explains the advantage (DropBox keeps the whole fatal, even after it has scrolled out of logcat).

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It states the launched activity type, success indicator (echo component), and error conditions (missing package or launcher). The usage pattern with stop_app adds transparency about side effects and state management.

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 (three sentences), front-loaded with the main action, and every sentence adds value. No filler or redundant information. It efficiently conveys purpose, behavior, and usage.

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 with no output schema and good parameter documentation, the description is largely complete. It covers success/failure behavior and a common usage pattern. Minor gap: the output format ('echo') is implied but not explicitly defined.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the input schema already provides for the two parameters (package and serial). No additional context about parameter values or constraints is 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's purpose: 'Launch an app by package name (starts its LAUNCHER activity) and echo the resolved component on success.' It uses a specific verb-resource combination and distinguishes itself from siblings like stop_app by explaining how to combine them for a clean restart.

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 explicit guidance on when to use the tool and what to expect on failure ('Fails with a clear message when the package isn't installed or has no launcher activity'). It also suggests a common workflow with stop_app, though it doesn't explicitly mention alternatives for deep links or other launch methods.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the deep-link construction, default host/port behavior, and the embedded-bundle fallback when adb_reverse is not set. It doesn't document the return value or post-launch behavior, but the core operational traits are 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?

Four sentences, all information-dense and directly useful. The main verb and outcome are front-loaded, the prerequisite and alternative are clearly flagged, and no words are wasted.

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

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

Despite having no output schema and no annotations, the description covers the essential context: prerequisite setup, fallback behavior, parameter sources, and distinction from a sibling tool. For a tool with five parameters and a specific launch flow, this is a complete and actionable description.

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 already provides rich descriptions for all five parameters (100% coverage), including defaults and device-visibility notes. The description adds context for scheme's source (app.json) and host/port defaults, but these largely repeat or infer what the schema already states, so the added semantic value is limited.

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 action: launching an Expo dev build directly at a Metro dev server, bypassing the Dev Launcher's server-picker. It explicitly distinguishes itself from open_url for plain Expo Go, which is a key sibling differentiator.

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 explicit when-to-use context (dev build vs Expo Go) and names the alternative (open_url with exp://). It also gives a clear prerequisite (adb_reverse tcp:8081) and explains the consequence of skipping it, offering concrete operational guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool lists AVDs that 'can be booted', implying a read-only operation, but does not mention any side effects, permissions needed, or how the list is obtained (e.g., from local files or ADB). For a zero-parameter tool with no output schema, some behavioral context is missing.

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

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

The description is two sentences long with no extraneous information. It front-loads the core purpose ('List the Android Virtual Devices') and adds a practical usage hint. 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?

Given the tool's simplicity (no params, no output schema), the description is largely complete: it explains what the tool does, when to use it, and how the output is used. A minor gap is lack of detail on output format (e.g., list of strings, JSON) or edge cases (e.g., no AVDs installed), but the description suffices for an agent to select and invoke the tool correctly.

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

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

The input schema has 0 parameters, and schema description coverage is 100%, so the description adds clarity by explaining what the tool returns (AVD names) and their purpose. No parameter documentation is needed, and the description compensates well by explaining the output usage.

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 'List' and the resource 'Android Virtual Devices (AVDs) installed on this machine', and distinguishes the tool's scope (listing installed AVDs). However, it does not differentiate from sibling tools like 'list_devices' or 'boot_emulator' beyond stating where the names feed into.

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 explicit guidance on when to use this tool ('Start here when no emulator is running yet') and indicates the next step ('the returned names feed boot_emulator'), which implies a workflow. However, it does not mention when not to use it or provide alternatives among the many 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?

With no annotations, the description carries the behavioral disclosure burden. It communicates that the tool is a read-only listing operation and clarifies the adb states it reports. It does not explicitly state the absence of side effects, but 'List' and the focus on device state strongly imply a safe, non-mutating 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 first two sentences are concise and front-loaded with essential information. However, the third sentence about the React Native/Expo guide is tangential to listing devices and introduces workflow advice that may belong elsewhere. It slightly dilutes the tool-focused message.

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 with one optional parameter and no output schema, the description covers the core action, expected state values, and practical use cases. It could be more complete by explicitly describing the return format, but the description is sufficient for an agent to understand what will happen.

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

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

Schema coverage is 100% and the schema already documents the 'serial' parameter with its optionality and adb -s semantics. The description adds marginal context by mentioning serial retrieval when multiple devices are attached, but it does not meaningfully supplement the schema.

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

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

The description states a specific verb and resource: 'List attached emulators/devices and their adb state'. It also defines the state values (device, offline, unauthorized), making the tool's function unambiguous. This distinguishes it from sibling tools like list_avds, which target AVDs rather than attached devices.

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 tells the agent when to use this tool: 'confirm a device is up before driving it' and 'get the serial when several are attached'. It does not explicitly mention alternatives or exclusions, but the usage contexts are clear enough for an agent to decide.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation (listing modules) with no side effects. It does not elaborate on potential errors or prerequisites beyond the gradlew wrapper, but for a simple list tool, this is sufficient. The behavior is transparent enough for an agent to understand the tool's impact.

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 concise single paragraph that front-loads the main purpose. Every sentence adds value: listing the result, usage examples, and a note about single-module builds. There is no redundancy or fluff.

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 absence of an output schema, the description is complete. It explains the tool's output format (modules as paths like ':app'), how to use it, and the edge case of single-module builds. No additional information is needed for effective use.

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 coverage is 100% with a description for the single parameter 'project_dir'. The tool description adds value beyond the schema by explaining the optionality via session defaults (referencing 'session_set_defaults'). This provides crucial context for an agent, elevating it above the baseline 3.

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: listing Gradle modules (sub-projects) in a project directory. It uses a specific verb ('List') and resource ('Gradle modules'), and provides examples like ':app', ':core', ':feature:login'. It differentiates from sibling tools like 'gradle_build' and 'list_gradle_variants' by explaining how the output is used to target those 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 explicitly tells when to use this tool: to find which module to point at 'gradle_build' or 'list_gradle_variants', or to address a task with a module path. It also explains the single-module build case, giving clear context. Though no explicit 'when not to use', the use case is well-defined and leaves no ambiguity.

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 states it runs 'gradlew tasks' which is a read-only operation, implying no destructive side effects. However, since there are no annotations provided, the description should ideally be more explicit about non-destructive behavior, output format (plain text), and potential prerequisites (e.g., Gradle installation). The description is adequate but not exhaustive.

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 a key parenthetical tip. It is front-loaded with the core purpose and efficiently conveys essential usage nuance without extraneous 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?

Given no output schema and moderate parameter count (4), the description adequately covers the tool's purpose, scope, and a key parameter usage (task for submodules). It does not detail return format (text output) or behavior when no task is specified, but the core use case is well-served. A sibling reference to list_gradle_projects adds helpful 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 schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds extra value by explaining the 'task' parameter's special usage for submodule scoping, which is not fully detailed in the schema. Additionally, it clarifies that 'json' is ignored by this tool, providing useful semantic nuance beyond the schema.

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

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

The description clearly states it lists available Gradle tasks via 'gradlew tasks' to discover build/test/install targets. It also distinguishes the scope (root project vs. submodule), which helps differentiate from sibling tools like list_gradle_projects or list_gradle_variants.

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 explains when to use this tool (discover Gradle tasks) and provides a concrete alternative approach for multi-module builds (passing task="<module>:tasks"). It could be stronger with explicit when-not-to-use scenarios, but the sibling context and tip cover key usage guidance.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It clearly states expected behavior (parsing from assemble* tasks, excluding test APKs), the edge case of multi-module root projects, and the relationship to task arg propagation. However, it does not discuss potential latency, error conditions (e.g., project_dir not set), or what happens if no assemble tasks exist, which would push it to a perfect 5 in this unannotated 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, dense paragraph of 4 sentences that front-loads the core purpose in the first sentence, then adds progressively more nuanced context. Every sentence is essential—no fluff, no repetition of schema, and no extraneous explanations. It achieves maximal information density in minimal space.

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 complexity (2 params, no output schema, moderate sibling list), the description is remarkably complete. It covers what the tool does, what it excludes, how variants map to downstream tools, the root project caveat, and cross-referencing to sibling tools like list_gradle_projects and gradle_build. No significant gaps remain for an agent to effectively select and invoke this tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-level detail beyond the schema—it mentions task= and project_dir in the prose but provides no additional syntax, allowed values, or format constraints. This is adequate since the schema already describes both parameters clearly, but the description does not enhance understanding of their role beyond restating schema information.

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-resource pair ('list the buildable build variants') and distinguishes the tool from its siblings by calling it the 'Android analogue of list schemes' and explaining that each variant maps to an assembleV/installV task. It clearly states what is excluded (test-only APK tasks) and how it relates to other tools like gradle_build.

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 guides when to use this tool and when to use alternatives: it explains that variants are passed to gradle_build's task= arg, and for multi-module builds, you should use list_gradle_projects first then task='<module>:tasks'. It covers the root project caveat and scoping advice, leaving no ambiguity about 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only listing operation, mentions optional filtering, and indicates that the output provides package names usable by launch_app/stop_app. This is sufficient for an agent to infer safety and return structure, though it could explicitly state it does not modify 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, well-structured sentence that front-loads the primary action and filter option, then immediately gives the use case. Every word earns its place, no redundancy.

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

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

Given the tool's low complexity (2 optional params, no output schema, no annotations), the description is nearly complete: it explains purpose, parameters briefly, and downstream usage. A minor gap is that it doesn't hint at the return format or that serial is for multi-device scenarios, but these are compensated by the schema descriptions.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the filter or serial parameters beyond what the schema already provides; it just names the parameters in context. This is adequate but does not exceed the baseline.

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

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

The description clearly states the tool lists installed package names, optionally filtered by substring, and explicitly communicates the use case: to confirm an app is installed and get its exact package name for launch_app/stop_app. This is a specific verb+resource combination that distinguishes it from siblings like get_app_details or install_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 tells when to use this tool (to confirm an app is installed and get its exact name for launching/stopping), implying the subsequent action. It does not explicitly state when not to use it or mention alternatives among the many sibling tools, but the context is clear enough for an 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?

With no annotations provided, the description fully shoulders the transparency burden. It discloses: the tool dumps and exits (not streaming), strips chatty spam, is case-insensitive, accepts relative time windows via device clock, and the default of 400 lines can span only seconds on a chatty emulator. All behavioral traits are clearly communicated.

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

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

The description is a single dense paragraph that wastes no words. Every clause earns its place: the default behavior, the since parameter explanation, the use-case hook, the filter/tag/priority options, the non-streaming nature, and the spam-stripping note. It is front-loaded with the core action and then layers detail. No fluff.

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

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

Despite having 7 parameters and no annotations or output schema, the description covers all important aspects: what the tool does, how to use each parameter, when to use it, its behavioral limits (dump and exit, spam stripping, device clock for since), and how to interpret results ('Caused by: line is the root cause'). The only minor gap is that no output format is described, but for a text-dumping tool that's acceptable — the user sees raw logcat text.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining that since is 'the right axis when the report is I just hit an error' and that '400 lines can span seconds on a chatty emulator' — adding operational context not present in the parameter descriptions. It also clarifies that tags are OR'd and priority mirrors adb's *:E syntax, which is not in the schema. One small deduction: the description doesn't detail how multiple filters (tag, priority, filter) interact — but the schema already implies AND logic.

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 'Dump recent native log lines' — a strong verb+resource pair. It immediately distinguishes itself from sibling tools like start_logcat_capture (streaming), clear_logcat (clearing), and last_crash (crash-specific) by emphasizing its dump-and-exit, non-streaming behavior and its role for root-cause analysis.

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 tells when to use this tool: 'when the UI only shows a generic X failed alert.' It also indirectly advises against using it for streaming (since it dumps and exits) and positions it as complementary to start_logcat_capture/stop_logcat_capture for continuous monitoring. The since parameter is scoped to 'device clock' and the right axis is explained.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates that the action is a sustained press at a coordinate in true device pixels for a configurable duration. However, it does not mention side effects (e.g., triggering system gestures) or failure modes, leaving a modest gap.

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 packs the verb, resource, key parameters, and use cases. Every phrase earns its lace, and the most critical information is front-loaded. No filler.

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

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

Given the tool's simplicity (4 basic paramers, no output schema, no nested objects), the description covers the essential purpose, input meaning, and typical scenarios. It lacks an explicit return-value statement, but that's acceptable for a void action. The description feels complete enough for an agent to invove this tool correctly.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description adds the meaning of 'true device pixels' and the 'duration' concept, but does not elaborate on serial or duration default beyond what the schema's 'Default 600' already states. Baseline 3 is appropriate.

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

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

The description clearly states 'Press and hold a coordinate' with specific use cases—'context menus, drag handles, and long-press actions.' This verb+resource combination distinguishes it from siblings like 'tap','swipe','drog' by emphasizing sustained contact.

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 lists when to use the tool ('for context menus, drag handles, and long-press actions'), guiding the agent toward appropriate user scenarios. It does not explicitly contrast with alternatives, but the use cases implicitly differentiate it from point-and-click or swipe actions.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly states the tool opens the dev menu via KEYCODE_MENU, implies it's reliable, and hints it may be non-destructive by mentioning follow-up inspection/selection rather than direct result. However, it could be slightly more explicit about whether it waits for the menu to appear or returns immediately.

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

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

Two sentences, zero waste. Every sentence serves a purpose: the first states the action and reliability, the second gives follow-up guidance. No filler, perfectly front-loaded.

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 low complexity (1 optional param, no output schema), the description is complete. It explains what it does, when to use it, and what to do after. The sibling list contains many UI tools, and the description clarifies its unique role among them.

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

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

Schema description coverage is 100%, so the schema already documents the `serial` parameter well. The description doesn't add parameter-specific details but does set broader context (target device from foreground app). Baseline 3, bumped to 4 because the description effectively compensates by contrasting with a sibling tool and explaining the tool's purpose, adding value beyond the schema's dry field description.

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

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

The description uses a specific verb+resource: 'Open the React Native dev menu (KEYCODE_MENU) on the foreground app', clearly differentiating it from sibling tools like `reload_app` or `launch_app`. It directly states what the tool does and unlike the sibling tools, it's tailored for a specific use case.

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

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

The description explicitly tells when to use this tool ('the reliable way to reach a dev build's Reload/Debug JS Remotely/etc. options when reload_app's broadcast doesn't apply') and provides follow-up instructions ('Follow with tap_on_text or describe_ui to pick a menu item'), giving clear context on when it's appropriate vs alternatives.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions launching via 'am start' and optionally targeting a package, which gives some insight into the underlying action. However, it does not disclose safety (e.g., whether this might launch external apps or change device state), nor any side effects like what happens if the URL is invalid or the deep link is not handled. For a tool that can launch arbitrary intents, more behavioral context would be warranted.

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 long, front-loaded with the main action. Every sentence adds value: the first states the core functionality and mechanism, the second clarifies optional targeting. No filler or redundant 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?

Given the tool has 3 parameters (all covered by schema), no output schema, and moderate complexity (launching an intent), the description provides basic completeness. It explains the 'what' and 'how' but omits important context like whether it handles malformed URLs, what the return value indicates (success/failure), or prerequisite conditions (e.g., device must be connected). This is adequate but not thorough.

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

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

Schema description coverage is 100%—each parameter already has a description in the schema: url as 'URL or deep link to open', serial as 'Target device serial', package as 'Optional package to target the intent at.' The tool description adds no new detail beyond what is in the schema, such as syntax or formatting nuances. Since schema coverage is high, a baseline of 3 is appropriate.

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

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

The description uses a specific verb+resource combination, 'Open a URL or deep link via an ACTION_VIEW intent (am start) — the way to jump straight to a deep-linked screen.' It clearly states the tool opens URLs or deep links and mentions the underlying mechanism (ACTION_VIEW intent). While it doesn't explicitly distinguish itself from siblings among many other tools, its purpose is distinct enough given the sibling list includes no other URL-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?

The description implies its usage context: 'the way to jump straight to a deep-linked screen' indicates when to use it (for deep links), and the optional package targeting provides some guidance. However, it lacks explicit exclusions or alternatives—for example, it doesn't say when NOT to use it (e.g., for opening a URL in a browser vs. a deep link). No sibling tool directly overlaps, so the lack of competition reduces the need for heavy guidance.

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

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

No annotations are provided, so the description carries full burden. It explains the actions and the emulator-only restriction, but does not disclose potential side effects, permission requirements, or error states when actions are used out of order. The information is adequate but not rich.

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 three sentences, front-loaded with the main action, and every sentence provides essential information. There is no fluff or redundancy.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description covers the core behavior and the critical emulator-only constraint. It does not explain return values or error handling, but for a simple ADB command tool, this is sufficient. The optional serial parameter is not mentioned, but it is covered by the schema.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining the effects of the action parameter ('rings an incoming call' vs 'transition an in-progress call'), which goes beyond the schema's list of options. This enhances understanding 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 states the tool drives an emulated voice call using adb emu gsm, and lists the specific actions (call, accept, cancel, busy, hold) with their effects. It is a unique verb+resource combination that distinguishes itself from siblings like send_sms or cellular.

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 includes explicit usage context: 'Use to test call-interruption behaviour and CALL_PHONE flows. Emulator-only.' This tells the agent when and where to use it. It does not explicitly state when not to use it or name alternatives, but the context is clear 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?

With no annotations provided, the description carries the full burden. It discloses that the tool 'tries' to move the prompt (implying possible failure), mentions two distinct mechanisms, and warns about app-controlled suppression. It advises a follow-up step. This is good behavioral context, though it could mention prerequisites or failure cases more explicitly.

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 long, each earning its place. The first sentence states the primary action, the second gives crucial post-usage guidance. No filler or repetition. Efficient and front-loaded.

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 lack of output schema and the tool's nature (a UI fallback action), the description is fairly complete. It explains what the tool does, warns about potential limitations, and tells the user the next steps (describe_ui then enter_pin). Could be strengthened by mentioning return behavior or side effects, but overall sufficient.

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

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

Schema description coverage is 100% for the single optional 'serial' parameter, with a clear description in the schema. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Try to move a standard BiometricPrompt to its PIN/password fallback.' It specifies the actions (selecting a system button or sending BACK) and the resource (BiometricPrompt). This distinguishes it from siblings like 'enter_pin' and 'describe_ui'.

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 for when to use the tool and how to proceed after invocation: 'confirm the resulting PIN pad with describe_ui before calling enter_pin.' It warns that app-controlled prompts may suppress or rename the option. However, it does not explicitly state when not to use it or mention alternative tools for different scenarios.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that a key press can be silently consumed with no effect (e.g., back during a biometric prompt), that power toggles rather than simply turning on, and that verify_change adds two extra hierarchy reads. These are non-obvious behaviors an agent needs to know.

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 dense but well-organized: core action first, then examples, then caveats, then batching guidance. Every sentence contributes useful information, and there is no redundant repetition of the schema.

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

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

It covers key names, behavioral caveats, alternative routing, and the verify_change option thoroughly. The only gap is that, with no output schema, the normal return value/immediate result of a press is not described, though verify_change's return is. This is minor relative to the tool's simplicity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by enumerating common key names, explaining wakeup vs power semantics, and clarifying the cost and purpose of verify_change. It does not add much about serial, but the schema already explains that clearly.

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 ('press') with a precise resource ('hardware/navigation key' or 'raw Android keycode number') and gives concrete examples. It also distinguishes itself from related tools by explicitly pointing to run_sequence for batched actions and contrasting wakeup vs power.

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 direct when-to-use guidance: submit a form with enter, dismiss keyboard with escape, go back with back. It explicitly warns that power toggles and may sleep an awake screen, recommending wakeup instead, and says time-sensitive or batched presses belong in run_sequence, not separate calls.

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

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

No annotations are provided, so the description must carry the full burden. It states the basic operation (copy from device by adb pull) but does not disclose important behavioral traits: whether the local path is overwritten without warning, what happens if the device is disconnected or the file does not exist, or any required permissions. The description is too minimal to ensure safe agent behavior.

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

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

The description is a single sentence plus an example, perfectly front-loaded with the key action. Every word earns its place; there is no fluff. It efficiently conveys the core functionality.

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 file copy tool with no output schema, the description covers the essential purpose and use cases. It could mention return values or error behavior, but the examples help ground the agent. It is not missing critical information, though a bit more detail on behavior 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?

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds only brief examples (e.g., 'retrieve a generated file, database, or screenshot') which provide some context but do not add significant new meaning beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Copy a file off the device to a local path' and identifies the underlying adb command 'adb pull'. The examples (generated file, database, screenshot) further clarify the type of resources. This distinguishes it well from sibling tools like push_file (opposite direction) and screenshot (captures a screen image but not arbitrary files).

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 through examples but does not explicitly state when to use this tool versus alternatives like push_file. It lacks guidance on prerequisites (e.g., device must be connected) or when not to use it. The context is clear enough for a simple tool but 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?

No annotations are provided, so the description carries the full burden. It only states the basic operation without revealing behavioral traits such as overwrite behavior, error handling, permissions, or side effects. This is insufficient for a write 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, efficient sentence that front-loads the purpose. Every word adds value, and there is no redundancy or 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?

For a simple file copy tool, the description is adequate but incomplete. It lacks details on overwrite behavior, error conditions, and output. With no annotations or output schema, more context about the tool's behavior would be beneficial.

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 covers all 3 parameters with descriptions, achieving 100% coverage. The description adds minimal parameter-level context (e.g., use case example) but does not enhance understanding beyond what the schema 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 ('Copy a local file onto the device (adb push)') and provides a concrete example ('seed test data or a file to import'). It distinguishes from the sibling tool 'pull_file' which does the opposite.

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 pushing files to a device, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'pull_file' is not mentioned as the counterpart). No conditions or exclusions are stated.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It honestly states 'best-effort', 'may silently no-op with no error', and details the exact conditions under which the tool works (debug builds, classic non-bridgeless architectures). This provides excellent transparency about limitations and failure modes.

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 front-loaded with the core purpose ('Best-effort: trigger a Metro/JS reload...') and then efficiently covers prerequisites, limitations, and alternatives. Every sentence adds value, though the prerequisites section is slightly lengthy. Still, it remains focused and avoids redundancy, earning a high score for conciseness.

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

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

Given the complexity of the tool (best-effort, silent failures, strict environment requirements) and the absence of an output schema, the description is remarkably complete. It covers prerequisites, failure modes, conditions for effectiveness, and fallback alternatives. No additional information is needed for an agent to use this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add new semantic information about the parameters beyond what the schema provides (e.g., serial optional when one device, package format). Baseline score of 3 is appropriate as the description adds no extra value for parameter understanding.

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 triggers a Metro/JS reload on React Native dev-client builds. It specifies the verb 'trigger', the resource 'Metro/JS reload', and the context 'RN dev-client build'. It also distinguishes from sibling tools like open_dev_menu and tap_on_text by providing alternative steps, making the purpose unambiguous.

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

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

The description explicitly states when to use this tool ('debug builds of classic RN architectures') and when not to ('newer RN/Expo dev clients may silently no-op'). It provides a direct alternative ('use open_dev_menu then tap_on_text("Reload")') and a prerequisite ('run adb_reverse {device_port: 8081} first'), offering complete guidance on 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?

With no annotations, the description carries the transparency burden and meets it: it explains that the tool reads the real view tree, enumerates the exact metrics, and warns that reset=true zeros frame counters as a side effect. The behavioral contrast with describe_ui's viewport scoping is genuinely informative.

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 compact sentences, each with a distinct job: enumerate outputs, differentiate from sibling, explain reset. No filler, and the most decision-relevant guidance is front-loaded.

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?

Since there is no output schema, the description must state what the tool returns — it does, with a concrete metric list and an interpretive hint about what the three numbers together argue. It also covers the reset behavior, so an agent can invoke it correctly.

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

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

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds value by restating reset=true's purpose ('so the next call measures one specific interaction') and tying it to jank attribution, which helps an agent decide when to set it. It doesn't add much for package/serial, but none 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 names a specific measurement operation with the metrics it returns (total views, render-node kB, jank percentage, frame-time percentiles, skipped frames), so an agent knows exactly what the tool provides. It also explicitly distinguishes itself from describe_ui, preventing sibling confusion.

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 states directly 'Use this — not describe_ui — to MEASURE a screen' and explains why describe_ui undercounts lists, giving a concrete decision rule. It also instructs when to pass reset=true, covering the main usage branch.

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

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

No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: revoking some permissions kills the app process. It also explains the effect on the permission dialog. It does not mention prerequisites like ADB connection or root permissions, but the given info is valuable and actionable.

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 plus a note, front-loaded with the core action. Every sentence adds value: action+technical details, use case+pairing, and a behavioral caveat. 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?

Given 3 fully described parameters, no output schema, and no annotations, the description covers purpose, usage context, and a key side effect. It lacks information about prerequisites (e.g., device must be debuggable, ADB authorization) and does not specify Android version compatibility. However, for a focused permission tool, it is largely 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 coverage is 100% for all three parameters, so baseline 3 applies. The description does not add parameter-specific details beyond the schema; it references 'runtime permission' but does not elaborate on parameter constraints or examples. No improvement over 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 clearly states the tool revokes a runtime permission using 'pm revoke' and specifies the exact use case: testing the denied path or re-triggering the permission dialog. It explicitly pairs with the sibling 'grant_permission', distinguishing 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?

Provides clear context: use when you need to test denied paths or re-trigger permission requests. Mentions pairing with grant_permission, implying sequential usage. Warns about process kills. Does not explicitly say when NOT to use or list alternatives, but the context is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It discloses the underlying command ('adb emu rotate') and the behavioral effect of rotation-driven state loss. However, it does not explain the exact rotation order (e.g., cycles through orientations) or whether it is a toggle, nor does it state if it is destructive or read-only. The description is adequate but lacks deeper 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 extremely concise: two sentences that front-load the primary action and immediately provide context. Every sentence adds value, and there is no redundant or unnecessary text.

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 simple tool (one optional parameter, no output schema, no annotations), the description covers the essential aspects: purpose, underlying command, use case, and constraint. It does not specify return values (likely none) or timing, but these are not critical for such a straightforward action. The description is sufficiently complete for an agent to use the tool correctly.

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

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

Schema description coverage is 100% for the single parameter 'serial', which already has a clear description. The tool description adds no additional information about the parameter. With high coverage, the baseline is 3, and the description does not exceed it.

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 'rotate' and the resource 'emulator orientation', and it specifies the action as rotating to the next orientation. It also distinguishes the tool's purpose by mentioning it's 'the quick way to exercise landscape/portrait layout and rotation-driven state loss', which uniquely identifies it among the 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 provides context for when to use this tool: to exercise layout and state loss due to rotation. It explicitly states 'Emulator-only', which is a clear constraint. However, it does not mention alternatives or when not to use it, though no direct sibling tool exists for rotation, so the guidance is sufficient.

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

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

With no annotations provided, the description carries full burden. It discloses that a booted device/emulator is required, that it returns per-suite timing and failing-test stack traces, and that json=true changes output format. It does not mention whether the device must be an emulator or physical, or if there are side effects like app installation. Still, it is fairly transparent for a test runner.

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 a clarifying second sentence about json output. It is front-loaded and efficient, but the note about default task could be more explicit as 'default task connectedAndroidTest' is already in parentheses.

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 4 parameters, no output schema, and no annotations, the description is adequate but not fully complete. It omits details like what happens if no device is available (error message?), whether it installs the app first, or the format of the text summary. For a complex test tool, more behavioral details 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?

Schema description coverage is 100%, so the schema already documents all 4 parameters. The description adds no new meaning beyond the schema for parameters like args, project_dir, or task. For json, the description clarifies it is shared with run_unit_tests and ignored by gradle_build/list_gradle_tasks, adding value only for this one parameter. Baseline 3 is appropriate.

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

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

The description clearly states it runs Gradle instrumented (on-device) tests in a project_dir, specifies the default task 'connectedAndroidTest', and distinguishes from other test-running siblings like run_unit_tests by noting the need for a booted device/emulator.

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 says it requires a booted device/emulator, which is critical context not obvious from the schema. It also hints at an alternative (json=true for structured output) and implicitly distinguishes from run_unit_tests via the device requirement. However, it does not explicitly state when not to use this tool versus build_and_run or gradle_build.

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

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

With no annotations provided, the description carries the full burden. It discloses sequential execution, stop-on-error behavior for non-optional steps, per-step results (ok/skipped/error) with elapsed_ms, final hierarchy capture, and the default for capture_final. It does not mention concurrency or limitations, but for a sequence runner this is adequate.

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 paragraph but is front-loaded with the key purpose. It covers the core functionality, guards, optionality, and return format without redundancy. It could be slightly better structured (e.g., bulleted action list), but every sentence earns its place and there is no fluff.

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 no output schema, the description fills the gap by detailing return structure (per-step result, final hierarchy). All 3 parameters are explained adequately beyond the schema. Error behavior, guard semantics, and the default for capture_final are covered. The description is complete for an agent to use the tool effectively without additional 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?

All three parameters are already documented in the schema (100% coverage), so baseline is 3. The description adds significant value by explaining guards (if_present/if_absent), the optional flag, how results are structured, and the action type list with context. This additional guidance raises the score above baseline.

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

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

The description opens with 'Run several interaction steps in ONE call — no agent round-trip between them,' making the core purpose immediately clear. It then distinguishes itself from sibling tools (single-step actions like tap, wait) by emphasizing the batch execution and timing-critical use cases, with a concrete example.

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 when to use: 'for scripted flows and, crucially, flows driven by NATIVE TIMERS... where a round-trip per step would perturb the timing.' It also explains how conditional guards (if_present/if_absent) and optional flags work, providing clear guidance on handling conditional branches and step failures. The implication that for non-timing-critical single steps one would use sibling tools is clear.

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

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

With no annotations, the description carries the full burden. It discloses the default task behavior, the fact that on Android it runs all variants, and the return format. However, it does not mention side effects (e.g., whether it modifies files), required permissions, or error behaviors, leaving some gaps.

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

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

Two sentences: first defines the core purpose and output, second delivers key usage guidance and optional feature. Every word adds utility, no redundancy. Extremely efficient and front-loaded.

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 no output schema, the description adequately describes return values (timing and stack traces, optional JSON). It covers all parameters with extra guidance and addresses the common Android variant scenario. Lacks mention of edge cases like missing gradle wrapper or no tests, but these are minor.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds significant value by explaining the json parameter effect (structured JSON), providing Android-specific advice for the task parameter, and clarifying the args parameter as extra Gradle arguments. This goes well beyond the schema descriptions.

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

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

The description clearly states the action ('Run Gradle JVM unit tests'), the resource (default task 'test'), location (project_dir), and what is returned (summary with per-suite timing and failing-test stack traces). It distinguishes from siblings like run_instrumented_tests and gradle_build by specifying JVM unit tests.

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 explicit guidance on when to override the default task on Android projects for efficiency (e.g., task='testDebugUnitTest'), giving concrete examples. It implies appropriate contexts for use but does not explicitly contrast with siblings like gradle_build or run_instrumented_tests, leaving slight ambiguity.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It clearly conveys that the tool writes a project structure (including wrapper generation, conditional on PATH), never overwrites non-empty dirs, and explains the dependency on `gradle_build`. Although it doesn't explicitly state that it's a write operation (non-read, potentially destructive), the 'never overwrites' phrasing implies safety for existing directories. A small gap is the lack of mention of cleanup or rollback if something fails, but overall it is thorough.

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 dense, front-loaded sentences with zero wasted words. Every clause earns its place: the first lists deliverables, the second addresses overwrite behavior and Gradle wrapper conditions. It is efficiently 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?

Given the tool's moderate complexity (3 params, no nested objects, no output schema), the description fully covers what the tool does, its side effects, prerequisites (empty directory, optional gradle on PATH), and how it relates to sibling tools like `gradle_build`. There is no missing guidance for an agent to invoke it correctly.

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

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

The input schema already covers all three parameters with complete descriptions (100% coverage), so the description does not need to repeat them. The description adds context beyond the schema: it explains that `destination` must be empty/new, and implies `name` and `package` affect the generated content. This adds meaningful usage nuance.

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 it creates a minimal Kotlin Android app in a new empty directory, listing specific outputs like Gradle Kotlin DSL, AndroidManifest, launcher Activity, resources, README, and gitignore. This is a specific verb+resource that clearly distinguishes it from siblings like `build_and_run` or `gradle_build`.

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 says the tool never overwrites a non-empty directory, and provides clear context about when to use it vs alternatives: it generates the Gradle wrapper when `gradle` is on PATH for immediate buildability with `gradle_build`, and explains what happens if no gradle is installed. This gives the agent solid when/when-not guidance.

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

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

With no annotations, description discloses auto-downscaling, retry logic for black frames, handling of FLAG_SECURE and sleeping displays, and multi-display foldable support. No contradictions—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?

Dense but efficient; each sentence adds value. Could be slightly more concise by merging some details, but front-loaded with core purpose and well-organized for a complex 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?

Covers edge cases (black frames, multi-display), retries, and limitations (no coordinate derivation). Missing explicit output format (e.g., base64), but otherwise complete for a screenshot tool with optional parameters and no output schema.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds context like default values for max_dim, alias usage for display, and when to omit serial, enriching the schema with practical usage hints.

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 captures a PNG of the current screen to see UI state, using specific verbs and resource. It distinguishes from siblings like describe_ui by emphasizing it's for visual confirmation, not coordinate derivation.

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

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

Explicitly tells when to use (after every action to confirm screen change) and when not to (when frame is black, use describe_ui instead). Provides alternative tool and explains consequence of driving blind.

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

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

With no annotations provided, the description carries full burden to disclose behavior. It reveals the low-level implementation ('adb emu sms send') and the emulator-only constraint, but does not clarify whether this is a destructive action (overwrites the last received SMS?), whether it requires any preconditions, or what happens if the emulator is not available. The description does not contradict any annotations because there are none.

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

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

Two sentences, zero wasted tokens. Every sentence serves a purpose: first sentence states the operation and use-case, second sentence clarifies required parameters with an example. Ideal length 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 simple 2-required-param tool with no output schema, the description is mostly complete: it covers purpose, use-case, constraints (emulator-only), and required inputs. However, completeness is slightly limited by the lack of behavioral transparency around error cases or side-effects (e.g., what happens if the emulator is offline).

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 description coverage is 100%, so the schema already documents all 3 parameters. The description mentions 'Pass a sender number (from) and the message text (e.g. the code)', which adds a typical usage example but does not add new constraints or semantics beyond what the schema provides. Baseline 3 is correct.

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

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

The description uses a specific verb ('Deliver an incoming SMS to the emulator (adb emu sms send)') and clearly identifies the resource and use-case (OTP/2FA flows). It distinguishes this from any sibling tool by calling out the emulator-only constraint.

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 identifies the primary use-case ('drive OTP / 2FA flows without a second phone') and notes the emulator-only limitation, which helps the agent decide when to use it. However, it does not describe when NOT to use it (e.g., physical devices) or suggest alternatives among 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?

With no annotations provided, the description carries the full burden. It clearly explains the effect: clearing pinned defaults and reverting to requiring them on every call, with a fallback note for serial. This is transparent about the behavioral change and the specific fallback behavior, which is valuable beyond what a schema could convey.

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, front-loaded with the action and resource, and includes a clarifying parenthetical about serial fallback. Every part is essential and there is no wasted text. It is perfectly sized for the tool's simplicity.

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, no output schema, and no annotations, the description fully explains what the tool does and its effect on session behavior. It is complete for this simple tool, though one could argue it could mention that it only affects the current session scope, but that is already implied.

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

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

The input schema has zero parameters, and schema description coverage is 100% (no params to describe). The description explains what the tool does without needing parameter details, which is appropriate. Since there are no parameters, the description adds value by clarifying the tool's effect, earning a higher score.

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 reverts session-pinned defaults for project_dir and serial, causing them to be required on every call again. The verb 'clear' and the specific resources ('project_dir/serial defaults') give a precise purpose. It distinguishes itself from session_set_defaults and session_show_defaults among 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 this tool is used when you no longer want pinned defaults and want to require explicit parameters each time. However, it does not explicitly state when to use it versus when not to, nor does it name session_set_defaults or session_show_defaults as alternatives. The guidance is clear enough but lacks explicit context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: only passed fields are changed, omitted fields retain their current default, and explicit parameters override session defaults. It does not mention reversibility (can be undone via session_clear_defaults), potential side effects, or whether defaults persist across session resets. This leaves some behavioral uncertainty.

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 three sentences: purpose, use case, and override behavior. It is front-loaded and well-structured. Each sentence adds value without redundancy. Minor opportunity to tighten, but overall efficient.

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

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

Given the tool's simplicity (2 optional params, no output schema), the description covers purpose, usage context, partial update behavior, and interaction with explicit parameters. It does not explain return values, but that is acceptable. A mention of session_clear_defaults for reversing would improve completeness, but the current text is largely sufficient.

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

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

Schema coverage is 100%, with both parameters described. The description adds context ('Only the fields you pass are changed; omit a field to leave its current default alone') but largely echoes the schema description ('Leave empty to leave the current default unchanged'). It adds marginal value beyond the schema, warranting a baseline 3.

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: pinning default values for project_dir and/or serial for the session. It uses specific verbs ('Pin', 'set defaults') and identifies the resource (session defaults). However, it does not explicitly differentiate from sibling tools like session_clear_defaults or session_show_defaults, which would strengthen clarity.

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 on when to use the tool: 'the fix for a multi-module or multi-flavor project (or multiple attached devices) forcing you to repeat the same project_dir/serial on every Gradle or device call.' It also explains how explicit parameters override session defaults. However, it lacks explicit 'when not to use' guidance or mentions of alternative tools (e.g., prefer_pin might relate but isn't addressed).

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

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

With no annotations provided, the description carries the full burden. It discloses the tool is a read operation (no side effects), but doesn't mention whether defaults are session-scoped or what happens if no defaults are set. The description is adequate for a straightforward query tool.

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

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

The description is a single sentence, perfectly focused, and front-loads the purpose. Every word adds value, with no redundancy or 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?

Given 0 parameters, no output schema, and no annotations, the tool is simple. The description clarifies the source of defaults (session_set_defaults), which is complete enough for selecting this tool among 77 siblings.

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

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

Schema description coverage is 100%, but with 0 parameters, the schema is inherently complete. The description doesn't list parameters (none needed), so it adds no parameter info, but the baseline for 0-param tools is 4 as no compensation is 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 'show' paired with the resource 'project_dir/serial defaults pinned for this session', clearly distinguishing it from sibling tools like session_set_defaults and session_clear_defaults. It precisely identifies what the tool returns (pinned defaults).

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 clarifies that defaults are those set via session_set_defaults, which implies a complementary relationship to that sibling. It doesn't state when not to use it or provide explicit exclusions, but the context makes usage 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?

No annotations provided, so description carries full burden. It discloses implementation differences (emulator vs physical device), that values persist until reset or reboot, and behavior of reset=true. No contradictions.

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 well-structured sentences, front-loaded with the primary purpose. Every sentence adds necessary information without redundancy. 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?

Given the lack of annotations and output schema, the description is complete: covers use cases, device behavior differences, persistence, reset usage, and explicitly mentions an alternative tool. Leaves no critical gaps.

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

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

Schema description coverage is 100%. Description adds context by summarizing parameter roles (level, charging, reset, serial) but does not provide additional meaning beyond the schema descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool sets battery level and charging state for testing low-battery UI and charging logic, distinguishing itself from set_status_bar (which only fakes battery in status bar). It specifies exact verb and resource.

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

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

Explicitly tells when to use (testing low-battery and charging behavior) and when not (for fake battery in clean status bar, prefer set_status_bar). Also explains persistence on physical devices and use of reset=true.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states the tool turns dark theme on/off ('true = dark theme on, false = off'), which implies a low-risk UI toggle. However, it does not mention whether a device reset or app restart is needed for the change to take effect, or if there are side effects. With no annotations, a 3 is appropriate as the basic behavior is clear but lacks depth.

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?

Single, front-loaded sentence that immediately states the action and purpose. The parenthetical includes a helpful internal command reference without bloating. Every word serves a purpose; no redundancy given the 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 a simple toggle with 2 params and no output schema or nested objects. The description fully covers the action and context (testing appearances). Minor gap: absent mention of return value or confirmation, but for a boolean toggle tool, this is acceptable. Sibling tools like set_battery have similar simplicity and would benefit from a similar level of detail.

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

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

Schema description coverage is 100%, meaning both parameters (serial, enabled) are already documented in the schema. The description adds value by clarifying the overarching purpose (testing appearances) and referencing the underlying command, but does not add new meaning for individual parameters beyond the schema. Baseline 3 is appropriate; plus 1 for the useful context (cmd uimode night) that aids parameter understanding.

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?

Description uses specific verb 'Turn' and resource 'system dark theme', immediately clarifying the on/off function. It distinguishes from sibling tools like set_battery, set_sensor, set_status_bar which set other system properties, and references the internal command 'cmd uimode night' for full precision.

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?

Description states the tool is for toggling dark theme on/off and mentions testing light/dark appearances, which implies a development/testing use case. However, it provides no explicit guidance on when not to use it, no alternatives, and no prerequisites (e.g., device must support dark theme).

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