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

With no annotations, the description fully carries behavioral disclosure. It details verification process, output structure, lifecycle states, and failure handling with specific error codes, leaving little ambiguity about tool 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?

Well-organized into sections (Purpose, Inputs, Output, Verification, Failure), but somewhat verbose. Every sentence is informative, though some redundancy exists (e.g., repeated default values).

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 inputs, outputs, verification guidance, failure handling, and edge cases (tolerance defaults for discrete/continuous). Without an output schema, the description provides sufficient structure for understanding return values. Complete for the 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?

Schema coverage is 88%, so baseline is 3. The description adds value by explaining default tolerance for discrete vs continuous controls, default maxAttempts, and the requirement of exactly one of selector or element_id, which aids correct 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 it adjusts a numeric control value with verification, specifying it's for slider-like controls with numeric values or value ranges. This distinguishes it from sibling tools like tap, swipe, or type_text.

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 verification guidance on preferred adjustment methods (direct platform, then increment/decrement, coordinate fallback as degraded) and advises using expect_state for readback. Does not explicitly list when not to use, but context implies it's for numeric controls.

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 mentions core behavior but omits details like side effects, failure handling, or whether it modifies project files. 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 sentences, front-loaded with purpose. Every sentence earns its place. No unnecessary words.

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

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

With no output schema, the description explains the return value (artifact path) but lacks format details. It covers the required inputs but could mention prerequisites like project structure. Generally adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description merely repeats that platform and projectType are required, adding no extra meaning beyond the schema's existing 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 a project for Android or iOS and returns the artifact path. It distinguishes from siblings like install_app by explicitly noting 'Does not install.'

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 indicates when not to use (if installation needed) and specifies required parameters. It does not explicitly name alternative tools but context from siblings makes it 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 exist, so description must carry the burden. It mentions output fields but does not disclose side effects, auth needs, or whether it is read-only. Some behavior is implied but insufficient.

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 efficient sentences, front-loaded with action and output format. 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?

Adequate for an all-optional parameter tool with no required inputs, but lacks usage guidelines and detailed behavioral context. Could be improved with when-to-use advice or clarification of 'derived semantic layer'.

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 for all 7 parameters. The tool description adds no additional parameter meaning, so 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 captures a complete debug snapshot with raw and optional derived layers, and lists specific return fields. This distinguishes it from siblings like get_logs or capture_screenshot.

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

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

No guidance on when to use this tool versus alternatives like start_log_stream or get_ui_tree. The description lacks context for decision-making.

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. Only mentions return value, not behavioral traits like side effects, permissions, or whether it affects device state. Missing critical disclosure for a mutation tool.

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

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

Single sentence, front-loaded with purpose, no fluff. Efficiently communicates main goal and return 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?

For a simple screen capture with 2 params and no output schema, description adequately states purpose and output. Minor gap: no mention of image format or metadata structure, but not critical given tool 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 covers both parameters with descriptions for deviceId and enum for platform. Description adds minimal value beyond schema; platform lacks explicit description but enum clarifies. Schema coverage 50% is compensated by schema itself.

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

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

Clear verb ('Capture') and resource ('screenshot') with platform specification ('Android device or iOS simulator'). Returns device metadata and image, distinguishing from siblings like capture_debug_snapshot. Fully describes 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?

Implied usage for capturing screenshots, but no explicit guidance on when to use this tool vs alternatives like get_current_screen or capture_debug_snapshot. Lacks exclusions or context.

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

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

With no annotations, the description fully carries the burden of behavioral disclosure. It details the classification rules (applied in order), post-outcome actions, and pre-call steps. This provides complete transparency into the tool's behavior without contradiction.

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

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

