polyscreen-mcp

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds context: it explains the heuristic nature of bucket ranges, the need for calibration, and that full timeline is omitted unless includeFullTimeline=true. This goes beyond annotations.

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

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

Three sentences, front-loaded with purpose. Every sentence adds value: first defines core function, second adds calibration note, third mentions mode and timeline option. 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 11 parameters and an output schema (present but not shown), the description covers the main purpose, calibration, mode usage, and timeline behavior. It would be stronger if it explained the output format, but the output schema exists. Almost complete for a complex 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 27% (3 of 11 params). The description adds meaning for mode (flash sets defaults) and mentions exportSampleFrames and includeFullTimeline, but leaves many parameters (fps, path, marks, etc.) unexplained. The description compensates partially but not fully for low schema 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 samples mean grayscale over an MP4, detects black/dim runs, and classifies brightness buckets. It uses specific verbs and distinguishes from siblings like mobile_theme_flash_report by mentioning mode='flash' for regressions.

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 for using mode='flash' and calibrating with exportSampleFrames. It implies the tool is for analyzing recordings for brightness issues, which is clear but does not explicitly state 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries a lower burden. The description adds 'Read' confirming idempotent behavior, but does not disclose potential failure modes (e.g., app not found) or whether the tool is safe to call repeatedly. It provides no extra behavioral context beyond what annotations offer.

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 that front-loads the purpose ('Read...'). It is efficient with no wasted words, but it lacks any additional structure or detail that could improve usability 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?

With an output schema present, the description does not need to detail return values. However, the description omits important context such as the fact that this tool targets Android apps (evident only from title), the requirement that the app must be installed, or any error conditions. For a tool with few parameters and good annotations, it is minimally adequate but not comprehensive.

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 50% (serial has a description, packageName does not). The tool description says 'Read package state...' which vaguely relates to packageName but does not clarify its meaning or pattern. It adds no new semantics beyond parameter names. Baseline is 3 due to moderate coverage and no param-specific elaboration.

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 'Read package state, permissions, components, users, and installation metadata', using a specific verb and resource. It clearly distinguishes from sibling tools like mobile_app_launch (launch) and mobile_app_install (install), which are write operations, and from other read tools like mobile_device_inspect which inspect the device rather than a specific 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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context such as prerequisites (e.g., app must be installed) or scenarios where this tool is preferred over mobile_device_inspect or mobile_server_info. No when-not-to-use or sibling differentiation is mentioned.

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

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

Annotations already indicate it is not read-only and not destructive. The description adds 'bounded timeout and structured ADB result', which provides useful behavioral context beyond the annotations, but does not elaborate on side effects or required permissions.

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

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

The description is a single sentence of 9 words, front-loading the action. It is efficient but may be overly brief for the level of detail needed.

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, low schema coverage, and existing annotations, the description lacks completeness. It does not explain the role of 'replace', the necessity of 'serial', or the nature of the structured result, leaving gaps for an agent.

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

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

With schema coverage at only 33%, the description should compensate but fails to add meaning. It only implies that 'path' is for a local APK, but does not explain 'replace' or the significance of 'serial'. The serial description in the schema is already present.

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 (Install), the resource (one local APK), and adds distinguishing details (bounded timeout, structured ADB result). This differentiates it from siblings like mobile_app_launch and mobile_app_uninstall.

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 use for installing an APK but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. The context is implied from the purpose.

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

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

Annotations are all false, providing no safety hints. The description mentions 'wait diagnostics' but does not disclose side effects, permissions, or output behavior. The output schema is indicated but not explained, leaving the agent uninformed about the response.

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 is front-loaded with the action, but it lacks structure or additional breakdown. It is concise but at the expense of completeness.

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 (5 parameters, 3 required, output schema present but unspoken), the description is too brief. It does not explain key terms like 'resolve' or 'logical display', nor does it clarify the diagnostics behavior.

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

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

Schema description coverage is low (40%), and the tool description adds no further explanation of parameters like displayId or packageName. The agent must rely solely on the schema, which does not fully compensate.

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

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

