MCP Scrcpy Vision

by invidtiv

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, such as android.input.swipe and android.input.dragDrop, which both involve screen gestures and could cause confusion. However, descriptions clarify their specific uses, and other tools are well-separated by domain (e.g., adb, input, screen, vision).
Naming Consistency5/5
Tool names follow a highly consistent pattern of domain.subdomain.action (e.g., android.adb.connectWifi, android.input.tap, android.screen.wake). This hierarchical naming scheme is predictable and aids in understanding the tool's purpose and category.
Tool Count2/5
With 33 tools, the count is excessive for a server focused on Android device control and vision. Many tools could be consolidated or omitted without losing functionality, leading to a bloated interface that may overwhelm agents and increase selection errors.
Completeness5/5
The tool set comprehensively covers Android device interaction, including adb connectivity, app management, file operations, input simulation, screen control, UI inspection, and vision streaming. There are no obvious gaps; it supports full lifecycle operations from setup to advanced automation.
Average 3.8/5 across 33 of 33 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions starting an app but doesn't disclose what happens on failure, whether it requires specific permissions, if it waits for app launch, or any side effects. The optional 'activity' parameter hints at deeper control but isn't explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, expected outcomes, error conditions, or how it fits with sibling tools, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds little. It mentions 'by package (optionally activity)', which loosely maps to 'packageName' and 'activity' parameters, but doesn't explain 'serial' (likely device identifier) or provide format examples. The three parameters remain largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Starts') and resource ('an Android app'), specifying it's done 'by package (optionally activity)'. It distinguishes from sibling 'android.app.stop' by being the opposite action, but doesn't explicitly differentiate from other app-related tools like 'android.apps.list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 is provided. The description doesn't mention prerequisites (e.g., device connection), when not to use it, or how it relates to siblings like 'android.app.stop' or 'android.apps.list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns values but doesn't describe what 'getprop' entails (e.g., system properties), potential errors (e.g., if device is unavailable), output format, or side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Returns a subset of getprop values for a device.' It's front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple but undocumented parameter, the description is incomplete. It doesn't explain what 'getprop' is, what subset of values is returned, or the output format. For a tool that interacts with Android devices, more context is needed to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('serial') with 0% description coverage, and the tool description doesn't mention parameters at all. However, since there's only one parameter and it's straightforward (device serial identifier), the baseline is 3. The description doesn't add meaning beyond the schema, but the simplicity of the parameter keeps the score from dropping lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns a subset of getprop values for a device.' It specifies the action (returns), resource (getprop values), and scope (subset, for a device). However, it doesn't explicitly differentiate from sibling tools like 'android.devices.list' (which likely lists devices rather than returning their properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., device connectivity), when-not-to-use scenarios, or how it relates to siblings such as 'android.devices.list' or 'android.shell.exec' (which might run arbitrary commands). Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the action ('Turns off the screen') and method ('using KEYCODE_SLEEP'), but lacks critical behavioral details: it doesn't mention if this requires device permissions, whether it's reversible (e.g., via android.screen.wake), potential side effects (e.g., locking the device), or error conditions (e.g., if the device is already asleep). For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two clear sentences that directly state the action and method. Every word earns its place, with no redundancy or unnecessary details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with no annotations and no output schema), the description is incomplete. It lacks information on prerequisites (e.g., device connectivity), behavioral outcomes (e.g., what happens after sleep), error handling, and how it integrates with sibling tools like android.screen.wake. For a tool that changes device state, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the 'serial' parameter beyond what the input schema provides (a required string). With 0% schema description coverage and 1 parameter, the description does not compensate by explaining what 'serial' represents (e.g., device identifier) or its format. However, since there's only one parameter and the tool's purpose is straightforward, the baseline is 3, indicating minimal but adequate coverage given the simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Puts to sleep') and resource ('device screen'), and mentions the specific mechanism ('using KEYCODE_SLEEP (223)'). It distinguishes from siblings like android.screen.wake (opposite action) and android.screen.isOn (status check), though not explicitly named. However, it doesn't fully differentiate from all screen-related tools like android.screen.unlock, which might have overlapping use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for turning off the screen, but it doesn't specify scenarios (e.g., to save battery, during idle periods) or contrast with other tools like android.screen.unlock (which might involve screen state changes) or android.screen.wake (the inverse action). This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions stopping a pipeline and removing a resource, which implies a destructive action, but fails to detail side effects (e.g., whether it terminates processes abruptly, frees memory, or requires specific permissions). This is inadequate for a tool that likely involves system-level operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly for its core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of stopping a vision stream (likely involving system processes), no annotations, no output schema, and low schema coverage, the description is insufficient. It lacks details on behavior, error handling, or what happens post-execution, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description adds no information about the 'serial' parameter's meaning or format. Since schema coverage is low, the description should compensate but does not, resulting in a baseline score of 3 due to the minimal parameter count, though it misses an opportunity to clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stops') and target ('scrcpy + ffmpeg pipeline and removes the frame resource'), which aligns with the title about stopping a vision stream. However, it doesn't explicitly differentiate from sibling tools like 'android.vision.startStream' beyond the obvious stop vs. start distinction, missing nuance about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as indicating it should only be called after starting a stream with 'android.vision.startStream' or in scenarios where stopping is necessary to free resources. It lacks context about prerequisites or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'force-stops,' which implies a destructive operation that terminates an app abruptly, but doesn't clarify side effects (e.g., data loss, background services stopping), permission requirements, or error conditions. This leaves critical behavioral traits unspecified for a potentially disruptive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('force-stops') and immediately specifies the target and key parameter. Every word earns its place by conveying essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral risks, parameter details beyond package name, expected outcomes, or error handling. For a tool that force-stops apps, this lack of context could lead to misuse or confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'package name' which maps to one parameter, but doesn't explain the 'serial' parameter at all or provide any additional context about parameter formats, valid values, or examples. This leaves half the parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('force-stops') and target resource ('an Android app by package name'), using precise technical terminology. It distinguishes itself from sibling tools like 'android.app.start' by specifying the opposite operation, and from 'android.shell.exec' by focusing on a dedicated app management function rather than general shell execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., device connectivity), when force-stopping is appropriate versus normal app closure, or how it differs from related tools like 'android.shell.exec' with kill commands. The agent must infer usage context from the tool name and sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool returns parsed output from 'adb devices -l', which implies a read-only operation without side effects, but doesn't disclose behavioral traits like error handling, dependencies on ADB connectivity, or format of the parsed output. This leaves gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Returns') and resource. There's no wasted text, and it directly conveys the tool's function without redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on the parsed output format, error conditions, or dependencies like ADB being installed and devices connected. For a tool in a complex Android automation context, this leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline is 4 for zero parameters, as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('output of adb devices -l'), specifying it's parsed. It distinguishes from siblings like android.devices.info by focusing on listing connected devices rather than detailed device information. However, it doesn't explicitly mention 'connected Android devices' as the title does, making it slightly less specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings include android.devices.info for detailed device information and android.adb.connectWifi for connectivity, but the description doesn't mention these or specify prerequisites like needing ADB setup. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions creation/updates of a resource. It omits critical behavioral traits: whether this is a long-running process, if it consumes significant resources, potential side effects on device performance, error handling, or how to monitor/stop the stream. The mention of 'continuous' hints at ongoing activity but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and implementation details in two concise sentences. However, the second sentence could be more integrated, and it lacks structural elements like bullet points for clarity, but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of starting a continuous stream, no annotations, no output schema, and 4 parameters with 0% schema coverage, the description is incomplete. It misses operational details (e.g., how to access the stream output, error conditions), making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'serial', 'maxSize', 'maxFps', or 'frameFps' mean, their units, typical values, or how they affect the stream. This leaves all 4 parameters semantically unclear beyond schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('start a continuous vision stream') and the resource ('for a device'), specifying it uses scrcpy server and ffmpeg decoding. It distinguishes from sibling tools like android.vision.snapshot (single capture) and android.vision.stopStream (termination).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for continuous vision streaming versus snapshot alternatives, but lacks explicit when-to-use guidance, prerequisites (e.g., device connectivity), or comparisons with other vision or device tools. It mentions resource creation but not operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the fallback behavior between scrcpy and adb protocols, which is useful context for performance or reliability. However, it lacks details on error handling, permissions required, or what happens if coordinates are out of bounds, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and efficiently adds technical details in a single, well-structured sentence. Every part earns its place without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters with 0% schema coverage, the description is moderately complete. It covers the basic action and fallback mechanism but lacks details on return values, error cases, or full parameter explanations, which could hinder safe usage in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions coordinates (x,y) and duration, mapping to parameters x, y, and durationMs, but doesn't explain the serial parameter (device identifier) or provide units/constraints beyond the schema. This adds some meaning but is incomplete for all 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Performs a long press') and the target ('at coordinates (x,y) on the device screen'), distinguishing it from siblings like android.input.tap (brief press) and android.input.swipe (drag gesture). However, it doesn't explicitly differentiate from android.input.dragDrop, which might also involve long presses as part of drag operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the fallback mechanism ('Uses fast scrcpy control protocol when stream is active, otherwise falls back to adb shell input'), which suggests context about performance or availability. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like android.input.tap for short presses or android.input.dragDrop for drag operations, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the filtering behavior (system/third-party/all) and the default (show all apps), which adds some context. However, it lacks critical details such as whether this is a read-only operation, if it requires specific permissions, the format of the output (e.g., list of package names), or any rate limits. For a tool with no annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, mechanism, and filtering options without unnecessary details. It is front-loaded with the core action and includes all essential information in a compact form, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the tool's purpose and parameter semantics for one parameter, but lacks details on behavioral aspects like output format, permissions, or error handling. Without annotations or an output schema, more context is needed for full completeness, but it meets a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'system' parameter's semantics by describing filtering options (system apps only, third-party apps only, or all apps), which clarifies its purpose beyond the schema's boolean type. However, it doesn't address the 'serial' parameter, leaving its meaning (likely device identifier) undocumented. With 2 parameters and partial coverage, this earns a 4 for adding meaningful context to one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('all installed packages'), and specifies the mechanism ('using pm list packages'). It distinguishes the tool's scope from potential siblings by focusing on app listing rather than device management or app control. However, it doesn't explicitly differentiate from other list tools like android.devices.list or android.file.list beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning filtering options (system apps only, third-party apps only, or all apps), which suggests when to adjust parameters. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like android.devices.list for device enumeration or android.file.list for file listing, nor does it mention prerequisites like device connectivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool performs a file transfer (implying a read operation from device and write to local system), and it specifies access requirements (readable remote path, writable local directory). However, it lacks details on error handling, performance, or side effects (e.g., overwriting local files).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose, followed by essential prerequisites. Every sentence adds critical value without any waste, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description provides basic operational context but is incomplete. It covers the what and key constraints but lacks details on return values, error cases, or integration with sibling tools (e.g., how it relates to 'android.file.push'). For a file transfer tool with three parameters, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some semantics by explaining that 'remotePath' must exist and be readable, and 'localPath' must be writable, which clarifies two of the three parameters. However, it doesn't explain 'serial' (likely a device identifier) or provide format examples, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Transfers a file from the device to the local filesystem') and the mechanism ('using adb pull'), which is specific and unambiguous. However, it doesn't explicitly differentiate from its sibling tool 'android.file.push' (which presumably pushes files in the opposite direction), though the directionality is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating prerequisites ('Remote path must exist and be readable. Local directory must be writable.'), but it doesn't explicitly say when to use this tool versus alternatives like 'android.file.list' (for browsing) or 'android.file.push' (for reverse transfers). The guidance is practical but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's read-only nature (finds/returns) and output format (center coordinates), but lacks critical behavioral details: whether it returns multiple matches, timeout behavior, screen state requirements (e.g., requires screen to be on), or error handling. For a tool with 5 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action (finds UI elements), specifies filters, and states the return value. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the purpose, filters, and return format adequately, but lacks details on behavioral traits (e.g., match limits, errors), parameter semantics beyond listing, and does not fully compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the four filter parameters (text, resource-id, class, content-desc) and implies the 'serial' parameter identifies the device, adding meaningful context beyond the bare schema. However, it does not explain parameter interactions (e.g., whether filters are AND/OR), format expectations, or the 'serial' parameter's purpose in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'finds' and resource 'UI elements in the current screen', specifying the filtering criteria (text, resource-id, class, content-desc) and the return value (matching elements with center coordinates). It distinguishes itself from sibling tools like android.ui.dump (which likely provides raw UI hierarchy) by focusing on filtered element discovery with actionable coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to locate UI elements for interaction (e.g., tapping), but does not explicitly state when to use this tool versus alternatives like android.ui.dump or direct input tools. It provides context about the current screen scope but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the command implementation ('adb shell ls -la') and return format ('detailed file information including permissions, ownership, size, and modification time'), which helps the agent understand what to expect. However, it doesn't mention potential limitations like device connectivity requirements, error conditions, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the action and implementation, the second describes the return format. Every word adds value, and the structure is front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description provides good behavioral context but leaves parameters completely undocumented. The return format description partially compensates for lack of output schema, but parameter semantics remain a significant gap. Overall adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'serial' and 'path' represent. While the tool's purpose implies 'path' is the directory to list, 'serial' remains completely unexplained. The description doesn't compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Lists') and resource ('files and directories on the device'), and distinguishes from siblings like android.file.pull/push by focusing on listing rather than file transfer operations. It provides concrete implementation details ('using adb shell ls -la') that further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the 'adb shell ls -la' detail, suggesting this is for Android device file system exploration. However, it doesn't explicitly state when to use this tool versus alternatives like android.shell.exec for custom commands or android.file.pull for file retrieval. No explicit exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the underlying implementation (adb shell input draganddrop) and version-dependent fallback behavior, which helps the agent understand execution characteristics. However, it doesn't mention potential side effects, error conditions, or what happens if the gesture fails, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides important implementation details. No wasted words, and the information is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a device interaction tool with 6 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the core action and implementation details but lacks information about return values, error handling, and full parameter explanations. For a tool that performs device input gestures, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for all 6 parameters. While it mentions 'start coordinates' and 'end coordinates' which map to startX/startY and endX/endY, it doesn't explain the 'serial' parameter (device identifier), 'durationMs', or provide any formatting details for coordinates. The description adds minimal semantic value beyond what's obvious from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('drags from start coordinates to end coordinates'), identifies the resource (Android device via coordinates), and distinguishes it from siblings like 'android.input.swipe' by mentioning the fallback mechanism. It uses precise technical terminology that differentiates this drag-and-drop gesture from other input methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying it works on Android 7+ with a fallback to swipe on older versions. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the fallback mention implies 'android.input.swipe' as an alternative for older versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral trait of disconnecting WiFi ADB connections, including the conditional logic based on the 'ipAddress' parameter. However, it lacks details on permissions required, error handling, or side effects (e.g., impact on other connections), which are important for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and efficiently explains parameter usage without redundancy. Every sentence earns its place by clarifying the tool's behavior, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with one optional parameter), no annotations, and no output schema, the description is adequate but incomplete. It covers the basic operation and parameter effect, but lacks details on return values, error cases, or prerequisites, which would enhance completeness for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the 'ipAddress' parameter as optional with its purpose. The description adds marginal value by reiterating the optionality and effect (disconnect specific vs. all devices), but does not provide additional syntax, format, or constraints beyond what the schema states, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Disconnects from a WiFi ADB connection') and resource ('WiFi ADB connection'), distinguishing it from siblings like 'android.adb.connectWifi' (which connects) and 'android.adb.enableTcpip' (which enables TCP/IP mode). It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool based on the optional 'ipAddress' parameter: use with an IP to disconnect a specific device, omit to disconnect all. However, it does not explicitly state when not to use it (e.g., vs. other disconnection methods) or name alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses implementation behavior (protocol selection based on stream state) which is valuable context. However, it doesn't mention potential side effects, error conditions, or what constitutes a successful swipe operation. The description doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that each earn their place. The first sentence states the core functionality, the second adds important implementation context. No wasted words, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description provides basic operational context but lacks details about coordinate systems, success/failure conditions, and the durationMs parameter. It's minimally adequate but has clear gaps given the tool's complexity and lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description doesn't add any parameter-specific information beyond what's implied by the coordinate names. It mentions coordinates (x1,y1 to x2,y2) but doesn't explain coordinate systems, units, or screen boundaries. The durationMs parameter isn't mentioned at all. The description doesn't sufficiently compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('swipes') with specific coordinates (x1,y1 to x2,y2) and identifies the target resource ('device screen'). It distinguishes from siblings like android.input.tap (single point) and android.input.dragDrop (similar but different interaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by mentioning the implementation details (fast scrcpy control protocol when stream is active, otherwise falls back to adb shell input). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (dumps notifications with specific command), what it returns (detailed notification information including text, package names, and metadata), and a key behavioral constraint (permission requirements on newer Android versions). This covers the essential operational aspects, though it could add more on error handling or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by return details and a critical note. Every sentence adds value: the first explains the action, the second specifies the output, and the third warns about permissions. There's no wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is partially complete. It covers the tool's purpose, output format, and a key behavioral constraint, but it lacks parameter documentation and doesn't fully address usage context or error scenarios. This leaves gaps that could hinder an agent's ability to use the tool effectively in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. However, the description doesn't mention the 'serial' parameter at all, leaving its purpose and format undocumented. Since schema coverage is low, the baseline expectation is higher, but the description fails to add any parameter-specific meaning, resulting in a minimal score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Dumps all current notifications') and resource ('from device'), using the exact command 'dumpsys notification --noredact'. It distinguishes itself from sibling tools like android.clipboard.get or android.ui.dump by focusing specifically on notification data, not other system information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the permission note ('may require special permissions on Android 10+ devices'), suggesting when this tool might fail. However, it doesn't explicitly state when to use this tool versus alternatives like android.ui.dump or android.vision.snapshot for different types of device information, nor does it provide clear exclusions or prerequisites beyond the permission hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value (true/false) and the underlying method (dumpsys power/display), which adds useful context beyond basic functionality. However, it lacks details on permissions, rate limits, error conditions, or side effects, leaving behavioral gaps for a tool that likely requires device access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose and method, the second specifies the return values. It is front-loaded with the core functionality and efficiently structured, making every sentence earn its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It explains the return values and method, which is helpful, but misses parameter semantics and deeper behavioral context like error handling or prerequisites. For a simple status-check tool, it meets basic needs but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It does not mention the 'serial' parameter at all, failing to explain its purpose or format. However, since there is only one parameter, the baseline is higher, but the description adds no semantic value beyond the schema, resulting in a score just above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Checks if the device screen is currently on'), identifies the resource ('device screen'), and distinguishes it from siblings like android.screen.sleep, android.screen.unlock, and android.screen.wake by focusing on status checking rather than state manipulation. The verb 'checks' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for determining screen state, but provides no explicit guidance on when to use this tool versus alternatives like android.screen.wake or android.screen.sleep. It mentions the method ('using dumpsys power/display'), which gives some context, but lacks clear when/when-not instructions or named alternatives for related scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only partially discloses behavior. It states the return format ('Returns image/png') but lacks critical details like whether this requires device permissions, if it works on locked screens, potential rate limits, or error conditions. For a tool that interacts with hardware, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded with all three sentences earning their place: first states the core functionality, second clarifies implementation advantages, third specifies return format. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema coverage, the description is minimally adequate. It covers purpose, implementation distinction, and return format, but lacks behavioral details (permissions, errors) and parameter explanations that would make it complete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter 'serial', but the description doesn't explicitly explain what 'serial' means. However, given there's only one parameter and the tool's purpose is clear from context (device screenshot), the description adequately compensates by implying device identification is needed. A perfect score is withheld since parameter meaning isn't directly addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a snapshot screenshot'), resource ('from a device'), format ('PNG'), and implementation method ('Uses adb exec-out screencap -p'), distinguishing it from sibling tools like android.vision.startStream (streaming) or android.ui.dump (UI hierarchy).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning it 'Works without scrcpy/ffmpeg', which implies when to use this simpler method versus alternatives requiring those dependencies. However, it doesn't explicitly state when NOT to use it or name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns about the tool's potential to 'modify device storage' (indicating a destructive operation) and mentions permission requirements, which are crucial for safe usage. It does not cover all behavioral aspects like error handling or performance limits, but it provides significant context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear warning and purpose, followed by essential usage notes in three concise sentences. Every sentence adds value—warning about risks, stating the action, and specifying prerequisites—with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a file transfer operation with no annotations or output schema), the description is moderately complete. It covers key behavioral risks and usage constraints but lacks details on error responses, success indicators, or specific permission types. For a mutation tool with 3 parameters and 0% schema coverage, more comprehensive guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds meaning by explaining that 'localPath must exist' and 'remotePath must be writable', which clarifies constraints for two of the three parameters (localPath and remotePath). However, it does not address the 'serial' parameter or provide full details on path formats, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Transfers a local file to the device filesystem') and resource ('using adb push'), distinguishing it from sibling tools like android.file.pull (which pulls files) and android.file.list (which lists files). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by specifying prerequisites ('Ensure paths are correct and you have proper permissions') and constraints ('Local path must exist and remote path must be writable'). However, it does not explicitly mention when not to use it or name alternatives like android.file.pull for reverse operations, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively by disclosing key behavioral traits: it describes performance differences (instant vs. slower), encoding issues (spaces as %s), and dependency on stream state. However, it does not cover aspects like error handling or permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Types text') and efficiently explains the behavioral context in one sentence. Every part adds value, with no wasted words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool with two parameters, no annotations, and no output schema), the description is somewhat complete by covering behavior and usage context. However, it lacks details on parameter semantics, error cases, or return values, which are important for full understanding in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate, but it does not explicitly explain the parameters (serial and text). It implies 'text' is the input to type and 'serial' relates to the device, but no details on formats or constraints are provided. This adds minimal value beyond the schema's basic structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Types text') and resource ('on the device'), distinguishing it from sibling tools like android.input.keyevent (for key events) or android.input.tap (for taps). It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it by explaining the fallback mechanism (fast scrcpy when stream active, slower adb otherwise), but it does not explicitly state when not to use it or name alternatives among siblings (e.g., android.input.keyevent for non-text input). This gives good guidance but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action (wakes screen using specific keycode) and conditionality (only if screen is off), but doesn't mention permissions needed, potential side effects, error conditions, or what happens if the device is locked. It provides basic behavioral context but lacks comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: first states the action and mechanism, second provides the conditional behavior. No wasted words, front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple single-parameter input schema, the description provides adequate but minimal context. It explains what the tool does and when it applies, but doesn't address return values, error handling, or the broader Android device management context. For a screen control tool with no structured metadata, more behavioral details would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no parameter information. However, with only 1 parameter and clear tool purpose, the agent can reasonably infer the 'serial' parameter identifies the target Android device. The description doesn't add parameter semantics, but the simplicity of the single parameter keeps this from being a critical deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Wakes the device screen') and mechanism ('using KEYCODE_WAKEUP (224)'), distinguishing it from sibling tools like android.screen.sleep (which puts screen to sleep) and android.screen.isOn (which checks screen status). It provides a precise verb+resource+method combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Turns on the screen if it's currently off'), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage when the screen is off, but doesn't address scenarios like screen already being on or other wake methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes what the tool returns ('package name and activity name') and its read-only nature is implied by 'retrieves.' However, it doesn't mention potential limitations like requiring ADB debugging to be enabled, device connectivity requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: the first states the core function, the second provides usage context, and the third specifies the return values. It's front-loaded with the main purpose and contains zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides good coverage of purpose, usage, and return values. It adequately explains what the tool does and what information it provides. The main gap is the lack of explicit parameter explanation, but the simplicity of the tool makes this less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. While it doesn't explicitly mention the 'serial' parameter, the description implies device-specific operation through context ('foreground activity'), and having only one parameter makes the tool straightforward. The description adds value by explaining what information is retrieved, though it could better explain the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('retrieves') and resource ('currently focused/resumed activity and package name'), making the purpose explicit. It distinguishes this tool from siblings by focusing on foreground activity detection rather than device management, app control, or UI interaction tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('useful for determining which app is in the foreground'), which implicitly distinguishes it from sibling tools that perform different functions like file operations or input simulation. However, it doesn't explicitly mention when not to use it or name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return behavior ('Returns the IP address or null if device is not connected to WiFi'), which is crucial for understanding outcomes. It doesn't mention error conditions, permissions, or rate limits, but covers the core behavioral trait of possible null returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by usage context and return behavior. Every sentence adds value without redundancy, and it's appropriately sized for a simple tool with one parameter and straightforward functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete: it states the purpose, usage context, and return behavior. It could mention error cases or prerequisites more explicitly, but for a simple read operation, it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no additional information about the 'serial' parameter's meaning or format. However, since there's only one parameter and it's likely a device identifier, the baseline is 3 as the description doesn't compensate for the schema gap but the simplicity mitigates the impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Gets'), the resource ('device's WiFi IP address'), and distinguishes it from siblings by focusing on IP retrieval rather than connection management (connectWifi/disconnectWifi) or TCP/IP mode enabling (enableTcpip). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Useful for connecting to the device wirelessly after enabling TCP/IP mode'), which implicitly suggests it should follow android.adb.enableTcpip. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, though the context makes its role evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: the technical method ('using dumpsys clipboard'), platform limitations ('limitations on Android 10+'), and edge case handling ('Returns empty string if clipboard is empty'). It doesn't mention error conditions or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first clause, followed by important technical notes. Every sentence earns its place by adding critical information about limitations and return behavior without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description provides good completeness: it explains what the tool does, technical implementation details, platform limitations, and return value behavior. It could benefit from mentioning error cases or the format of returned content beyond 'empty string'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single 'serial' parameter, and the tool description provides no information about what 'serial' represents or how to obtain it. The description adds no parameter semantics beyond what the bare schema provides, but with only one parameter, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves') and resource ('current clipboard content'), and distinguishes it from its sibling 'android.clipboard.set' by focusing on getting rather than setting content. It provides precise technical context with 'using dumpsys clipboard'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('Retrieves the current clipboard content') and includes important limitations ('May have limitations on Android 10+ due to privacy restrictions'), but doesn't explicitly mention when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it describes the two execution modes (scrcpy vs adb), their performance characteristics (~5ms vs ~100-300ms), and the condition for mode selection (stream active vs not). It doesn't cover error handling or side effects, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and efficiently adds critical performance details in two sentences. Every sentence earns its place by providing essential operational context without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with 0% schema coverage, the description does well by covering execution behavior and performance. It lacks details on parameter semantics (especially 'serial'), error cases, or return values, but is reasonably complete for a straightforward input tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions coordinates (x,y) but doesn't explain the 'serial' parameter or provide details like coordinate system origin, units, or valid ranges beyond the schema's minimum. It adds some meaning for x and y but leaves 'serial' unexplained, resulting in partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Taps') and target ('at coordinates (x,y) on the device screen'), distinguishing it from sibling tools like android.input.swipe or android.input.longPress. It precisely identifies the verb and resource without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about performance differences based on stream state (fast scrcpy vs slower adb fallback), which implicitly guides when to use it for optimal latency. However, it doesn't explicitly state when to choose this over alternatives like android.input.longPress or android.input.dragDrop, nor does it mention prerequisites like device connectivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output format ('Returns XML with all visible elements, their bounds [left,top][right,bottom], text, resource-id, content-desc, and class'), which is useful context beyond basic functionality. However, it lacks details on potential side effects, performance implications, or error conditions, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core functionality in the first sentence, followed by output details and usage context. Every sentence adds value without redundancy, making it appropriately sized and efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (dumping UI hierarchy), no annotations, no output schema, and low schema coverage, the description does well by explaining the output format and use case. However, it could improve by mentioning prerequisites (e.g., device connectivity) or limitations (e.g., only visible elements), keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'serial' undocumented. The description does not mention parameters at all, so it adds no semantic information beyond the schema. However, with only one parameter, the baseline is 4, as the agent can infer 'serial' refers to a device identifier from context, and the lack of param details is less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Dumps the current UI hierarchy using uiautomator') and resource ('UI hierarchy'), distinguishing it from sibling tools like android.ui.findElement (which finds specific elements) or android.vision.snapshot (which captures visual data). It provides a precise verb+resource combination that is not tautological with the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit context for when to use this tool ('Useful for finding tap targets'), which helps differentiate it from alternatives like android.ui.findElement (for locating specific elements) or android.vision.snapshot (for visual analysis). However, it does not explicitly state when NOT to use it or name specific alternatives, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses the dual protocol implementation (fast scrcpy when stream active, adb shell otherwise), which affects performance and availability. However, it doesn't mention error conditions, permissions needed, or what happens if the device is locked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose and implementation details, the second provides critical parameter guidance with examples. Every element serves a clear purpose, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description is quite complete: it explains the action, implementation behavior, and provides parameter examples. The main gap is lack of explicit error handling or success indication, but it covers most essential context given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description compensates fully by explaining the 'keycode' parameter with concrete examples (HOME=3, BACK=4, etc.), providing essential semantic meaning beyond the bare integer type in the schema. The 'serial' parameter's device identification purpose is implied by context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Sends a keycode event') and resource ('on the device'), distinguishing it from sibling input tools like android.input.tap or android.input.text. It precisely defines the tool's function without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning fallback protocols (fast scrcpy vs adb shell), but doesn't explicitly state when to use this tool versus alternatives like android.input.tap for touch events or android.input.text for text input. No clear exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this uses single-finger swipe simulation rather than true multi-touch, which is important behavioral context. However, it doesn't mention potential side effects, error conditions, or what happens if parameters are invalid, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first states the purpose, second explains implementation limitations, third defines parameter semantics. Every sentence earns its place with no wasted words, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations and no output schema, the description does well by explaining key parameter semantics and behavioral constraints. However, it doesn't describe what happens on success/failure or potential side effects, leaving some completeness gaps for a tool that modifies device state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description compensates excellently by explaining the semantic meaning of startDistance and endDistance for pinch in/out operations. It clarifies that centerX/centerY define the center point and implies serial identifies the device, adding crucial context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a pinch gesture for zooming in/out, specifying it uses a single-finger swipe simulation. It distinguishes from siblings like android.input.swipe by focusing on pinch functionality and mentions limitations compared to true multi-touch, providing specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (simulating pinch gestures) and mentions limitations (single-finger simulation vs. true multi-touch). However, it doesn't explicitly state when not to use it or name specific alternatives among siblings, though the context implies it's for zoom operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool establishes a WiFi connection, requires TCP/IP mode enabled beforehand (implying a dependency), uses a default port of 5555, and needs the device's IP address. However, it doesn't mention potential errors (e.g., if connection fails) or side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisites and usage notes in three concise sentences. Every sentence adds value: the first states the action, the second specifies prerequisites, and the third provides practical guidance. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well for a connection tool with 2 parameters. It covers purpose, prerequisites, and basic usage, but lacks details on return values (e.g., success/failure status) or error handling. For a tool that establishes a network connection, this is a minor gap, but overall it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (ipAddress and port) well-documented in the schema. The description adds minimal value beyond the schema: it mentions the default port is 5555 (already in the schema) and implies ipAddress is required (already in required array). No additional syntax or format details are provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (connect to device over WiFi using ADB) and resource (Android device), distinguishing it from siblings like android.adb.enableTcpip (which enables TCP/IP mode) and android.adb.disconnectWifi (which disconnects). The verb 'connects' is precise and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to connect over WiFi) and provides clear prerequisites: the device must already have TCP/IP mode enabled, requiring use of android.adb.enableTcpip first while connected via USB. It also references android.adb.getDeviceIp as an alternative for obtaining the IP address, offering complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the prerequisite (USB connection required), the default port setting, the post-enablement workflow (getting IP and connecting wirelessly), and the ability to disconnect USB afterward. It doesn't mention error conditions or permissions, but covers the essential operational context well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: it starts with the core purpose, then lists prerequisites, default values, and follow-up steps in a logical flow. Every sentence adds essential information without redundancy, making it easy to understand the tool's role in the debugging workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a device configuration tool with prerequisites and follow-up steps), no annotations, and no output schema, the description does an excellent job of providing complete operational context. It explains the entire workflow from USB connection to wireless debugging. A perfect 5 would require mentioning potential errors or security considerations, but this is very comprehensive for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal parameter semantics beyond the schema (mentioning 'Default port is 5555' which is also in the schema). It doesn't provide additional context about parameter usage or implications, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Enables TCP/IP mode') on a specific resource ('device for WiFi debugging'), distinguishing it from sibling tools like android.adb.connectWifi (which connects after enabling) and android.adb.getDeviceIp (which gets the IP address). It provides a complete picture of the tool's function beyond just the name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Device must be connected via USB first') and provides clear alternatives for subsequent steps ('use android.adb.getDeviceIp to get the device's IP address, then use android.adb.connectWifi to connect wirelessly'). It also mentions the prerequisite condition and the workflow context effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns about reliability issues ('may not work reliably across all Android versions') and security restrictions ('restricted on most Android devices due to security policies'), which are crucial for understanding the tool's behavior. However, it doesn't specify error handling or response formats, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each serve a distinct purpose: stating the action, warning about limitations, and suggesting an alternative. It's front-loaded with the core functionality and wastes no words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an Android ADB tool with no annotations and no output schema, the description does a good job covering key aspects like purpose, usage guidelines, and behavioral warnings. However, it lacks details on error cases or what happens on success, which would be helpful for a tool with potential reliability issues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. While it doesn't explicitly explain the 'serial' and 'text' parameters, the context of 'via ADB' implies 'serial' refers to a device identifier, and 'set clipboard content' implies 'text' is the content to set. This adds some meaning, but doesn't fully document the parameters, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('set clipboard content') and resource ('via ADB'), distinguishing it from its sibling 'android.clipboard.get' which retrieves clipboard content. It goes beyond just restating the name/title by specifying the method (ADB).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for setting clipboard content via ADB) and when not to use it (due to restrictions on most Android devices). It also offers a clear alternative ('Consider using UI automation to paste text instead as a fallback'), which helps differentiate it from other input-related tools like 'android.input.text'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it warns of high risk ('extreme caution'), describes the action's scope ('can perform any operation on the device'), and specifies the return values ('stdout, stderr, and exit code'). It lacks details on permissions or rate limits, but covers essential safety and output information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a warning, followed by clear statements on capability and returns, all in three concise sentences with zero wasted words. Each sentence adds critical information (risk, scope, output), making it efficiently structured and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (arbitrary execution), no annotations, and no output schema, the description is largely complete: it covers purpose, risk, and return values. However, it lacks details on error handling or specific prerequisites (e.g., device connectivity), leaving minor gaps in context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain the parameters 'serial' or 'command' beyond what the schema's property names imply. The description adds no meaning to the parameters, such as clarifying 'serial' refers to device identifier or 'command' format, leaving them undocumented. Baseline 3 is given as it partially compensates by implying command execution context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'executes' and the resource 'shell command on device', clearly distinguishing it from sibling tools like android.file.pull or android.input.tap by focusing on arbitrary command execution via adb shell. It specifies the action and target without redundancy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Use with extreme caution', indicating high-risk scenarios, and implicitly suggests alternatives by noting it 'can perform any operation', implying more specific tools (e.g., android.file.push for file operations) should be preferred when available. It clearly defines when to use (arbitrary commands) and warns against misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the two-step behavior (wakes screen first, then attempts unlock), the methods used (KEYCODE_MENU or swipe gesture), and critical constraints (only works on non-secure devices). However, it doesn't mention error handling, timeout behavior, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by implementation details and critical warnings. Every sentence adds essential information with zero wasted words, making it highly efficient and well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and minimal parameters, the description provides excellent context about behavior, constraints, and usage boundaries. The only minor gap is the lack of information about return values or error responses, but given the tool's straightforward nature and clear success/failure conditions described, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. While it doesn't explicitly explain the 'serial' parameter, the context of 'device' in the description implies this identifies the target Android device. Given only one parameter and clear tool context, this provides adequate semantic understanding despite not naming the parameter directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('unlocks the device screen') and distinguishes it from siblings like android.screen.wake (wakes only) and android.screen.sleep (puts to sleep). It explicitly mentions the two-step process of waking then unlocking, making the purpose distinct and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Only works for devices without secure lock') and when not to use it ('Devices with secure locks cannot be unlocked via ADB for security reasons'). It clearly defines the specific use case versus alternatives like manual unlocking or other ADB commands for secured devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-scrcpy-vision MCP server](https://glama.ai/mcp/servers/invidtiv/mcp-scrcpy-vision/badges/card.svg)](https://glama.ai/mcp/servers/invidtiv/mcp-scrcpy-vision)

Score Badge

Copy to your README.md:

[![mcp-scrcpy-vision MCP server](https://glama.ai/mcp/servers/invidtiv/mcp-scrcpy-vision/badges/score.svg)](https://glama.ai/mcp/servers/invidtiv/mcp-scrcpy-vision)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/invidtiv/mcp-scrcpy-vision'

If you have feedback or need assistance with the MCP directory API, please join our Discord server