The description is well-organized with clear sections (HOW TO GATHER INPUTS, RULES, BEHAVIOUR) and each sentence serves a purpose. It is detailed but not excessively verbose for the complexity of the tool; a minor reduction could improve 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 tool's complexity and absence of an output schema, the description thoroughly covers all necessary aspects: input gathering, rule application order, output categories, and post-classification behavior. No gaps remain.

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%, but the description adds significant meaning by explaining each parameter's role in the classification logic (e.g., uiChanged triggers rule 1, actionType maps to action type categories). This goes beyond the schema definitions.

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 classifies the outcome of the most recent action into one of five distinct categories. The verb 'classify' combined with the resource 'action outcome' is specific and unambiguous. No sibling tool performs classification, so it distinguishes well.

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: 'when the intended outcome is not already fully verified by the UI signal alone.' Also details how to gather inputs and includes a rule set. While alternatives are not explicitly excluded, the instruction is clear and context-rich.

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 internal resolution, deterministic binary output, failure codes (TIMEOUT, UNKNOWN), and constraints (no natural-language interpretation). It could mention that the tool is read-only.

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 structured with clear headers (Purpose, Inputs, Output Structure, etc.) and is front-loaded. However, it is somewhat verbose and could be more concise without losing clarity.

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

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

Given the lack of output schema, the description covers purpose, usage, behavior, output structure, and failure handling. It does not detail the nested selector properties (text, contains, etc.) but provides sufficient context for an agent to understand the tool's role.

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 50%. The description adds meaning for selector and element_id (e.g., 'required selector used to resolve the target element') but does not explain deviceId, platform, timeout_ms, or poll_interval_ms. Parameters with defaults are not described, leaving gaps.

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: 'deterministically verify that the intended UI outcome of an action has occurred by confirming a target element is visible.' It uses specific verb-resource combination and distinguishes from sibling tools like expect_screen and expect_state.

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 recommended usage workflow (steps 1-6), verification guidance, and failure handling. It tells when to use ('primary and authoritative verification tool') but does not explicitly state when not to use. The sibling list provides context.

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

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

With no annotations, the description fully discloses output structure, confidence meaning, constraints (no NLP), and failure handling. Behavior is completely 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?

Well-structured with clear sections, front-loaded purpose, and every sentence adds value. 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?

Covers inputs, outputs, usage, failure handling, and constraints comprehensively. No output schema exists, but description compensates fully.

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, and the description adds meaningful context (preference for fingerprint, fallback to screen) 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 verb 'verify' and the resource 'navigation outcome' with deterministic exact matching. It distinguishes from siblings like get_current_screen and wait_for_screen_change.

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 step-by-step recommended usage and guidance on fallback from fingerprint to screen. However, it does not explicitly contrast with alternatives like expect_element_visible or discuss when not to use.

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?

Without annotations, the description fully discloses behavior: it returns structured success/failure only, does not infer state when property is unavailable, and lists failure handling for ELEMENT_NOT_FOUND and UNKNOWN. It does not explicitly state it is non-destructive or require permissions, but verification nature implies read-only. Adds important details beyond typical.

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 well-structured with clear sections (Purpose, Inputs, Supported Properties, Verification Guidance, Constraints, Failure Handling). It is front-loaded with the purpose and every sentence contributes value. No unnecessary words or repetitions.

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 explains that the tool returns 'structured success/failure only' and 'observed value when available'. It covers common failure cases with advice. However, it does not detail the exact structure of the response, which might be needed for parsing. Still, for a verification tool, this is adequate.

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

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

Schema coverage is high (83%), so baseline is 3. The description lists input parameters (selector/element_id, property, expected, deviceId/platform) and provides a list of supported property values (e.g., checked, selected, focused), which is not in the schema. This adds meaningful guidance for 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 verifies a readable UI state property on the currently visible element, with a specific verb ('verify') and resource ('UI state property'). This distinguishes it from siblings like expect_element_visible (checks visibility) or expect_screen (checks screen).

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

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

The description provides a 'Verification Guidance' section explaining when to use this tool ('when the UI element is visible but its state must also be confirmed'). It also advises to prefer canonical property names. However, it does not explicitly state when not to use or list alternatives, though 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?

The description discloses return metadata (confidence, selection reason, fallback alternates) and implies a search with timeout. However, it does not mention side effects, permissions needed, or whether it modifies state. Since no annotations exist, this is partial 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?