The description clearly states the tool's purpose: to resolve and launch an activity on a logical display with wait diagnostics. The verb 'launch' and resource 'activity' are specific, and the tool is distinct from sibling tools like mobile_app_inspect or mobile_app_stop.

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 mobile_app_relaunch_on_displays. No when-not-to-use or prerequisites are mentioned.

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 explains the sequence of actions (force-stop then launch) and the target (each logical display). Annotations are minimal (all false) so the description carries the burden. It does not disclose potential side effects like killing the app or permission requirements, but adds some behavioral context beyond annotations.

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

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

Two concise sentences front-loaded with the action and the use case. No unnecessary words or repetition.

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

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

Given the tool has 6 parameters, low schema coverage, and an output schema (not shown), the description is brief but covers the core behavior. It lacks details on error handling, behavior with invalid displayIds, or what happens if the activity is not found. Adequate but not comprehensive.

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 17%, with only displayIds having a description. The tool description does not explain other parameters like serial, userId, activity, settleMs, or packageName. It mentions 'main (or given) activity', which relates to the activity parameter, but overall it adds little 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 tool force-stops a package and launches its activity on each logical display. It specifically mentions the use case for dual-display cold-start/flash reproduction, distinguishing it from siblings like mobile_app_launch or mobile_app_stop.

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 'Use for dual-display cold-start / flash reproduction', providing clear context. It does not explicitly mention 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?

The description adds context beyond annotations: it mentions including 'processes and pending implicit launches', which explains the scope of the stop action. Annotations already indicate idempotentHint=true and destructiveHint=false, and the description does not contradict these. However, it does not disclose potential side effects like loss of unsaved data or app state.

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

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

The description is very short (one sentence), which is concise, but it lacks important details such as parameter hints or usage context. It is minimal but not optimally informative.

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 an output schema (not shown in the provided data) but the description does not mention return values or behavior. For a force-stop operation, details about confirmation, error handling, or impact on other processes are missing, leaving the description incomplete.

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

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

Schema description coverage is only 33% (only 'serial' has a description). The tool description does not mention any parameters or provide additional meaning beyond the schema. For a tool with low coverage, the description should compensate, but it fails to do so.

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 title 'Force-stop Android app' and description 'Force-stop a package, including its processes and pending implicit launches' clearly specify the verb (force-stop) and resource (package). This effectively distinguishes it from sibling tools like mobile_app_launch or mobile_app_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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or scenarios. The agent is left to infer usage from the name alone.

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

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

The annotation already marks destructiveHint=true, and the description confirms destructive behavior. However, it fails to disclose potential side effects (e.g., required permissions, failure on system apps, irreversible removal).

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 conveys the essential purpose 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 the destructive nature and 3 parameters, more details are needed (e.g., return value, error cases, prerequisites). The output schema is present but not described.

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 meaning for keepData ('optionally retaining its data'), but packageName and serial rely on schema. With schema coverage at 33%, the description partially compensates.

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 (uninstall) and resource (a package), with the optional data retention feature. It distinguishes from sibling tools like mobile_app_install and mobile_app_inspect.

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, nor any exclusions (e.g., system apps). It only mentions optional data retention without context.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that it does not embed binary contents, clarifying the extent of data returned. No contradictions with annotations.

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

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

Two sentences, front-loaded with purpose, no extraneous information. Efficiently conveys the core functionality and a key exclusion.

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 a simple list tool with an output schema (presumably documenting return fields). Missing parameter description is a minor gap, but overall complete enough given the annotations and 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?

The only parameter 'limit' is not mentioned in the description. Schema provides default, min, max, but with 0% schema description coverage, the description should compensate and fails to do so, leaving agent to infer the parameter's effect.

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 lists metadata stubs (uri, name, mime, size) for files under the artifact root and explicitly says it does not embed binary contents, distinguishing it from potential sibling tools that might read file contents.

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 or alternatives. The usage is implied as a list operation, but the description does not differentiate from siblings like mobile_artifacts_prune or other list 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?

Annotations already indicate destructiveHint=true, and the description reinforces that it deletes files. It adds value by mentioning the dryRun preview behavior, which is beyond annotations. 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?

Two sentences, no wasted words. Each sentence provides critical information: the core action and the preview option.

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

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