Two well-structured sentences, front-loaded with action and resource. No fluff; 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?

Despite no output schema or annotations, the description covers input purpose and output structure. Could mention that it requires a device/app context, but given sibling tools, the domain is clear. Reasonably complete for a find operation.

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

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

The schema has 100% coverage, but the description adds semantic context like 'by semantic query' and lists specific attribute types (text, content-desc, etc.) not in the schema. It also clarifies return type, enhancing 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 finds a UI element by semantic query using attributes like text, content-desc, resource-id, class, and specifies that it returns best match with metadata. This distinguishes it from siblings like tap_element (tap) or get_ui_tree (tree dump).

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

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

No guidance on when to use this tool versus alternatives such as wait_for_ui or expect_element_visible. Does not specify preconditions (e.g., screen loaded) or scenarios where it should be avoided.

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, and the description does not disclose behavioral traits such as side effects, prerequisites (e.g., requires a running app), or error conditions. The description only states what it returns, leaving the agent uninformed about important behavioral aspects.

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 with two sentences, front-loaded with the primary action and return value. Every sentence is informative 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?

For a simple query tool with no required parameters and a clear return value, the description is largely complete. However, given the absence of an output schema, a brief note on the structure of the returned package and activity name could enhance 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% for the single parameter. The description adds 'Defaults to connected/booted device' which is already implied in the schema. No additional semantic value is provided beyond what the schema already conveys.

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 gets the currently visible activity on an Android device and returns package and activity name. It uses a specific verb and resource, distinguishing it from sibling tools like get_screen_fingerprint or get_ui_tree.

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

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

No guidelines are provided on when to use this tool versus alternatives such as get_screen_fingerprint or get_ui_tree. The description lacks context on appropriate usage 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'recent logs' but does not state whether the tool is read-only, whether logs are cleared, or any side effects. Lacks details on authentication needs, rate limits, or default behavior for deviceId.

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

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

Two sentences, front-loaded with the core purpose. No extraneous words. Both sentences add distinct value: what the tool does and what it returns.

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 high parameter coverage, the description lacks explanation of the return format ('structured logs suitable for AI consumption' is vague) and does not clarify the 'device metadata'. More context on output would improve completeness for a tool with 10 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 description coverage is high (90%), so baseline is 3. The description does not add meaningful nuance beyond what the schema already provides; it only summarizes the tool's purpose.

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

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

The description clearly states the action (Get), the resource (recent logs), and the target platforms (Android or iOS simulator). It distinguishes from siblings like read_log_stream by emphasizing one-time retrieval and returning device metadata and structured logs.

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

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

No explicit guidance on when to use this tool versus alternatives like start_log_stream or read_log_stream. Missing prerequisites, context for one-time vs streaming, and when not to use.

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 fully discloses behavior: events are filtered to significant requests, explains status values with HTTP code ranges, and describes the return shape including empty response. 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?

Description is concise with no wasted words. It uses bullet points for status values, front-loads the main purpose, and each sentence adds necessary 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?

Given 2 parameters with good schema coverage and no output schema, the description sufficiently explains the return format (requests array, count, empty case) and the filtering behavior. Complete for a read-only network log tool.

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

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

Schema coverage is 100%, but description adds value by explaining defaulting behavior for deviceId and the purpose of platform. The additional context on defaults improves usability 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?

The description clearly states it returns structured network events from platform logs since the last action. The verb 'returns' and resource 'network events' are specific, and it distinguishes from siblings like get_logs by focusing on network activity.

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

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

Explicitly states when to call: immediately after an action when backend evidence is needed and result is ambiguous. Also instructs not to call more than once per action, providing clear usage boundaries.

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 but only states it generates a fingerprint. It does not disclose whether the tool is read-only, if it has side effects, or what behavior to expect beyond the surface description.

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 sentence, 14 words, front-loaded with the key action and output. No wasted words; every part is essential.

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

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

While the tool is simple with two optional parameters and no output schema, the description fails to explain the return value format or provide context on when to use it among many sibling UI tools. An AI agent would benefit from more behavioral and usage details.

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

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