The description covers the main purpose and key parameter usage. It could elaborate on the interaction when both maxAgeMs and maxCount are specified, but overall it is largely complete given the presence of 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 0%, so the description fully explains all three parameters: maxAgeMs and maxCount as deletion criteria, and dryRun as a preview mode. This adds essential meaning beyond the bare 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 'Delete' and the resource 'old or excess artifact files', and specifies criteria (maxAgeMs and/or maxCount). It distinguishes from sibling tools like mobile_artifacts_list by focusing on deletion.

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 advises using dryRun to preview deletions, providing a clear usage guideline. However, it lacks explicit when-not-to-use or alternative tools, missing the highest standard of 5.

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

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

Annotations already indicate read-only (readOnlyHint=true), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds the specific capability types probed (ADB, input, etc.), which provides some behavioral context beyond annotations. However, it does not disclose potential side effects like network usage or time cost.

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

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

The description is a single focused sentence of 14 words, front-loading the key information. No extraneous content.

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

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

For a tool with an output schema and clear annotations, the description lacks context about when this inspection is necessary (e.g., before certain mobile actions). It is adequate but not complete in guiding the agent's workflow.

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 50% of parameters (serial described, refresh only type/default). The description does not elaborate on the 'refresh' parameter or add any meaning beyond the schema. For a 2-parameter tool with partial schema coverage, the description should compensate but fails to do so.

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 probes the device's ADB, input, command, build, and backend capabilities. It uses a specific verb ('probe') and a clear resource ('capabilities'), and distinguishes from siblings like mobile_devices_list (listing devices) and mobile_app_inspect (app-specific inspection).

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. It does not mention prerequisites, such as having a device serial from mobile_devices_list, or when not to use it. Sibling tools exist for similar purposes but no distinction is made.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by detailing what the list includes (reachability, grouping, aliases), which goes beyond annotations. It does not contradict annotations.

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

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

The description is a single, well-structured sentence that front-loads the primary action ('List ADB devices') and provides essential detail without redundancy.

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

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

Given zero parameters and the presence of an output schema, the description provides a complete overview of what the tool returns, sufficient for an agent to select and use it appropriately.

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

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

There are no parameters, so baseline 4 applies. The description does not need to add parameter information, and the schema coverage is 100%.

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 ADB devices and specifies the output details (reachability, hardware serial grouping, preferred TCP serial, aliases). This distinguishes it from sibling tools like mobile_device_inspect which inspects a single 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 implicitly indicates this tool is for listing devices, but it does not explicitly mention when not to use it or provide alternatives. However, given the simplicity and zero parameters, the usage 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?

Annotations already declare read-only, idempotent, non-destructive. Description adds valuable detail about what information is listed (logical displays, physical capture IDs, evidence, focus state). 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?

Single, concise sentence that front-loads the key action and results. 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 existence of an output schema, the description sufficiently covers the tool's purpose and outputs. It mentions all key elements without being verbose.

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 a thorough description of the serial parameter. Description does not add any additional parameter information, so baseline 3 applies.

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

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

Description clearly states it lists logical displays with correlated physical capture IDs, evidence, and focus state. Differentiates from sibling tools like mobile_screen_capture and mobile_focus_trace.

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

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

No explicit when-to-use or when-not-to-use guidance. The serial parameter is documented in schema, but no context on when this tool is preferable over 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?

Description discloses blocking behavior and artifact writing for large sample sets, which are key behavioral traits not covered by annotations. However, it does not mention permissions, prerequisites, or potential side effects, slightly limiting full 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 three concise sentences with front-loaded purpose, no redundant wording, and each sentence adds distinct 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 tool's complexity (6 parameters, blocking nature), the description omits return format, error conditions, and prerequisites. The existence of an output schema only partially compensates.

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 17%, and the description adds no parameter-specific information. Essential parameters like durationMs, maxSamples, and includeAllSamples lack meaningful explanation beyond the schema defaults.

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

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

Description clearly states the tool performs a blocking trace of focused package/activity/taskId per display for a fixed duration. It explicitly distinguishes from the start/stop variant, 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?

Explicitly recommends preferring mobile_focus_trace_start/stop for interleaved scenarios, providing clear when-to-use guidance. Also notes the artifact behavior for large samples.

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

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

Annotations are all false (not read-only, not idempotent), so description adds value by disclosing non-blocking nature, ring-buffering with maxSamples, and optional record binding. Could mention that samples overwrite when buffer full or that stopping is required.

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-load purpose, then provide key behavioral details (non-blocking, buffer, binding). No unnecessary words or repetition of schema fields.

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 output schema present, return values need not be described. Description covers core behavior, optional binding, and default interval. Lacks mention of prerequisites (valid serial/displays) or lifecycle (requires stop tool), but acceptable for a focused 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 low (20%), but description adds meaning: 'logical displays', 'non-blocking', 'ring-buffered', and 'maxSamples' clarifies buffer behavior. Bound record alignment explained. However, some parameters (serial, displayIds) are well-documented in schema already.

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 'Start non-blocking focus sampling for logical displays' with specific verb and resource. Distinguishes from sibling tool mobile_focus_trace (which likely represents a different operation like a one-time trace) and pairs with mobile_focus_trace_stop for 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?

Description provides context on optional binding and default behavior but does not explicitly state when to use versus alternatives like mobile_focus_trace (possibly a synchronous variant). No exclusionary guidance or prerequisites mentioned beyond schema hints.

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

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

Annotations provide no destructive or readOnly hints, but the description adds transparency by noting that large traces write samples to an artifact, a significant side effect. It also describes the output fields. However, it does not clarify whether stopping is idempotent or if it destroys the session beyond retrieval.

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 core purpose and output. Every sentence adds value without redundancy.

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

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

Given the simplicity of the tool (stop a session and return data), the description is mostly complete. It mentions return fields and the artifact side effect. However, it omits linking `focusSessionId` to the start tool and does not leverage the presence of 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 only 33%, and the description does not explain the `includeAllSamples` parameter. It mentions 'samples' but lacks specifics. The `focusSessionId` is not described in context, relying on format alone. The description needs to compensate for the low schema coverage but falls short.

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

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

The description clearly states the action ('Stop an async focus session') and what it returns ('focus change events plus samples'). It distinguishes from sibling tools like mobile_focus_trace_start by focusing on stopping. The preference for `changes` adds specificity.

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 hints at usage with 'Prefer `changes` for flash/launcher hunting', but does not explicitly state when to use this tool versus alternatives like mobile_focus_trace_start. No exclusion criteria or prerequisites are mentioned.

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 the action is a long-press drag-and-drop and is capability-gated, which adds some behavioral context beyond annotations. However, it does not confirm whether the action is destructive or reversible, and annotations provide no destructive hint. The description is not contradictory but leaves 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?

Single sentence that efficiently conveys the core action. No extraneous text, but could benefit from structured breakdown of behavior and parameters.

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

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

Despite having an output schema, the description does not mention what the tool returns. The complexity of drag-and-drop with coordinate objects and parameters is not fully addressed. The description is too brief 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 only 40%, meaning only serial and displayId have descriptions in the schema. The description adds no parameter details, leaving the start, end, and durationMs parameters undocumented. The action description implies coordinates and duration, but specifics are absent.

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

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

The description clearly indicates the tool performs a long-press drag-and-drop action, specifying the action type and scope ('on one logical display'). However, it does not differentiate from sibling tools like mobile_input_swipe or mobile_input_tap, which perform similar input 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?

No guidance on when to use this tool versus alternatives. The phrase 'capability-gated' hints at a precondition but does not explain what the gate is or how to meet it. No exclusion criteria or alternative tool mentions.

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

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

The description mentions 'capability-gated press options', hinting that certain actions may be unavailable depending on device capabilities. Annotations are minimal (all false), so the description adds some behavioral context. However, it does not disclose error handling, side effects, or 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 a single sentence that is concise and front-loaded with the main action. It contains no fluff, but given the tool's complexity with 6 parameters, additional structured information (like a brief list of keys) could be beneficial without sacrificing 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?

The description covers the basic purpose but lacks completeness for an agent to correctly differentiate from 30+ sibling tools. It does not mention the key format or common use cases. With an output schema assumed, it doesn't need to explain return values, but it should still provide enough context for appropriate tool selection.

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

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

With only 33% schema description coverage, the description partially compensates by clarifying that 'key' can be symbolic or numeric, and that 'source' defaults to gamepad. However, it does not explain the 'action' enum values, 'durationMs', or 'displayId' beyond what the schema provides. More detail would be needed for full clarity.

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 sends Android keys, specifying 'symbolic or numeric' and 'gamepad source'. While it mentions 'gamepad source' as default, it doesn't explicitly differentiate from sibling tools like mobile_input_key_combination or mobile_input_text. However, it clearly indicates the core action of sending a key.

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 lacks any guidance on when to use this tool versus alternatives. It does not mention when to prefer this over mobile_input_key_combination or mobile_input_text, nor does it state prerequisites or conflicts. No when-to-use or when-not-to-use information is provided.

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

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