Schema description coverage is 100%, so the schema documents both parameters adequately. The description adds no additional parameter information beyond what is already in the schema, meriting a baseline score of 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?

Description uses specific verb 'generate' and resource 'stable fingerprint', and clarifies it represents the current visible screen including activity and UI elements. This clearly distinguishes it from sibling tools like get_ui_tree or get_current_screen.

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

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

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when not to use it or what distinguishes it from similar tools like get_current_screen or wait_for_screen_change.

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 burden of behavioral disclosure. It indicates a non-destructive read operation via 'healthcheck', but lacks details on permissions, failure modes, or what exactly is checked in each listed area.

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

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

The description is a single concise sentence that front-loads the key purpose and includes specific details. Every word adds value, with 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 no output schema and many siblings, the description adequately explains the tool's purpose and scope. However, it does not describe the output format or confirm that the healthcheck returns actionable status information, leaving some ambiguity.

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

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

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter information. A baseline of 4 is appropriate for a parameterless tool.

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

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

The description clearly states the tool performs a 'quick healthcheck' of the 'local mobile debugging environment', listing specific aspects (adb, devices, logs, env, iOS). This verb+resource combination is distinct from sibling tools like list_devices or get_logs, which cover individual components.

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

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

The description does not explicitly state when to use this tool versus alternatives. The phrase 'quick healthcheck' implies it should be used for an overview before more detailed checks, but no exclusions or guidance are provided.

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

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

With no annotations, the description bears full transparency burden. It mentions incremental delta signals (hinting at optimization) but fails to disclose whether the operation is read-only, requires a running app, or has performance implications. The term 'Get' implies a read, but specifics are lacking.

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

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

Two sentences, front-loaded with purpose. No wasted words. Every word serves a purpose, and the structure supports quick comprehension.

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 is moderately complete. It specifies the return format (structured JSON with snapshot metadata and delta signals) but lacks depth on the tree's composition or performance expectations. For a complex tool, more context (e.g., size, filtering) would help.

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 no extra meaning beyond the schema's parameter descriptions (e.g., deviceId defaults, platform enum). No elaboration on parameter usage or constraints.

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 retrieves the current UI hierarchy from Android/iOS, returning a structured JSON. It distinguishes itself from siblings like 'get_current_screen' (which likely returns a simpler identifier) and 'get_screen_fingerprint' (a hash), but does not explicitly differentiate.

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

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

No explicit when-to-use or when-not is provided. It implies usage for obtaining the full UI tree but does not mention prerequisites, alternatives, or contraindications. Among siblings, clearer guidance would help, e.g., when to use this vs the more granular finding elements 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 full burden. It mentions accepting binary or project directory and building then installing, but does not disclose failure modes, prerequisites (e.g., device connection), permissions, or whether previous app versions are replaced.

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

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

Two sentences, no redundancy. Efficiently conveys core functionality and requirements.

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?

Lacks information about return values, success indicators, or error handling. No mention of output or follow-up actions, which is notable given no output schema is provided.

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 parameters. The description adds minimal extra meaning beyond clarifying that appPath can be a binary or project directory, which the schema already implies.

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 installs an app on Android or iOS, specifies it accepts both built binaries and project directories, and requires platform and projectType. This distinguishes it from sibling tools like build_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?

No explicit guidance on when to use this tool versus alternatives like build_app. The description only states required parameters but does not provide context for when to use this among 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?

No annotations exist, so the description bears full burden. It only states it 'List connected devices and their metadata' without disclosing whether authentication is needed, if data is cached, or performance implications. Minimal behavioral insight.

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

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

The description is a single, front-loaded sentence with no wasted words. It is highly concise and 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 no output schema and no annotations, the description is adequate but incomplete. It lacks details on return format, scope of metadata, and behavior when platform is omitted.

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

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

Schema coverage is 0% (no parameter description), so description must compensate. It adds context by mentioning platforms (android + ios) which relates to the 'platform' parameter, but does not explain the parameter fully or describe metadata contents.

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

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

The description clearly states the action 'List' and the resource 'connected devices' with metadata, and specifies scope (android + ios). It distinguishes from sibling tools which are action-oriented (e.g., start_app, tap).

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 listing devices, but does not explicitly state when to use this tool versus alternatives or when to filter by platform. No exclusions or context provided.

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

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

No annotations provided, so description carries full burden. It thoroughly explains output structure, success/failure behavior, failure codes, retryability, and UI fingerprints.

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?

Well-structured with sections and front-loaded purpose, but somewhat verbose (e.g., detailed output structure). Minor 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?

No output schema, but description covers inputs, outputs, usage steps, failure handling, and verification guidance. Complete for a simple action tool.

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

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

Schema coverage is 100% with detailed descriptions. The description merely restates the parameters (platform/deviceId) without adding new meaning, thus 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 'Dispatch the Android Back action', using a specific verb and resource. This distinguishes it from sibling tools like tap, swipe, and type_text.

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

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

Provides a recommended usage sequence and verification guidance, but does not explicitly state when not to use the tool or compare it to 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, the description must fully disclose behavior. It only mentions 'accumulated' and 'active session', but fails to explain what happens if no session exists, if the stream was not started, or whether reading clears the buffer. Minimal behavioral information.

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

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

The description is a single, short sentence with no extraneous words. It conveys the core action efficiently.

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

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

Given the lack of output schema and parameter descriptions, the description is too minimal. It does not cover return format, error behavior, or relationship to other tools like start_log_stream. The tool has 1 parameter but no elaboration.

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

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

Schema description coverage is 0%, so the description should add meaning to the sessionId parameter. It does not mention the parameter at all. 'Active session' is implied but not linked to the parameter, leaving the agent to guess its role.

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 'read' and the resource 'accumulated log stream entries'. It distinguishes from sibling tools like start_log_stream and stop_log_stream by focusing on reading. However, 'active session' is somewhat vague, preventing a perfect score.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites like calling start_log_stream first, nor does it exclude scenarios. The description lacks any context for appropriate usage.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'clear storage' but does not elaborate on what data is removed (e.g., cache, user defaults), whether the app is terminated, or if the action is reversible. The description is insufficient given the potentially destructive nature of 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 very concise (one sentence), but it sacrifices important details for brevity. It would benefit from additional context about the action's impact, which could be added without becoming overly verbose.

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

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

The tool has moderate complexity with three parameters and no output schema. The description omits important context such as what happens after the reset (e.g., app restarts, data is lost permanently) and prerequisites (e.g., app must be installed). This gap leads to an incomplete understanding for the agent.

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

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

Schema description coverage is 67% (two of three parameters have descriptions). The tool description adds no further parameter semantics beyond the schema, but the existing schema descriptions are adequate. 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 'reset app data (clear storage)' and the target 'mobile app on Android or iOS simulator'. It uses a specific verb and resource, distinguishing it from sibling tools like start_app or get_logs.

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

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

The description provides no guidance on when to use this tool versus alternatives such as reinstalling the app or using other reset methods. It does not mention that this is a destructive action or suggest use cases like simulating a fresh install.

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, but the description fully covers behavioral traits: output structure, success/failure conditions, lifecycle state, and integration with verification steps. It also includes failure handling for TIMEOUT and UNKNOWN cases.

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?

Well-structured with clear sections (Purpose, Inputs, Output, Recommended Usage, etc.). While verbose, every section adds value for an AI agent, and the purpose 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?

Despite no output schema, the description provides a detailed output structure and workflow integration with sibling tools. It is complete for the tool's complexity and the given context signals.

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 67%, and the description lists parameter names but adds minimal additional meaning beyond the schema's descriptions. The baseline for this coverage is 3, and the description does not significantly elevate 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 'restart' and the resource 'mobile app on Android or iOS'. It distinguishes itself from sibling tools like start_app, terminate_app, etc.

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

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