The description adds behavioral context about explicit ordering and chord duration beyond the annotations, but lacks details on error handling, blocking behavior, or prerequisites.

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

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

The description is a single concise sentence that immediately conveys the tool's purpose, with no 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 the complexity of 5 parameters and required params, the description is adequate but does not fully cover usage context such as valid key values or expected behavior for invalid inputs. Output schema exists but is not referenced.

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 40%, and the description does not provide additional meaning for parameters like keys, source, or durationMs beyond the brief 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 injects a device-supported key combination with explicit ordering and chord duration, distinguishing it from single-key tools like mobile_input_key.

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 simultaneous key combinations through the title and name, but does not explicitly state when to use this tool versus alternatives like mobile_input_key or mobile_input_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?

Annotations indicate non-destructive and non-readOnly behavior, but the description adds little beyond stating it 'injects' a swipe. It does not disclose potential side effects (e.g., what happens if multiple displays), required permissions, or whether the operation blocks. The explicit duration is already captured by the durationMs parameter in the schema, so no added value.

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-loading the key purpose. It is concise with no redundancy. However, it may be too terse, sacrificing clarity on parameter semantics and usage context.

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 (including nested objects), an output schema, and lacks schema descriptions for 60% of parameters, the description is insufficient. It does not explain how to construct the swipe (e.g., coordinate system, units), the role of serial and displayId, or what the output contains. The agent would need to rely on external knowledge.

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

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

Schema description coverage is only 40% (only serial and displayId have descriptions, but they are nested in properties). The description does not explain start, end, durationMs, or how they relate to the swipe gesture. For parameters like start and end (nested objects with x,y), the description provides no semantics beyond the schema field names.

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

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

The description clearly identifies the tool as injecting a touchscreen swipe with explicit duration, and 'display-targeted' distinguishes it from non-display inputs. It uniquely specifies the action (swipe) and the target (touchscreen display), making it distinct from siblings like mobile_input_tap and mobile_input_drag.

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

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

No guidance is provided on when to use this tool versus alternatives such as mobile_input_drag. The description does not mention prerequisites, conditions, or when not to use it. The agent would have to infer context from the tool name and sibling list.

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

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

Annotations indicate non-read-only, non-destructive, non-idempotent, but the description adds no behavioral context beyond that. For a tool that triggers UI state changes, there's no mention of system impact, permissions, or response 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?

Single sentence, no unnecessary words, directly states the action and object. Efficient and 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?

Given the tool's simplicity and the presence of an output schema (from context), the description covers the essential purpose and coordinate semantics. Minor gap: no mention of where the tap lands if coordinates exceed display bounds.

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 50% of parameters with descriptions (serial, displayId). Description adds 'logical display coordinates' which clarifies x,y meaning, but doesn't explain coordinate system origin or units. Adequate but minimal added 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 states specific verb ('inject'), resource ('display-targeted touchscreen tap'), and key qualifier ('logical display coordinates'). Clearly differentiates from sibling tools like swipe, drag, and key inputs.

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 or when not to use this tool versus alternatives. Context from sibling names implies it's for touchscreen taps, but no comparative statements or prerequisites are given.

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

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

Annotations provide no safety or behavior hints (all false). The description adds value by disclosing that the tool 'Reports the Unicode limitation instead of hiding it,' which tells the agent that there is a known limitation regarding Unicode input and that the tool will surface it. This goes beyond what the schema conveys, though it does not detail the exact limitation.

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 brief at two clauses total. It front-loads the core purpose. The second clause is somewhat vague ('Reports the Unicode limitation instead of hiding it') but adds relevant detail. It could be slightly clearer, but overall earns its place without extra 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 tool has three required parameters and an output schema (not shown), the description lacks sufficient completeness. It does not mention return values, side effects (e.g., does it clear existing text?), or how the Unicode limitation affects usage. An agent would need to infer or discover additional behavior from other sources.

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% (two of three parameters have schema descriptions). The description does not add any parameter-specific information; it neither explains the 'text' field nor provides usage context not already in the schema. With high coverage, a baseline of 3 is appropriate, but the description fails to compensate for the undocumented '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 clearly states the tool's purpose: 'Type text through ADB's virtual keyboard.' This specifies the action (type) and the resource (text via ADB virtual keyboard). It also mentions reporting a Unicode limitation, which adds further clarity and distinguishes it from sibling input tools like tap, swipe, or key combination.

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. It does not mention that for non-text input one should use mobile_input_tap or mobile_input_swipe, nor does it specify prerequisites or scenarios where this tool is appropriate. The sibling tools include many input variants, but no comparative context is given.

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

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