Provides a step-by-step recommended usage pattern including waiting and verification with other tools. Does not explicitly state when not to use it or alternatives, but the guidance is clear and context-aware.

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?

Despite no annotations, the description details the post-dispatch lifecycle state, success conditions, failure codes, and optional fingerprint fields. It does not mention potential side effects like scroll causing layout changes, but overall it is transparent.

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

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

The description is well-structured with clear sections and front-loaded purpose. However, the output structure section is very verbose and could be more concise, especially since there is no output schema to offload 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 the complexity (6 parameters, nested object, enums) and no output schema, the description covers usage workflow, success criteria, and failure modes. It lacks detail on the resolved element info output, but is otherwise 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?

The description lists parameters but does not explain their meaning beyond the input schema. Schema coverage is only 33%, and the description does not add value for the undocumented parameters (direction, maxScrolls, scrollAmount). For example, 'scrollAmount' could be a fraction or absolute value, but no clues are given.

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

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

The purpose is clearly stated as 'Scroll until a target element becomes visible.' This is a specific verb+resource action that distinguishes the tool from siblings like tap, swipe, and find_element.

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 usage guidance including a recommended workflow (RESOLVE → ACT → WAIT → EXPECT), verification guidance (when to use expect_element_visible vs wait_for_*), and failure handling instructions for specific error types.

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 fully discloses behavior: dispatches launch, lifecycle states, success/failure codes, and UI fingerprints. 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?

Well-structured with sections (Purpose, Inputs, Output, Usage, Failure). Slightly verbose but all content is valuable and 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 no output schema, the description fully explains output structure, usage workflow, and failure handling. Sufficient for an app launch action.

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?

Adds meaning beyond schema: appId as 'Android package name or iOS bundle id', deviceId defaulting to 'booted/connected'. Covers all three parameters 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 clearly states 'Launch a mobile app on Android or iOS' with specific verb and resource, and the parameter list distinguishes it from sibling tools like terminate_app or restart_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?

Provides explicit step-by-step usage (define landing screen, call, wait, verify, retry) and failure handling guidance (TIMEOUT, UNKNOWN). Clearly differentiates from other 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 must fully disclose behavior. It mentions the underlying commands (adb logcat, xcrun) but omits lifecycle details, resource usage, or whether the stream runs continuously until stopped. The sessionId parameter hints at manageability but is not explained.

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 efficiently convey the action and platform details without extraneous information. The structure is 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?

Given the tool has 5 parameters and no output schema or annotations, the description covers the main purpose and platform differences. It lacks details on return values, lifecycle management, and potential side effects, but is sufficient for a start action.

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 60%, with some parameters defaulted. The description adds context by explaining platform-specific commands (adb logcat, xcrun) and the default device behavior. However, it does not elaborate on each parameter's semantics 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 tool starts streaming logs for an app on Android or iOS, with specific commands for each platform. It distinguishes from siblings like get_logs and stop_log_stream by focusing on starting the stream.

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 real-time log streaming but does not explicitly state when to use this tool over alternatives like get_logs or read_log_stream. No usage exclusions or prerequisites are provided.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states the action 'stop' without detailing side effects (e.g., whether logs are discarded, if all streams are stopped, or if it requires an active stream). This is insufficient for a tool with potential destructive implications.

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

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

The description is only 8 words in a single sentence, which is efficient and front-loaded. However, it sacrifices essential detail for brevity.

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

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

For a simple tool with one parameter and no output schema or annotations, the description covers the basic purpose but lacks behavioral details and parameter guidance. It is minimally 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 0%, and the description does not explain the sessionId parameter. The parameter name is somewhat self-explanatory, but format, required status, or typical usage is missing, leaving the agent to guess.

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 stops an active log stream for the session, using a verb+resource pattern. It is distinguishable from sibling tools like start_log_stream and read_log_stream, though it does not explicitly differentiate.

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

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

No guidance on when to use this tool versus alternatives such as get_logs or read_log_stream. No mention of prerequisites or conditions like requiring an active stream.

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?

Discloses output structure, lifecycle states, failure codes, and notes that swipe outcomes are less predictable. No annotations contradict.

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?

Well-structured with clear sections, front-loaded with purpose. Slightly long 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?

Covers output structure, usage, verification, failure handling, and parameter details. Complete care for a 7-parameter tool with 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?

Input section adds context beyond 100% schema coverage, e.g., defaults for deviceId. Schema already detailed, but description adds 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?

Clearly states 'Dispatch a swipe gesture on Android or iOS.' Distinguishes from sibling tools like tap, scroll_to_element.

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 'Recommended Usage' steps, 'Verification Guidance' (e.g., Do not use wait_for_* alone), and 'Failure Handling' strategy.

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 details the output structure (action_id, timestamp, lifecycle_state, success flag, failure codes, UI fingerprints) and failure handling (retries, snapshot capture). This is comprehensive and transparent.

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

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

The description is well-structured with clear sections (Purpose, Inputs, Output, Usage, Failure). While lengthy, each section adds necessary guidance. Minor redundancy could be trimmed 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 no output schema, the description compensates by detailing the output structure thoroughly. It also covers the recommended workflow, failure handling, and reference to sibling tools (tap_element, wait_for_*, expect_*). Complete for the 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?

Schema coverage is 100%, so baseline is 3. The description adds context by summarizing parameters (x, y coordinates, optional platform and deviceId) and implying defaults. It does not repeat exact schema details but adds value by grouping optional fields.

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 dispatches a tap at specific screen coordinates, distinguishing it from tap_element which should be preferred when an element is available. The verb 'dispatch' and resource 'tap at coordinates' are specific.

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 a Recommended Usage section with a clear sequence (RESOLVE → ACT → WAIT → EXPECT) and explicit guidance to prefer tap_element over tap. It also provides Verification Guidance and Failure Handling, detailing when and how to use the 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?

No annotations provided, so description carries full burden. It details output structure, failure codes (STALE_REFERENCE, ELEMENT_NOT_INTERACTABLE, UNKNOWN), retry logic, and clarifies that success only means execution, not outcome. Very 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?

Well-structured with sections (Purpose, Inputs, Output Structure, Recommended Usage, etc.). It is relatively long but every sentence adds value given the tool's complexity.

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

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

Comprehensive coverage: usage flow, verification guidance, failure handling, and output details. Without output schema, the description compensates fully by listing expected fields.

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

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

Schema coverage is 100% (1 parameter, elementId). The description adds meaning by explaining how to obtain elementId from wait_for_ui and its purpose, going beyond the schema's brief 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 clearly states the tool's purpose: 'Tap a previously resolved UI element using its elementId.' This is specific and distinguishes it from siblings like generic 'tap' by requiring a resolved elementId from wait_for_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 'Recommended Usage' section provides a clear workflow (RESOLVE → ACT → WAIT → EXPECT) and when to use expect_screen vs expect_element_visible. However, it does not explicitly exclude usage scenarios compared to siblings like 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether termination is graceful or forceful, if it triggers confirmation dialogs, or what happens to app state. The agent lacks insight into side effects or constraints beyond the obvious terminal action.

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

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

The description is a single, clear sentence with no unnecessary words. It efficiently conveys the core purpose and platform scope, making it easy to parse quickly.

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

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

Given the 3 parameters (2 required) and no output schema, the description is too minimal. It omits behavioral details, usage context, and error scenarios. The agent would need to consult other documentation or trial-and-error to use this tool reliably alongside the listed 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?

The description adds no additional meaning to the parameters beyond what the input schema already provides. While the schema covers 'appId' and 'deviceId' with descriptions, the 'platform' parameter is only listed via enum and has no separate description; the description does not compensate for this gap or clarify parameter relationships.

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 ('terminate'), the resource ('a mobile app'), and the context ('on Android or iOS simulator'). It effectively distinguishes this tool from sibling tools like start_app, restart_app, or stop_log_stream by specifying the exact operation and platform.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., restart_app, press_back, or force stop via system settings). The description lacks context about prerequisites, session states, or typical use cases, leaving the agent to infer without support.

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 typing into focused input, optional deviceId/platform, output structure including success, failure, lifecycle states, and ui fingerprints. 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?