The description introduces a concept ('offsetMs from record start') that does not exist in the input schema; the actual parameters are label, serial, and recordId, with no offsetMs. This discrepancy could mislead an agent. Annotations are all false, so the description carries full burden, but it fails to disclose whether labels must be unique, the effect on the recording, or what happens if the recordId is invalid. The claimed offsetMs is not a parameter, reducing trustworthiness.

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, which is concise. However, it includes a potentially misleading reference to 'offsetMs' that could confuse agents. Most of the sentence is useful, but the erroneous detail slightly reduces efficiency.

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

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

The tool has three required parameters and an output schema (not shown). The description provides context about correlating with other tools but omits details like when exactly to invoke (e.g., during an active recording) and how the label relates to the recording timeline. With a moderate complexity (3 params, no enums), the description is adequate but not fully comprehensive.

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% (label and serial have descriptions; recordId lacks one). The tool description adds limited parameter meaning: it explains that the label is a 'labeled timestamp' for correlation, which slightly enriches the label parameter but adds nothing for serial or recordId. Given the baseline of 3 for high coverage, the minimal extra value keeps the score at 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 function: 'Attach a labeled timestamp... for later correlation with analyze/focus/logcat.' It specifies verb (attach), resource (timestamp on a recording), and intended use (correlation), distinguishing it from sibling tools like mobile_analyze_recording or mobile_focus_trace which perform analysis, not marking.

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 to use the tool ('for later correlation with analyze/focus/logcat'), implying it should be used during or after recording to mark points of interest. It does not explicitly mention prerequisites (e.g., active recording) or when not to use it, but the purpose is clear enough for an agent to infer context.

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

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

The description adds behavioral context beyond annotations: it discloses that the tool is non-blocking, allows concurrent input, and enforces one session per (serial, displayId). This complements the annotations (readOnlyHint=false, openWorldHint=true) 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 two sentences, front-loaded with the key action and non-blocking distinction. Every word earns its place; no redundancy or irrelevant 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 tool's simplicity, 2 required parameters, and existence of an output schema, the description covers essential aspects: purpose, non-blocking nature, session constraint, and integration with input tools. Minor omissions like error conditions or default storage location are acceptable.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by clarifying that 'serial' is exact and must not be inferred, and that 'displayId' is a logical ID, not a physical one. This extra context helps the agent use parameters correctly.

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

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

The description clearly states the specific verb 'Start' and resource 'non-blocking screenrecord on one logical display'. It distinguishes from siblings by emphasizing 'non-blocking' and the session constraint, which differentiates it from other recording tools like mobile_screen_record.

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 when input tools need to run during capture, but it does not explicitly name alternatives or state when not to use this tool. While the non-blocking nature hints at a comparison, it lacks explicit guidance on choosing between this and its siblings.

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

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

Discloses the use of SIGINT, artifact creation, and return format. Annotations already indicate non-read-only and non-destructive; the description adds process details beyond annotations.

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

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

Single sentence that is front-loaded and concise, with no superfluous words. Every part earns its place.

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

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

Describes core behavior but omits prerequisites (must have an active recording started by mobile_record_start) and does not elaborate on 'marks' or 'offsets' despite having an output schema. Adequate for a simple tool but could be more helpful.

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%, and the description adds no parameter-specific meaning. It does not explain recordId beyond what the schema provides (pattern, no description). Baseline of 3 for moderate coverage, but fails 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 stops a screen recording using SIGINT, pulls the resulting MP4 into artifacts, and returns marks with offsets. This is specific and distinguishes it from siblings like mobile_record_start.

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 vs alternatives (e.g., it should follow mobile_record_start). Requires a recordId, but prerequisites are not 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?

Annotations indicate it's not read-only, and description adds internal resolution step. However, it does not clarify artifact creation, error handling, or permission requirements. Annotations balance the safety profile.

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

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

The description is very concise (one sentence, 12 words) and front-loaded with action and resource. It could be slightly expanded with a use-case note without becoming verbose.

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

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

Covers core purpose but lacks details about saveArtifact, error scenarios, and use-case guidance relative to siblings. Output schema handles return values, so completeness is adequate for this simple 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?

The description adds meaning to displayId by explaining the resolution to physical ID. Schema already covers serial and displayId well, but saveArtifact is unexplained. Description compensates partially for moderate schema coverage (67%).

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 (capture) and resource (one logical display), with technical nuance about resolving SurfaceFlinger physical display ID. It distinguishes from siblings like mobile_screen_record and mobile_displays_list.

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

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

The description provides no guidance on when to use this tool versus alternatives like mobile_screen_record or mobile_displays_list. It does not mention prerequisites or context for 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not need to repeat those. It adds the behavioral trait of tight pairing and same-moment capture, but does not disclose potential side effects (e.g., artifact creation, timing guarantees) or the non-idempotent nature beyond annotations.

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

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

A single sentence with a parenthetical clarification conveys the core purpose efficiently. Every word earns its place, and the structure is front-loaded with the action and resource.

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 captures the essence but omits important context: the meaning of 'display resolve', the output format (despite an output schema), and the behavior of saveArtifact. Given the tool's complexity and low schema coverage, a more complete description would improve usability.

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 low (33%), yet the description adds no parameter-level context. It does not explain the serial requirement, the meaning of displayIds, or the saveArtifact parameter. The agent must rely solely on the schema, which is insufficient for proper invocation.

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 ('capture'), the resource ('multiple logical displays'), and the unique value proposition ('tightly paired same-moment screenshots'). It distinguishes from sibling tools like mobile_screen_capture (single display) and mobile_screen_record (video). The parenthetical clarification reinforces the parallel, synchronized nature.

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 capturing multiple displays simultaneously but does not explicitly state when to use this tool vs. mobile_screen_capture or mobile_screen_record. No when-not-to-use guidelines 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?

Discloses blocking behavior and bounded duration, which are not captured by annotations. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, etc.).

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, front-loaded with core action, 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 tool's simplicity and presence of output schema, the description covers essential points: blocking, bounded duration, and alternative tool. Could mention output details but not critical.

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 67% of parameters (serial and displayId have descriptions). Description implies duration parameter via 'bounded duration' but adds no new details beyond schema for serial/displayId. DurationSeconds lacks description in schema and description.

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

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

Clearly states it records a display with 'Blocking record of one physical-backed display for a bounded duration.' Distinguishes from sibling tools by explicitly preferring mobile_record_start/mark/stop for interleaved input.

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 alternative for a specific use case ('when input must be interleaved'), guiding when not to use this tool. Could be improved by mentioning other relevant 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat safety traits. It adds valuable behavioral context by specifying the exact return data and the recommended invocation scenario, complementing the annotations perfectly.

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

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

Two short sentences with no wasted words. The first sentence immediately states the purpose, and the second provides a clear usage tip.

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, the presence of annotations and an output schema, and the clear description of return values and usage, the definition is fully complete. No additional information is needed for an agent to select and invoke this tool correctly.

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

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

There are zero parameters, and the schema coverage is 100% (empty). According to guidelines, baseline is 4. The description does not need to add parameter 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 what the tool returns (package version, active profiles, exact registered tool list) and provides a specific use case ('Call after reconnect to verify Cursor sees the full core surface'). It effectively distinguishes from sibling tools which focus on devices, displays, screens, and apps.

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

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

The description explicitly instructs when to use this tool ('after reconnect to verify Cursor sees the full core surface'). It does not mention alternatives or when not to use it, but given the tool's unique purpose and zero parameters, the guidance is sufficient for an AI 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?

Annotations provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds context about recovering IDs after reconnects, which is valuable behavioral information beyond the annotations.

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

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

The description is two sentences, direct and efficient. It front-loads the purpose and immediately gives usage context without any redundancies.

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, annotations cover safety, output schema exists, and description explains when to use. It lacks detail on output structure but that is likely handled by the 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?