Well-structured with clear sections (Purpose, Inputs, Output Structure, Recommended Usage, etc.). Every sentence adds value, 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?

Comprehensive for a tool with no annotations and moderate complexity. Includes output structure, failure handling, and verification steps, fully covering agent needs.

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%, but description adds behavioral context (e.g., 'currently focused input', default device connection) 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 'Type text into the currently focused Android input field.' This is a specific verb and resource, and it distinguishes from sibling tools like tap, swipe, and press_back.

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 step-by-step usage flow (RESOLVE → ACT → WAIT → EXPECT), verification guidance, and failure handling. Helps the agent decide when and how to use the 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?

Discloses key behavioral traits: it only detects change, not correctness, and does not verify resulting state. Constraints are clearly listed. Without annotations, this description carries the full burden and does it well.

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?

Well-structured with sections (Purpose, Capabilities, Constraints, Recommended Usage). Front-loaded with purpose. Slightly verbose but every sentence adds value. Could be trimmed slightly.

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

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

Covers purpose, capabilities, constraints, and usage workflow. No output schema exists, but behavior (wait, detect change) is clear. Could mention timeout behavior more explicitly, but overall 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%, so baseline is 3. The description does not add significant meaning beyond the schema; it only mentions previousFingerprint as required. No extra explanation of other 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's purpose: detecting screen transitions via fingerprint comparison. It distinguishes from expect_* tools but does not explicitly differentiate from sibling 'wait_for_ui_change', leaving some ambiguity.

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 and when-not-to-use guidance, including a note not to use alone when an expect_* tool exists, and alternative for backend/API activity. The 'Recommended Usage' section offers a clear workflow.

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

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

Without annotations, the description discloses that it does not verify correctness of the resulting state and is deterministic. This adds behavioral context beyond the schema, though it lacks edge-case or error behavior details.

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 well-structured into clear sections (Purpose, Capabilities, Constraints, Recommended Usage) with no redundancy. Minor inefficiency: the phrase about deterministic element resolution appears twice.

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 8 parameters, nested objects, and no output schema, the description provides high-level purpose and constraints but lacks details on parameter interplay, return value, and error conditions, leaving significant gaps.

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

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

Schema description coverage is only 25% (only 'contains' subfield described). The description does not explain parameters like match, retry, selector, condition, or timeout beyond their schema defaults, failing to compensate for low coverage.

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

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

The description clearly states the tool resolves elements and detects UI transitions/conditions, with a specific verb and resource. It distinguishes from siblings like wait_for_screen_change by focusing on element-level synchronization.

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?

Explicit recommended usage steps are provided: resolve element, call action, then verify with expect_*. Also states a constraint: not to be used alone when expect_* exists, providing clear when-to-use and when-not.

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 carries full burden. It explains the wait behavior, mentions returned 'snapshot_revision', scope-aware metadata, and failure handling. Lacks details on authorization or side effects, but as a wait tool, those are less critical.

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?

Well-organized with sections (Purpose, Inputs, Guidance, Failure Handling). Every sentence is informative. Front-loaded with purpose. 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 7 parameters fully described in schema, no output schema, and many siblings, the description provides sufficient context: purpose, parameter roles, usage preferences, and failure handling. An agent can effectively decide when and how to use 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 coverage is 100%, so baseline 3. The 'Inputs' section lists parameters but adds little beyond the schema definitions. Some guidance is given (e.g., 'target is for subtree'), but no additional semantic depth.

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 it waits for a non-navigation UI mutation or in-place update to become stable, and later distinguishes from wait_for_screen_change. The verb 'wait' and resource 'UI change' are specific, and the scope is clarified.

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 when-to-use guidance: 'Prefer wait_for_screen_change for navigation transitions. Prefer wait_for_ui_change for in-place mutations.' Also includes a Failure Handling section describing TIMEOUT behavior.

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