The single parameter 'serial' is fully described in the input schema with details about exact ADB serial. The tool description does not add further semantic information, so baseline 3 applies given 100% schema 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 'Return active async recording, focus, and logcat sessions' with a specific verb and resource. It distinguishes from sibling tools like mobile_record_start/stop by focusing on listing active sessions.

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

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

The description explicitly says 'Use before stop/mark to recover IDs after a reconnect,' providing clear context on when to invoke this tool. It also mentions optional serial filter, implying 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?

The description only states 'correlate', which implies analysis. Annotations indicate no read-only or destructive hints, but the description lacks details on side effects, required permissions, or what happens to tool state. It does not contradict annotations but adds minimal behavioral context.

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

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

The description is a single concise sentence, front-loading the core correlation action. However, the density may reduce readability. It is efficient but could benefit from slight restructuring.

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 an output schema, reducing the need to describe return values. However, the description does not explain what the report contains or how to interpret results. Given the complexity of correlating night mode and recording analysis, more context would be helpful.

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 low (25%), with only 'serial' described. The description mentions 'markWindowMs' implicitly via '± markWindowMs', but does not explain 'path', 'artifactUri', or other parameters. The description partially compensates for one parameter but leaves others undocumented.

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

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

The description clearly states the tool correlates system night mode with recording analysis and marks, using specific terms like 'flash mode' and 'black/dim run'. It is distinct from sibling tools, though it could be more explicit about the output format.

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, context, or scenarios where it is preferred over similar tools like mobile_analyze_recording.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context (e.g., visibility requirements, search scope) beyond what is already known. It does not contradict annotations.

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

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

The description is a single sentence of 10 words with no filler. It is efficiently front-loaded with the core action and criteria.

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 6 parameters (2 required) and an output schema, the description leaves significant gaps. It does not explain how to combine multiple search fields (AND/OR logic), what the output contains (beyond schema), or edge cases like no match. The agent would need to guess critical usage patterns.

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

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

With only 33% schema coverage, the description lists the three search parameters but provides no additional meaning or usage details. For example, it does not explain how 'text' and 'exact' interact, whether searches are case-sensitive, or the format of 'resourceId'. The description fails to compensate for the low schema 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 verb 'find', the resource 'accessibility nodes', and the search criteria by which to find them (text, content description, or resource ID). It is specific and distinguishes from sibling tools like mobile_ui_snapshot and mobile_ui_wait.

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, nor does it mention prerequisites or exclusions. The agent is left to infer context from the tool name and sibling list.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds the display limitation (display 0 only with Portable ADB), which is useful behavioral context. However, it does not explain what 'companion' refers to or any other runtime behaviors.

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 with two sentences. The first sentence states the purpose, and the second adds a critical constraint. No unnecessary words or repetition.

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

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

For a simple read tool with an output schema, the description covers the core purpose and a key limitation. It could mention prerequisites (e.g., device must be awake) or clarify 'companion,' but overall it is adequate given the annotations and 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%, and both parameters have descriptions in the schema. The description does not add further meaning or usage hints for the parameters 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 states the tool 'Return parsed accessibility nodes,' which is a specific verb+resource. It clearly indicates it returns accessibility data. However, it does not explicitly differentiate from sibling tools like mobile_ui_find or mobile_ui_wait, which also deal with UI elements.

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 constraint ('Portable ADB supports only display 0; other displays require the companion') but offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or 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?

Annotations already provide readOnlyHint=true and idempotentHint=true, confirming safety. The description adds the polling mechanism and bounded timeout, which clarifies behavior beyond annotations. 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?

The description is a single, clear sentence with no unnecessary words, front-loading the core functionality effectively.

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

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

While the description covers the basic polling behavior, it omits details about return values, error handling, and parameter interactions. The existence of an output schema partially mitigates this, but the description alone is insufficient for complete understanding.

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%, leaving most parameters (e.g., text, exact, pollMs) undocumented. The description does not explain any parameter or add meaning beyond the schema, 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 polls (verb) until a matching accessibility node appears (resource) or timeout expires, which is specific and distinct from siblings like mobile_ui_find (snapshot) or mobile_ui_snapshot (capture).

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 waiting on UI elements but does not explicitly state when to use this tool versus alternatives like mobile_ui_find or mobile_ui_snapshot, nor 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.