scrcpy-mcp

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools have clearly distinct purposes (tap vs swipe vs long_press vs drag_drop), and the session-dependent note for several is helpful. Minor overlap exists between ui_find_element, ui_tap_element, ui_get_state, and ui_wait_for_element, which all touch UI exploration, but their actions differ enough to distinguish. These UI tools could occasionally be confused by an agent.
Naming Consistency4/5
Naming follows a good snake_case verb_noun pattern throughout (screen_on, app_start, file_push). Minor inconsistencies exist: some tools use device_*, some screen_*, some app_*, and UI tools mix ui_* with standalone form_fill and scroll_to_element. Most follow convention but the ui helper tools break the pattern slightly.
Tool Count3/5
46 tools is heavy, near the upper boundary of reasonable. The count is justified for the breadth of the domain (device control, UI automation, file management, video streaming, session management), but several tools overlap functionally (ui_find_element and ui_get_state, or app_list vs file_list) suggesting consolidation could reduce the count. It's not chaotic, but it's more than strictly necessary.
Completeness5/5
The surface is remarkably complete for an Android automation server: device control, input gestures, UI interaction, app lifecycle (start/stop/install/uninstall/list), clipboard, files, screen capture/record/video streaming, and a shell_exec escape hatch solves any gaps. No obvious dead-end operations exist, and fallback behaviors are described for tools requiring a session.
Average 3.6/5 across 46 of 46 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Force-stop' which implies killing the app process. Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, which cover the main behavioral profile. The description adds the force-stop nature but doesn't disclose whether data is lost, whether the app restarts, or effects on background processes. With annotations present, the description carries moderate but acceptable burden.
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?
A single efficient sentence that states exactly what the tool does. No wasted words, front-loaded with the action. Appropriate for a simple tool.
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?
The tool is simple (2 params, 1 required, no nesting), has an output schema, and full annotation coverage. The one-liner is arguably sufficient for this complexity level. However, it could mention that serial is optional (defaulting to the primary device) and clarify force-stop semantics versus normal stop. The description is minimally adequate.
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% — both parameters (serial, packageName) are documented in the schema itself. The description adds no additional parameter meaning beyond 'force-stop' framing. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource ('Force-stop an app on the device'), which is clear. However, it doesn't differentiate from siblings like app_start or app_uninstall beyond the obvious inverse relationship. It's a clear single-line description but lacks scoping detail.
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 vs alternatives. Nothing mentions that force-stop terminates processes without uninstalling (vs app_uninstall), or that it's for halting a misbehaving app. The openWorldHint=true suggests it may work on unknown devices, but no context for appropriate use cases is given.
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?
Annotations declare destructiveHint=true and readOnlyHint=false, which is acknowledged by the description implying a write operation to the host machine. However, the description doesn't disclose what happens on failure (partial file?), whether it overwrites existing local files, permission requirements for reading the remote path, or whether directories need to exist. With only a one-line description and no additional behavioral context, this is thin coverage.
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?
A single efficient sentence that communicates the essential purpose. It's appropriately brief with zero wasted words. Could potentially be slightly more verbose to add usage guidance, but as written it's clean and front-loaded with the main purpose.
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 there's an output schema and full schema parameter coverage, the description is somewhat adequate for a simple file-transfer tool. However, given the destructiveHint annotation, some guidance on overwrite semantics for localPath would strengthen completeness. For a straightforward operation with good schema support, this is a minimally acceptable level of description.
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 all three parameters are documented in the schema itself. The description doesn't add parameter-specific details beyond naming the source and destination. The baseline of 3 is appropriate since the schema carries the parameter documentation burden and does so adequately.
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 (pull) and resource (file from device to host machine), which is a specific, unambiguous purpose. It distinguishes from siblings like file_push and file_list, though it doesn't name them explicitly. The direction of transfer (device→host) is clearly stated, which is the key differentiator from file_push.
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 like file_push or file_list. It doesn't mention prerequisites (e.g., device connected), when it's appropriate to use, or situations where it would fail. No exclusions or context about use cases is 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?
No annotations contradict the description, and annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive action. However, the description adds no behavioral detail beyond what annotations provide—no mention of effects on running apps, whether the screen can be turned back on, or device state implications.
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?
A single sentence, zero waste, appropriately sized for a simple tool action. Nothing extraneous.
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?
This is a very simple tool with one optional parameter, an output schema, and annotations covering the safety profile. For such a low-complexity tool, the description is minimally adequate. However, it doesn't mention what the output/return indicates (success/failure) or any failure conditions, though the output schema may cover this.
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 the single 'serial' parameter documented as 'Device serial number'. The description adds no further meaning beyond the schema. Baseline 3 is appropriate when the schema fully documents parameters and there's only one simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Turn the device screen off' has a clear verb+resource and states the action. However, it doesn't distinguish from the sibling tool screen_on beyond the obvious inverse relationship, and there's no detail about what state transitions occur.
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 vs alternatives. It doesn't say whether screen_on should be used for the reverse, whether there are prerequisites (e.g., screen must be on), or any conditions where this would fail. The sibling screen_on exists but no cross-reference is made.
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?
Annotations say idempotentHint=true, indicating stopping a non-existent recording is safe, and destructiveHint=false. The description confirms the read/pull behavior but adds little beyond annotations. There's no contradiction. The annotation set already covers safety profile; the description adds the 'pull file' behavior context.
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?
One concise sentence, front-loaded with the main action, and captures the key optional behavior. No wasted words. Slightly more detail on usage context could help, but the length is appropriate.
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?
Has an output schema which partially reduces the need to describe return values. However, for a stop/cleanup operation, it would help to mention whether stopping implies a timeout, what happens if no recording is active (idempotent per annotations), and any interaction with the host pull in case of failure. Adequate but with room to enrich.
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 parameters are well-documented in the schema itself. The description adds minimal value — it mentions 'pull the file to the host' which maps to pullToHost, but doesn't expand beyond the schema's parameter descriptions. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Stop screen recording and optionally pull the file to the host.' It distinguishes from screen_record_start, though there's also stop_video_stream in the sibling set which could create ambiguity — the description doesn't clarify the distinction between stopping a screen recording vs. stopping a video stream.
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 it's the end-phase companion to screen_record_start, and mentions the optional pull-to-host behavior. However, it doesn't explicitly say when to use it (only after screen_record_start), doesn't specify prerequisites, and doesn't clarify the screen_record_stop vs stop_video_stream distinction.
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?
Annotations provide readOnlyHint=false and destructiveHint=false, which partially describe the safety profile. The description adds nothing beyond the single gesture statement. It doesn't disclose what happens on a swiped element (scroll vs. navigation), duration semantics, or whether coordinates are absolute screen coordinates. With annotations covering basic safety, the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the core function with zero filler words. It's efficient and front-loaded with the key action. However, for a tool with 6 parameters and multiple gesture siblings, the brevity borders on under-specification.
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?
With an output schema present and 100% schema coverage, the tool relies on structured data for parameters. However, the ambiguous boundary between swipe, drag_drop, and scroll is not addressed, and there's no guidance on coordinate reference frame or device/session prerequisites. For a gesture tool in a broad device-control API, this is incomplete.
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 all 6 parameters (x1,y1,x2,y2,serial,duration) are documented in the schema. The description adds no new parameter information beyond what the schema already conveys. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Perform a swipe gesture from one point to another' clearly states the verb (perform a swipe) and the resource (from one point to another). It distinguishes from siblings like tap, long_press, drag_drop, and scroll reasonably well, though it doesn't sharply differentiate from drag_drop which is a similar gesture-based action.
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?
There is no guidance on when to use swipe vs. alternatives like drag_drop, scroll, or tap. It doesn't mention coordinate system (screen pixels vs. view-relative), prerequisites (device must be on, session active), or inapplicable cases. For a gesture tool with several similar siblings, this is a meaningful gap.
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?
Annotations include idempotentHint=true, which is the opposite of what one might expect for a disconnect (it implies repeated calls are benign). The description doesn't clarify whether disconnecting an already-disconnected device is harmless or errors. With annotations covering idempotency, a partial credit is reasonable, but the description adds nothing beyond the annotation layer.
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 appropriately concise — a single clear sentence that states the purpose without waste. It's front-loaded and efficient, though it could have used the space to add a usage note.
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?
With one simple parameter (100% schema coverage) and annotations covering idempotency and non-destructiveness, the description is mostly adequate. However, it lacks behavioral details like whether the connection is confirmed, error handling behavior, and whether it's tied to session state. For a simple disconnection tool, this is minimal viable but not rich.
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% — the address parameter is fully documented in the schema with an example format (e.g., 192.168.1.100:5555). The description adds nothing beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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+resource: 'Disconnect from a wireless ADB device'. It's specific and unambiguous about what the tool does. However, it doesn't explicitly differentiate from siblings like connect_wifi, though the pairing is fairly self-evident given the names.
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 explain that this pairs with connect_wifi, doesn't mention whether this is needed before ending a session, and gives no context about prerequisites (e.g., must be connected first) or error states.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is fully covered. The description adds minimal behavioral context beyond the annotation. It doesn't mention whether hidden files are shown, sorting behavior, or output format details, but with the readOnlyHint annotation covering the main safety profile, a baseline 3 is appropriate.
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 a single concise sentence with no wasted words. It's appropriately front-loaded with the primary action. Could be slightly more informative but achieves efficiency as-is.
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 simplicity of the tool (list directory, 2 params, fully covered schema, readOnlyHint annotation, and an output schema provided), the description is essentially adequate. The output schema exists so return values don't need describing. Some mention of absolute-path requirements or error conditions (e.g., non-existent path) could improve completeness, but the tool's low complexity keeps requirements modest.
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% as both parameters (path, serial) have descriptions. The path parameter is described with an example value (/sdcard/), which adds useful context. The description itself doesn't add meaning beyond what the schema provides, so baseline 3 is appropriate.
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 states the verb (list) and resource (directory contents) clearly. It distinguishes from file_push/file_pull siblings since it's a read-only listing operation. However, it's somewhat short and doesn't explicitly contrast with sibling tools like device_list or app_list, so sibling differentiation is partial.
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 when-to-use or when-not-to-use guidance is provided. It doesn't mention alternatives like shell_exec for more advanced file operations, file_push/file_pull for file transfers, or app_list for application files. The description provides no context for choosing this tool over related ones.
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?
Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation aspect is already covered. The description adds that it supports string or numeric keycodes, which is useful beyond the schema. However, it doesn't disclose behavioral details like whether the event waits for device responsiveness, whether unsupported keycodes produce errors, or interaction with the open-worldHint (e.g., custom keycodes).
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?
Single sentence that is efficient and front-loaded with the primary action. The example keycodes add practical value without bloat. Could arguably be slightly richer, but is appropriately concise for its purpose.
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?
Complexity is low-moderate (3 params, none required). The description covers the essential purpose and key examples. With an output schema present, return-value explanation isn't needed. However, given the volume of sibling input tools (tap, swipe, type_text, long_press), a single sentence is arguably thin for disambiguation, and it doesn't address the key-vs-keycode alias ambiguity.
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 all 3 parameters (key, serial, keycode). The description adds examples of valid key values but doesn't explain the relationship between 'key' and 'keycode' aliases or clarify whether both can be provided simultaneously. Baseline 3 is appropriate given full schema coverage.
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 it sends a key event to the device, with a specific verb+resource. It provides concrete examples of keycodes (HOME, BACK, ENTER, VOLUME_UP) that clarify what kinds of keys are supported. It doesn't fully distinguish from siblings like tap, swipe, or input_text, but the keycode-based nature is implied clearly enough.
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 vs alternatives like tap, input_text, or app controls. The description doesn't say 'for physical/navigation keys' or contrast with other input methods. Usage context is only implied by the examples given, with no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds nothing about behavioral traits beyond what annotations state - it doesn't mention what physical effect occurs (e.g., potentially triggering long-press actions, haptic feedback, or context menus). While no contradiction exists, the description contributes minimal behavioral context beyond the structured hints. There's also no mention of the device 'serial' parameter requirement or what happens without it.
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 a single, efficient sentence with zero waste. It's appropriately sized for a simple action tool. The only minor weakness is that it could mention the duration parameter implications, but for a tool of this simplicity, the brevity is well-earned.
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?
An output schema exists, so return values are presumably documented. However, for a physical action tool with openWorldHint=true and no safety annotations for a non-readOnly action, the description doesn't explain prerequisites (e.g., screen must be on, device must be connected) or the coordinate system (screen vs view-relative). Given the tool's simplicity and the output schema presence, this is somewhat adequate but leaves gaps around preconditions.
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 all 4 parameters (x, y, serial, duration) have descriptions in the schema. The duration parameter has a clear default (500ms) and semantics in the schema. The description itself adds no additional meaning beyond what the schema provides. Per guidance, with high coverage, baseline 3 is appropriate since the description doesn't compensate with extra context like coordinate format or coordinate-space reference.
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 'Perform a long press at the specified coordinates' uses a specific verb (perform long press) with a clear resource (specified coordinates). It clearly differentiates from siblings like 'tap' (single tap) and 'swipe'/'drag_drop' (motion actions). However, it doesn't explicitly name the distinguishing sibling alternative, and the purpose is clear but could be more explicit about what a long press is for (e.g., context menus).
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 like 'tap' or 'ui_tap_element'. The description gives no context about use cases (e.g., long-press to reveal context menus) or exclusion criteria (e.g., when a simple tap suffices). This is a pure action tool with zero usage context 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?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description doesn't contradict these and is consistent with an install operation (which modifies device state but is not destructive). However, the description doesn't disclose behavioral traits beyond annotations — no mention of what happens to an existing app with the same package name (upgrade vs failure), whether installation requires specific permission, or response format.
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?
A single, direct sentence that states the action and source/destination context. No wasted words, no redundancy with the title or schema. Efficient 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 tool with an output schema, annotations, and 100% parameter coverage, the description is arguably sufficient at the minimum level. However, it lacks context about session requirements (does an active session need to exist?), behavior on conflicting installs, or the relationship to app_uninstall/app_list for managing installed apps. Given the tool's simplicity, a 3 is appropriate.
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 both parameters (serial, apkPath) are documented in the schema. The description clarifies that apkPath refers to a path on the host machine, which adds context beyond the schema. However, this is a baseline case where the schema does the heavy lifting; the description doesn't add format validation or usage nuances for either 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 (Install), resource (APK file), destination (device), and source (host machine). It's distinct from siblings like app_start, app_stop, and app_uninstall. However, it doesn't explicitly contrast with siblings, so it's clear but not fully differentiating.
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?
There's no guidance on when to use this tool versus app_start, app_uninstall, or file_push. The description doesn't mention that the APK must be a path on the host machine (which is a key distinction from file_push) or any prerequisites like having an active session. No when/when-not guidance is 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?
No annotations are present to declare read-only or destructive behavior, so the description carries the disclosure burden. It does disclose the implementation fallback (swipe on older versions), which is valuable. However, it doesn't mention whether the input draganddrop interface requires a debug shell or if there are side effects like triggering long-press behavior.
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 two sentences, compact and front-loaded with the core purpose. It adds the platform-specific implementation detail efficiently without waste.
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?
The tool has a well-documented schema (100% coverage) and an output schema, but the description is minimal for a gesture tool with a platform fallback. Given the sibling 'swipe' tool, more guidance on when drag_drop is preferable and the behavioral caveat of the fallback would improve completeness.
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 all parameters documented in the schema. The description adds the duration parameter's meaning implicitly (gesture speed) but doesn't add details beyond what the schema provides. Baseline 3 is appropriate when schema covers all 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 tool performs a drag and drop gesture between two points, with a specific verb and resource. However, it doesn't explicitly distinguish this from sibling tools like 'swipe' or 'scroll' beyond the implementation detail. The title 'Drag and Drop' reinforces the purpose.
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 mentions the platform version distinction (Android 8.0+ uses input draganddrop, older versions fall back to swipe), which gives some usage context. However, it doesn't explicitly say when to use this vs the 'swipe' sibling tool, nor does it note that on older Android versions the behavior may differ from a true drag-and-drop gesture.
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?
The description discloses the label-matching heuristic (nearest input field, checkbox/dropdown handling) which is useful behavioral context. However, it doesn't describe failure modes (what happens when a label isn't found, partial fill behavior), and given readOnlyHint=false and no destructiveHint, the mutation behavior is only implied rather than stated. Schema coverage is complete but behavioral risks like non-reversibility aren't addressed.
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?
Three sentences, tightly written, front-loaded with the core purpose. The first sentence states the action, the second explains the mechanism, the third notes special field handling. No wasted words or redundancy. Slightly more could be said about failure behavior, but structurally this is efficient.
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 openWorldHint=true, the description should disclose more about what's NOT guaranteed. It explains the mechanism reliably but omits behavior under edge cases (unfindable labels, unsupported field types, empty values, behavior on submission). No output schema details are needed since one exists, but the description could state that partial fills may occur silently.
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 all three per-field parameters and the serial field are documented in the schema. The description adds value by explaining the 'type' semantics (text/checkbox/dropdown handling via label matching) rather than just listing them, but the description doesn't elaborate on 'serial' beyond schema. Baseline 3 is appropriate when schema covers all 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 uses a specific verb+resource ('Fill a multi-field form') and clearly explains the mechanism (array of label/value pairs, finds nearest input, taps, types). It distinguishes from siblings like input_text (single field) and ui_smart_fill by describing the batch multi-field behavior, though it doesn't explicitly name an alternative.
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 (batch form filling with label-based field matching) but provides no explicit when-to-use vs alternatives, no exclusions, and no guidance on when this would fail (e.g., ambiguous labels, missing serial requirement). No mention of when to prefer ui_smart_fill or input_text.
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?
Annotations provide readOnlyHint=false (correctly implying mutation of viewport state) and openWorldHint=true. The description adds value by disclosing the search strategy (by text, swipes, timeout-bounded). However, it doesn't specify default timeout duration, what happens when text is not found, or whether the element must be visible vs merely present in hierarchy — gaps an agent would want to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then the search strategy detail. Efficient and no wasted words. Minor point: could list the timeout default, but overall the structure is clean and scannable.
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 there's an output schema (not shown in detail) and 100% param coverage, the description is reasonably complete for a scroll-to-element tool. However, for a tool that mutates viewport state, it doesn't clarify behavior when the element cannot be found (does it error? return null?), nor does it mention interaction with the device connectivity context (serial param). Adequate but not thorough.
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%, covering all 4 params (text, serial, direction, maxScrolls). The description adds no parameter-level detail beyond the schema, but the schema already fully documents each parameter's meaning. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds little beyond what's known.
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 states a clear purpose: scroll the page to bring a UI element into view. The verb 'scroll' plus resource 'page' and target 'specific UI element' is specific. It distinguishes from siblings like 'scroll' (which likely handles pure scrolling without element search) and 'ui_find_element' (which finds without scrolling) by combining search-and-scroll behavior.
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 says it 'tries to find the element by text, then swipes up/down until visible or timeout.' This implies usage context (locating an off-screen element) but doesn't explicitly state when to prefer this over alternatives like 'ui_find_element' or 'scroll'. The timeout-bounded behavior is mentioned but no explicit exclusions or alternative recommendations are given.
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?
Annotations provide openWorldHint=true and readOnlyHint=false, but no destructiveHint guidance. The description adds nothing about what happens on tap (e.g., does it trigger a down+up event, does it require display on, any coordinate system caveats). With readOnlyHint=false already signaling mutation, the description misses the opportunity to clarify coordinate origin (top-left?) or require the screen to be on. It's neutral but not contradictory.
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?
One sentence, zero waste. Every word earns its place. This is an appropriately minimal description for a simple coordinate-tap operation.
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?
There's an output schema present, and the parameters are simple coordinates at 100% schema coverage, so the description carries less burden. However, given the tool operates on a physical device screen, it should clarify coordinate origin (top-left corner), whether the screen must be active/on, and how coordinates map to device resolution versus display scaling. These are meaningful gaps for a device-control tool.
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 coverage is 100% and only 2 required params (x, y). The schema already describes 'X coordinate' and 'Y coordinate' clearly. The description adds no parameter detail beyond what the schema provides, but with 100% coverage and simple coordinate params, the description's silence is acceptable. The serial param is undocumented in the description, but it's optional and self-explanatory as a device identifier.
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 'Tap at the specified screen coordinates' clearly states the verb (tap) and resource (screen coordinates). It's straightforward and distinguishes from siblings like swipe, long_press, and drag_drop since 'tap' is specific. However, it doesn't explicitly contrast with similar actions like ui_tap_element (which taps an element rather than coordinates), leaving slight ambiguity about when to use coordinate-based tapping.
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 vs alternatives like ui_tap_element or app interactions. The description doesn't mention that this operates on raw screen coordinates versus on UI elements, nor does it note prerequisites like screen-on state or that coordinates must be within the device display bounds. For a tool with 44 siblings including ui_tap_element, this is a notable gap.
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?
readOnlyHint=true and openWorldHint=true are already declared in annotations. The description adds that the tool 'polls' and has timeout behavior, which is useful. However, it doesn't disclose what happens on timeout (error? returns false?), what 'matches criteria' means in detail, or whether it returns the found element or a boolean. With annotations covering safety (read-only, open-world), the incremental disclosure is moderate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that establishes core behavior (wait, poll, criteria, timeout) without padding. It's appropriately front-loaded with the primary action. Could potentially add a note about return/error behavior without bloating significantly, but current length is reasonable.
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 7-parameter polling tool with no required parameters and an output schema present, the description covers the basic wait-poll-timeout paradigm. However, it lacks clarity on return values (does it return the matched element or a boolean success?), multi-parameter matching semantics (AND/OR), and failure behavior on timeout. The presence of an output schema offsets some of this, but the matching criteria semantics are a genuine gap for a tool with 7 search parameters.
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 all 7 parameters are documented in the schema itself. The description adds minimal value beyond that: it mentions 'polls' and 'criteria' but doesn't explain how the text, className, resourceId, and contentDesc parameters combine (AND vs OR logic), or how exactMatch interacts. Baseline 3 is appropriate given full schema coverage, but the combination semantics are unaddressed.
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 states a clear purpose: 'Wait for a UI element to appear on screen' with a specific verb (wait/poll) and resource (UI element). It distinguishes well from siblings like ui_find_element (which finds without waiting) and wait (a generic sleep). However, it doesn't explicitly distinguish itself from ui_scroll_to_element or other UI-timing tools.
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 synchronization scenarios ('polls until element matches criteria or timeout is reached') but provides no explicit guidance on when to use this vs ui_find_element, wait, or scroll_to_element. No exclusions or alternatives are named. The polling behavior and timeout semantics are stated but the differentiation from siblings relies on the agent making inferential connections.
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?
Annotations already declare destructiveHint=true, so the destructive nature is captured structurally. The description adds no behavioral context beyond what annotations provide — no mention of whether uninstall persists across sessions, requires root/adb permissions, or fails for system apps. With destructiveHint present, the description adds minimal value, though not contradicting anything.
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?
A single, direct sentence that fully conveys the purpose. Zero wasted words. Appropriate for a tool with well-documented schema and annotations.
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 destructive mutation tool with no description beyond one sentence, the description relies heavily on annotations (destructiveHint=true) and 100% schema coverage. There is an output schema present, so return values don't need explanation. However, given it's a destructive action, slightly more context about failure modes (e.g., system apps) would improve completeness.
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 coverage is 100% — both serial and packageName have descriptions in the schema, including a concrete example ('com.example.app'). Description adds no parameter info beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states "Uninstall an app from the device" with a specific verb (uninstall) and resource (app). It's clear and distinguishes from siblings like app_start/app_stop and app_install. However, it doesn't explicitly contrast with app_install which is its direct inverse — though the meaning is obvious enough.
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 doesn't explicitly state when to use this vs alternatives or provide exclusions. Context implies this is for removing an app, and the sibling set makes the purpose reasonably inferable, but no explicit guidance on prerequisites (e.g., app must be installed, permissions needed) is given.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing the Android 10+ requirement for the scrcpy path and the fallback behavior, which is meaningful behavioral context beyond the annotations. However, it doesn't describe the output format or size limitations of clipboard content.
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?
Two sentences, zero waste. Every sentence earns its place: first states the primary purpose, second provides the mechanism and version constraint. Well front-loaded with the core purpose in the opening clause.
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?
With readOnlyHint and openWorldHint annotations, output schema present, and 100% parameter schema coverage, the description is reasonably complete for this tool's complexity. It covers mechanism, fallback behavior, and platform constraints. The only minor gap is not describing the return value format, but the output schema likely covers that.
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% - the single 'serial' parameter is already documented in the schema ('Device serial number'). The description doesn't add any meaning beyond what the schema provides, so the baseline 3 applies. It doesn't clarify whether serial is optional or how it's used to select the device.
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 it gets the current clipboard content from the device using a specific verb ('Get') and resource ('clipboard content'). It distinguishes from its sibling clipboard_set by being the read counterpart, though it doesn't explicitly name the sibling. The mechanism details (scrcpy vs ADB fallback) add useful context.
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 mentions the mechanism details (scrcpy GET_CLIPBOARD when a session is active, ADB fallback) which implicitly signals it's best used with an active session. However, it doesn't explicitly state when to use vs. alternatives, no exclusions, and doesn't mention Android versions where it works on the fallback path. The behavioral context is implied rather than commanded.
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?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the scrcpy session prerequisite, which is useful context beyond what annotations provide. The tool mutates UI state but the description clarifies the action is collapsing (reversible, non-destructive), consistent with the idempotent and non-destructive hints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the purpose and a key prerequisite. It's front-loaded with the primary action and includes the critical scrcpy session requirement efficiently. Minimal waste, though it could arguably structure the prerequisite as a separate clause for clarity.
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 simple UI action tool with good annotations (openWorldHint, idempotentHint), full schema coverage, and an output schema present, the description is reasonably complete. It identifies the target panels and the one critical prerequisite. Given complexity is low and annotations carry significant weight, this is adequate without extensive additional detail.
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 the single 'serial' parameter fully described as 'Device serial number'. The description adds no additional meaning to the parameter beyond what the schema already provides. Since coverage is high, baseline 3 is appropriate per the rubric.
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 tool name 'collapse_panels' combined with the description 'Collapse all open panels (notification, settings)' clearly identifies the verb (collapse) and resource (panels). It distinguishes somewhat from siblings like expand_notifications and expand_settings by specifying it targets both notification and settings panels. However, it doesn't explicitly differentiate from a potential per-panel collapse tool, though none exists among siblings.
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 states '(requires active scrcpy session)', which is an important prerequisite and implies context for when this tool is appropriate. It doesn't explicitly discuss when not to use it or name alternative tools. Setting the collapse action for both notification and settings panels clarifies scope but lacks explicit exclusion guidance.
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?
Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, which describe safety characteristics. The description adds minimal context: it says the tool 'returns the connection address' and mentions it 'Enables WiFi ADB' — implying a state change on the device, which aligns with readOnlyHint=false. No contradiction, but the description doesn't add much beyond what annotations cover regarding side effects on the device's network configuration.
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 a single concise sentence plus a return-value note. It's appropriately brief and front-loaded with the action verb. No wasted words, though it could have been slightly more informative about connection behavior without much cost.
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?
With an output schema present and 100% schema coverage on parameters, the description is reasonably complete for this tool. However, there's no mention of connection timeout behavior, whether the serial defaults to a single device when omitted, or what happens on failure. The tool is relatively simple so this is adequate, but it lacks some behavioral nuance an agent might need (e.g., is serial required if multiple devices are connected?).
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 100%, so both parameters (port and serial) are already documented in the schema with descriptions. The description adds implicit meaning by establishing that connection is established via a TCP port and serial number, reinforcing the schema. Since coverage is complete, the baseline is 3, and the description's mention of 'connection address' subtly clarifies the relationship between port and the resulting connection.
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 states 'Enable WiFi ADB and connect to the device wirelessly' with a specific verb (enable/connect) and resource (WiFi ADB connection). It distinguishes from sibling disconnect_wifi clearly, though it doesn't explicitly contrast to avoid confusion with other connection-related tools.
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?
No explicit when-to-use or when-not-to-use guidance is given. The context implies it's for establishing a wireless ADB connection, but there's no mention of prerequisites (e.g., device must be enabled for wireless debugging) or alternatives. It's clear enough from the name and sibling context (disconnect_wifi) but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=true, idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description's note about requiring an active scrcpy session adds some behavioral context beyond what annotations provide. However, it doesn't add much beyond that — no mention of visual state changes, timing, or interaction with notification panel state. With annotation coverage reasonably good, an average score is fair.
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 a single concise sentence that efficiently conveys the core action and a key prerequisite. No wasted words, though it could capitalize on brevity to add a bit more operational detail without becoming verbose.
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 simple, single-parameter UI action tool with good annotations and full schema coverage, the description is largely sufficient. The tool is simple enough that the one-line description plus annotations cover the use case. Slight room to improve by clarifying the relationship with the notification panel, but this is a minor gap for a low-complexity tool.
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% — the single 'serial' parameter is fully described in the schema. The description adds nothing about the parameter beyond the schema. Per the baseline rule, a 3 is appropriate when the schema already documents all 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 verb (expand) and resource (quick settings panel). It distinguishes from the sibling expand_notifications and collapse_panels by naming the specific panel. The parenthetical noting it requires an active scrcpy session adds useful context, though it doesn't explicitly contrast with the sibling expand_notifications.
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 notes the prerequisite of an active scrcpy session, which gives usage context. However, it does not explicitly say when to use this tool versus expand_notifications or collapse_panels, and sibling alternatives exist that are closely related. The 'requires active scrcpy session' clue implies the start_session prerequisite but doesn't fully spell it out.
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?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the key behavioral detail that recording is a persistent state that continues until screen_record_stop is called, which is genuinely useful beyond the annotations. However, it doesn't disclose the 180s device limit mentioned in the schema, potential storage implications, or what happens to an existing file at remotePath on restart.
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 total, each earning its place. The first states the primary purpose; the second clarifies the persistent nature of recording and its pairing with the stop tool. Zero wasted words, perfectly 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?
The tool has a coupled start/stop interaction requiring the agent to remember both the pairing and the remotePath location for later retrieval. The description adequately signals the pairing but doesn't explain the output schema, the retrieval flow via screen_record_stop, or the 180s duration cap that's buried in the schema comment. Given the output schema exists, not explaining return values is acceptable, but the start/stop workflow could use more scaffolding.
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 fully documents all three parameters (serial, duration, remotePath) with their descriptions and defaults. The description adds minimal value here beyond the schema, but the schema already does the heavy lifting with clear per-parameter documentation, so the baseline 3 applies.
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 (Start) plus resource (recording the screen), and distinguishes it from its obvious sibling screen_record_stop by noting recording continues until the stop counterpart is invoked. It's concise and unambiguous, though it doesn't mention specific output characteristics like the resulting file.
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 the paired start/stop interaction (recording continues until stop is called), giving the agent basic usage context. However, it doesn't explicitly state when to use this versus alternative capture mechanisms like screenshot, nor mention any preconditions such as device connection or permissions that might be required.
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?
The description discloses behavioral traits beyond annotations: the immediate-tap side effect and the nearest-input-field smart matching for labels. However, readOnlyHint=false already signals mutation, so this isn't adding safety-critical info. It doesn't disclose what happens on no-match (error? no-op?), or whether the tap occurs after a wait/scroll. openWorldHint=true suggests dynamic UI but that's already in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with the core verb+resource. Every sentence conveys meaningful info. Could arguably add when-no-match behavior but the current content is efficient. No 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?
There is an output schema present, so return-value explanation isn't required. However, the tool has 8 parameters and behaves on dynamic UI (openWorldHint). The description doesn't address multi-match handling (index parameter semantics beyond schema), timeout/retry behavior, or what happens when no element is found. For a tool that combines find+tap with smart matching, it's adequate but has notable gaps.
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 coverage is 100%, so the schema documents all 8 parameters. The description adds semantic value by explaining the preferInput behavior (nearest input field when targeting a label), which enriches understanding of the preferInput and text parameters beyond their schema descriptions. Good delegation to schema plus contextual highlights.
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 what the tool does: find a UI element by text, resource ID, class name, or content description, and immediately tap it. It also adds a smart behavior (nearest input field for labels). While it distinguishes from ui_find_element (which likely just finds without tapping), it doesn't explicitly name siblings, hence 4 not 5.
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 this is used when you want to find and tap in one step, and the 'nearest input' behavior suggests when targeting labels. However, it doesn't explicitly state when to prefer ui_tap_element over ui_find_element+separate tap, nor when not to use it. Usage context is implied but not articulated with exclusions or alternatives.
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?
Annotations already provide readOnlyHint=true, so the safety profile is covered. The description adds the specific fields returned (model, version, screen size, SDK, battery), which is useful but doesn't disclose potential latency, failure modes with multiple connected devices, or behavior when serial is omitted and no device is connected.
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?
Single sentence, perfectly sized, front-loaded with the action and resource, then specific detail fields. Zero waste.
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?
Tool has one optional parameter fully documented in schema, clear annotations, and an output schema. The description lists the key data returned. It could mention behavior when no device is connected or when multiple devices exist, but for a read-only info tool this is largely sufficient.
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% — the serial parameter is documented as device serial number with the fallback behavior to the only connected device. The description adds no additional parameter semantics beyond what the schema already states. Baseline 3 is appropriate here.
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?
Clear verb+resource: 'Get detailed info about a device' with specific fields listed (model, Android version, screen size, SDK level, battery level). It distinguishes from siblings since no other tool retrieves device metadata, though it doesn't explicitly name an alternative.
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 doesn't explicitly say when to use this tool versus alternatives. However, its read-only information retrieval purpose is implicitly clear given the sibling set (all other tools perform actions or sessions). No exclusion criteria or alternative tools 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?
Annotations provide openWorldHint=true (side effects possible), readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds the prerequisite of active scrcpy session, which is useful context beyond annotations. However, it doesn't disclose what happens if no session is active (error behavior) or what the output represents, given there's an output schema.
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 a single concise sentence with the key prerequisite in parentheses. It's front-loaded and efficient with zero waste. Could arguably add sibling differentiation, but as written it's appropriately tight for a simple action tool.
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?
The tool is simple (1 param, no required params, full schema coverage, output schema present). The description captures the purpose and the key prerequisite (active scrcpy session). For a simple panel-expansion action, the description is complete enough. The only minor gap is not contrasting with expand_settings, but the simple scope makes this sufficient.
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 coverage is 100% with the single 'serial' parameter described as 'Device serial number'. The description doesn't add much beyond the schema, but with full schema coverage and clear output schema, the baseline of 3 applies. The description's mention of 'active scrcpy session' contextually clarifies that serial should reference the session device, adding minor value, warranting a 4.
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 uses a specific verb+resource ('Expand the notification panel'), clearly identifying the action. It distinguishes from its sibling 'expand_settings' which expands a different panel type, though it doesn't explicitly name it. The parenthetical about active scrcpy session adds useful prerequisite context.
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 stating the prerequisite of an active scrcpy session, which guides when it's valid to call. However, it doesn't explicitly state when NOT to use this vs. alternatives like expand_settings or collapse_panels, nor mention that it pairs naturally with collapse_panels for cleanup.
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?
The annotations declare destructiveHint=true, which signals this operation can modify the device filesystem. The description adds the directionality (host to device) and implies file system mutation at a remote path. The description aligns with the annotations — push is a write/destructive operation, consistent with destructiveHint=true. It doesn't add much detail about overwrite behavior or permission requirements, but the annotations carry much of this burden.
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 a single concise sentence that captures the essential operation. It's appropriately front-loaded and has no wasted words. Could arguably add a bit more context about path format requirements, but for its length it's 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?
For a file transfer tool, the description is functional but minimal. It doesn't address potential path format differences, whether relative paths are acceptable, overwrite behavior on the device, or whether the serial parameter is needed for multi-device setups. With an output schema present and 100% parameter coverage, some of this burden is lifted, but the description could add operational context that structured data doesn't capture.
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?
All 3 parameters (serial, localPath, remotePath) have descriptions in the schema (100% coverage), so the schema does the heavy lifting. The description mentions 'host machine' and 'device' which contextualizes localPath vs remotePath semantics. However, it doesn't clarify the serial parameter — whether it's required in multi-device scenarios or optional when only one device is connected.
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 states 'Push a file from the host machine to the device' with a specific verb (push) and direction (host→device), which clearly conveys the core function. It differentiates from the sibling file_pull, though it doesn't explicitly mention that distinction. The title 'Push File to Device' reinforces the purpose.
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 this tool is for file transfer in the host→device direction, which inherently distinguishes it from the sibling file_pull (device→host). However, it doesn't explicitly state when to use it vs alternatives, or mention any prerequisites (e.g., needing an active session via start_session, or the device being accessible via serial). The context of sibling tools suggests session-based operation but this isn't stated.
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?
Annotations declare readOnlyHint=true, which covers the safety profile. The description adds that it returns base64, which is useful output context. However, it doesn't disclose details like whether a screen-on state is required, whether the device must be unlocked, or how large the base64 payload might be. The base64 return disclosure is the main value-add beyond annotations, but richer behavioral context (e.g., required device state) would be more helpful.
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 concise sentences with zero waste. The description clearly communicates the action, the target, and the return format without any padding. Every word earns its place.
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 simple single-parameter read-only tool with full schema coverage and an output schema present, the description is largely complete. It communicates purpose and return format. It could note the required device state (on/unlocked), but given the tool's simplicity, annotations (readOnly) plus good schema coverage make this adequately 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% - the single 'serial' parameter is fully described as the device serial number. The description adds no additional parameter semantics beyond the schema. With full schema coverage, baseline 3 is appropriate; the description doesn't add context like what happens when serial is omitted or whether it's optional for single-device setups.
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 takes a screenshot of the Android device screen and returns base64 image. The verb is specific ('screenshot') and the resource is defined (Android device screen). It doesn't explicitly distinguish from screen_record_start/stop, but 'screenshot' vs 'screen_record' are semantically distinct enough that the name carries the differentiation.
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 you need a static image of the device screen) but provides no explicit guidance on when to use this versus screen_record_start/stop or other alternatives. The sibling set includes screen recording tools, which share visual-capture context, and the description offers no differentiation. However, the distinction between screenshot and video is reasonably understandable from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it opens a viewer window (ffplay) and auto-starts a scrcpy session, which adds useful behavioral context. However, annotations already cover readOnlyHint=false and destructiveHint=false, and the description doesn't mention cleanup behavior, port conflicts, or how the stream is stopped—though the sibling stop_video_stream tool hints at that. The annotation non-read-only nature aligns with starting a stream.
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, zero waste. Every clause adds value: it names the protocol (HTTP MJPEG), the effect (viewer window), and the dependency handling (scrcpy auto-start). Highly concise and front-loaded with the core purpose.
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?
With an output schema present and good annotations, the description carries a reasonable burden. It explains the stream mechanism, the viewer, and dependency behavior. It doesn't mention how to terminate the stream, but the sibling stop_video_stream covers that, and the output schema likely documents the stream URL. This is adequate for a tool of this complexity.
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 both port and serial are already documented in the schema. The description adds minimal value beyond the schema—it doesn't explain what the serial selects or how port interacts with the stream endpoint. Per the baseline rule for >80% coverage, a 3 is appropriate.
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+resource (start an HTTP MJPEG video stream of the device screen) and mentions it opens a viewer window via ffplay. It also notes it starts a scrcpy session if needed. It distinguishes from sibling stop_video_stream and screen_record_start by framing this as a live HTTP MJPEG stream rather than a recording, though it doesn't explicitly contrast with screen_record_start.
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 when to use (viewing live screen remotely via HTTP MJPEG) but doesn't explicitly state when not to use it or give alternatives like screenshot or screen_record_start/stop for capturing frames. The mention of auto-starting scrcpy is a useful context cue, but there's no exclusion or alternative guidance.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that it returns tap coordinates, which is useful behavioral context. However, it doesn't disclose details like whether partial matches are default behavior, how many results are returned, or what happens with multiple matches - though exactMatch parameter partially covers matching 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?
Two tight sentences with zero waste. The first sentence states the purpose and search criteria, the second describes the return value. Every clause carries meaning.
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 that an output schema exists (documenting the return structure) and annotations flag this as read-only/open-world, the description covers the essential aspects: what it finds, how to search, and what it returns. The tool is relatively simple with good schema coverage, so the description is adequately complete for its complexity level.
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 coverage is 100%, so all 6 parameters are well-documented in the schema itself. The description enumerates the search criteria (text, resource ID, class name, content description) which aligns with the parameters, but adds no value beyond what the schema already provides for each parameter. Baseline 3 applies since the schema does the heavy lifting.
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 finds UI elements by text, resource ID, class name, or content description and returns coordinates. This is a specific verb+resource combination that adequately communicates the function, though it doesn't explicitly differentiate from siblings like ui_tap_element or ui_get_state beyond implying it returns 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 context (finding UI elements before interacting with them) but doesn't explicitly state when to choose this over siblings like ui_dump, ui_tap_element, or ui_get_state. There's no when-to-use or when-not-to-use guidance, though the nature of returning tap coordinates hints at its role as a preamble to tapping.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context beyond what annotations provide. It's a wake action with no description of side effects or state changes.
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?
A single concise sentence, zero wasted text. The description is front-loaded and communicates the core purpose immediately.
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?
This is a very simple tool (1 optional parameter, single action, no nested objects, output schema present). The description is adequate for such a trivial operation. However, it could note that 'serial' is optional and which device it applies to when omitted, or clarify if this only affects the screen state as opposed to device locks.
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 coverage is 100% (the single 'serial' parameter is documented as 'Device serial number'). The description doesn't add meaning about the parameter beyond what the schema provides, so the baseline 3 applies.
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 'Wake the device screen (turn screen on)' uses a specific verb (wake/turn on) with a clear resource (device screen). It clearly distinguishes this tool from screen_off, its direct sibling, and from other device control tools.
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 when to use this tool (when you need to wake the device screen), but there's no explicit guidance on when not to use it or how it differs from screen_off. The sibling tools exist but no alternatives are named. Clear context but lacking 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?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it closes the viewer window but doesn't disclose whether stopping affects the underlying device, whether resources are freed, or what happens if no stream is active. With annotations covering safety, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words. Front-loads the action before the detail about the viewer window. Perfectly sized for a simple stop operation.
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 simple 'stop' action with strong annotations (idempotent, non-destructive) and an output schema present, the description covers the essential purpose. It could mention whether this is the required cleanup for start_video_stream but the description is otherwise sufficient for a focused operation.
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 coverage is 100% and the single 'serial' parameter is well-described as a device serial number in the schema. The description contextually clarifies serial refers to the device whose stream is being stopped, which aligns with the sibling convention. Only one parameter, so burden is low.
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 (stop the HTTP MJPEG video stream) and the resource (device), with specific technical detail about the stream type. It distinguishes from start_video_stream sibling but could be more explicit about the viewer window component and why both are needed.
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 as the counterpart to start_video_stream but doesn't explicitly state when to use it vs alternatives, nor whether it's required before other operations. No mention of prerequisites or ordering constraints relative to siblings.
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?
Annotations provide readOnlyHint=false and openWorldHint=true, signaling this mutates device state and operates on live UI rather than a closed world. The description adds the composite behavior (locating, tapping, typing, optional ENTER) and the label-to-nearest-field intelligence, which is value beyond annotations. However, it doesn't disclose edge behaviors like what happens with multiple matches, focus requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, fully front-loaded with the action sequence and the distinguishing smart-label behavior. No wasted words; every clause earns its place.
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?
With a 100% covered schema and an output schema present, the description doesn't need to explain return values. The composite find+type behavior is well captured, but given it's a complex multi-step tool with 9 params and a smart disambiguation step, a bit more on match failure or multi-step expectations would strengthen completeness.
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 coverage is 100%, so all 9 parameters are documented. The description adds meaning by clarifying the two-part nature: search-based element location (text, contentDesc, resourceId, className, exactMatch, index) feeding into a type action (textToType, pressEnter). This helps an agent understand how search and action parameters relate, adding value beyond the individual field descriptions.
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?
Description clearly states verb+resource (find, tap, inject text, press ENTER) with a distinguishing smart feature (finds nearest input field when targeting a label). It differentiates reasonably from siblings like tap, input_text, and form_fill, though it doesn't explicitly name them.
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 a composite action (find+tap+type) and mentions the smart label-to-field behavior, which gives some context on when it would be preferred. However, it does not explicitly state when to use this vs. alternatives like input_text, tap, or form_fill, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false but no readOnlyHint, so the mutation is implied by the annotation absence. The description adds the 'requires active scrcpy session' prerequisite, which is useful context. However, it doesn't disclose whether rotation affects alpha/beta versions, whether the change persists, or what the return value contains.
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?
A single concise sentence with zero wasted words. The prerequisite information is packed efficiently into the parenthetical. Ideal length for a simple single-parameter tool.
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?
The tool is simple with one optional parameter and a required-session prerequisite clearly stated. The output schema exists so return value explanation isn't needed. For its complexity level, the description covers what's necessary.
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 coverage is 100% with the single 'serial' parameter described as 'Device serial number', which is adequate for an optional/contextual parameter. The description doesn't add meaning beyond the schema, but with full coverage and a single obvious parameter, the baseline 3 is appropriate.
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 (Rotate) and resource (device screen), distinguishing it as an action on the device display. It's unambiguous in purpose and distinguishes from siblings like screen_on/screen_off which control screen power rather than orientation.
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 parenthetical '(requires active scrcpy session)' gives clear context that an active session must exist, implying it belongs within the scrcpy session workflow. It doesn't explicitly name alternatives or when-not-to-use, but the prerequisite is valuable guidance.
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?
Annotations declare destructiveHint=true and readOnlyHint=false, and openWorldHint=true, covering the safety profile. The description itself adds little behavioral context beyond what annotations convey — it doesn't mention that arbitrary commands could have side effects, require root, or block on long-running commands. However, it doesn't contradict the annotations, and the destructiveHint annotation does substantial work here, so the description's minimal addition is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero waste. The first states the core operation, and the second adds positioning guidance. Front-loaded with the action verb. Perfectly sized for a catch-all tool that needs to convey purpose and scope without unnecessary verbosity.
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?
Despite having an output schema, the description is brief but sufficient for a general-purpose escape-hatch tool: it conveys purpose, scope, and usage positioning. Given its catch-all nature, exhaustive behavioral documentation isn't feasible, and the high schema coverage plus output schema relieve the description of return-value and parameter detail burdens. It's adequate for the tool's role.
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%, meaning both parameters (serial and command) have descriptions in the schema. The description adds limited value beyond the schema — it doesn't explain the serial parameter's optionality semantics (capturing 'the device' but serial being optional), nor does it explain output format. Baseline 3 is appropriate since the schema fully documents 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 it executes an ADB shell command on the device and returns output. The verb 'Execute' plus the specific resource ('ADB shell command') make the purpose clear, and the second sentence ('Use this for any device operation not covered by other tools') helps position it against the large sibling set. It doesn't name specific sibling alternatives, but 'not covered by other tools' explicitly signals its generalist fallback role.
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 explicitly states 'Use this for any device operation not covered by other tools,' which gives clear when-to-use guidance and implicitly establishes when NOT to use it (when a specialized sibling exists). This is effective for a fallback/catch-all tool among 48 siblings, though it could be stronger by naming a couple of concrete examples of what operations fit here.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the output is XML format ('as XML'), which is a valuable behavioral detail not in the annotations. It does not disclose potential size/verbosity of the dump, but given annotation coverage, the bar is lower and the description adds meaningful 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?
A single, compact sentence conveys the action, scope, and output format without any filler. Every element earns its place. There is nothing extraneous to trim.
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?
The tool takes one optional parameter (serial, fully described in schema), has an output schema (so return format is specified structurally), and carries readOnly/openWorld annotations. The task is simple—dump the UI hierarchy—and the description adequately communicates purpose and output format for this low-complexity operation. Could note potential verbosity of large dumps but the tool's simplicity doesn't demand much more.
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%, meaning the 'serial' parameter is fully described in the schema as the device serial number. The description adds no additional parameter semantics, which matches the baseline of 3 when schema covers everything. No compensation needed.
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+resource: 'Dump the full UI hierarchy of the current screen as XML.' It specifies both the action (dump) and the object (full UI hierarchy). However, it doesn't explicitly distinguish itself from sibling tools like ui_find_element or ui_get_state, which also relate to UI inspection, though the full-hierarchy XML scope is fairly distinct.
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 inspecting the complete screen layout but doesn't provide explicit when-to-use guidance or contrast with alternatives like ui_find_element (targeted search) or ui_get_state (state extraction). Since multiple UI inspection tools exist among siblings, clearer guidance on when to use a full dump vs targeted queries would improve selection accuracy.
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?
Annotations declare readOnlyHint=true and openWorldHint=false, which the description is consistent with. The description adds value by explaining the detection mechanism (environment variable, binary, built-in default), but doesn't describe return format or potential failure modes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Every part earns its place — the verb, resource, and detection mechanism are all conveyed efficiently with no 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?
For a simple 0-parameter informational tool with an output schema present, the description is appropriately complete. It explains how the version is determined, which is the main behavioral nuance. Minor gap: doesn't mention the built-in default value or what the output format resembles, but with an output schema present, return-format explanation is not required.
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 tool has 0 parameters, so the description need not document any. With schema coverage at 100% (empty schema), the baseline for 0 params is 4, and the description correctly avoids inventing parameters.
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 reports which scrcpy version the MCP server is using, with specific verb ('report') and resource ('scrcpy version'). It also explains the detection order, distinguishing it from any sibling tools.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It's a simple informational tool with no sibling competitors, so context is somewhat implied, but no usage guidance is provided at all.
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?
The description discloses the fallback mechanism behavior, which is valuable beyond what annotations provide. It explains that with an active session scrcpy is used (optional paste flag), otherwise ADB commands handle it. The paste parameter's scrcpy-only limitation is noted. With annotations already declaring readOnlyHint=false, idempotentHint=true, and destructiveHint=false, the description adds the mode-switching context beyond the structured fields.
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 a single, information-dense sentence covering purpose, mechanism, and fallback behavior. It's compact and front-loaded with the primary purpose. It could be slightly more structured with the fallback detail, but there's no 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?
With an output schema present, the description needn't explain return values. The tool has only three parameters, all documented, and the mode-switching behavior is explained. For a relatively simple clipboard-set operation, this is reasonably complete. Minor gap: it doesn't note potential failure modes (e.g., what happens if neither scrcpy nor ADB is available).
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 coverage is 100%, so all three parameters are documented in the schema with descriptions. The description adds some context about the paste flag (scrcpy only) and clarifies the mode-dependent behavior, which aligns with the paste parameter's schema note. However, the description doesn't add substantial meaning beyond the schema — the mode-switching detail is the main added value. Baseline 3 is appropriate for full schema coverage.
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 sets clipboard content on a device, with a specific verb+resource. It also distinguishes the mechanism (scrcpy SET_CLIPBOARD vs ADB fallback), which adds technical specificity. However, it doesn't explicitly contrast with the sibling clipboard_get, though the verb 'set' vs 'get' makes the distinction obvious.
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 explains the dual-mode behavior (uses scrcpy when session active, falls back to ADB), giving the agent context on when the different paths apply. It doesn't explicitly state when NOT to use this tool or name alternatives, but the mechanism details provide meaningful usage context. The openWorldHint=true annotation also suggests permissive operation.
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?
The description adds the scroll direction convention (dy negative/positive) and practical guidance about using large values for meaningful scroll distance. The annotation openWorldHint=true suggests this operates in an open context, and the description aligns with no contradictions. It doesn't describe return values or touch behavior, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste. The direction semantics and example values are front-loaded. It could arguably be more concise by removing redundant direction restatement, but the examples add practical value for parameter tuning.
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 there is an output schema, the return value is covered externally. The description covers the scroll direction convention, provides magnitude guidance, and the schema handles all parameters. It provides adequate context for a positioning tool, though it could mention that coordinates refer to the screen coordinate system.
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 documents all 5 parameters including dx/dy direction conventions and x/y coordinates. The description adds the practical guidance about using large values (e.g., -400, 500), which is additive. The serial parameter has clear schema documentation, so no further detail is needed.
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 'Scroll at the specified position' and provides specific direction semantics (negative dy = scroll up, positive dy = scroll down). It is immediately distinguishable from siblings like scroll_to_element, which scrolls to a target element rather than to a position.
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 showing how to trigger scroll directions with examples like -400 and 500. However, it doesn't explicitly state when to use this tool vs scroll_to_element or other scroll alternatives, and doesn't mention prerequisites like starting a session or having a device connected.
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?
Annotations provide readOnlyHint=true and openWorldHint=true, and the description aligns with them (no contradiction). The description adds specificity about what is returned (package name and activity), which is the key behavioral output an agent needs. The openWorldHint meaning is somewhat ambiguous but not contradicted by the text.
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 fully states the tool's purpose and return value. Zero wasted words, perfectly 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?
This is a simple read operation with good annotations, a single fully-documented parameter, and an output schema present. The description adequately covers what the tool does and returns. For such a low-complexity tool, coverage is sufficient; slightly more context about format of the output (e.g., 'com.example.app/ActivityName') could help but the output schema mitigates this.
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 coverage is 100% — the single 'serial' parameter is fully documented in the schema as 'Device serial number'. The description doesn't add parameter-specific detail beyond what the schema provides, 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 is specific: 'Get the currently foregrounded app package name and activity.' It uses a clear verb ('get') with a precise resource (foregrounded app) and states the exact return values (package name and activity). While siblings exist (app_list, app_start), the read-only 'current app' purpose is distinct enough from those.
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 a query context (foreground status inspection) but provides no explicit when-to-use guidance versus alternatives like app_list or ui_get_state. No exclusions or alternative tool references are given. It's clear enough for straightforward use but lacks explicit differentiation.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety profile. The description adds the WebView coordinate scrolling caveat, which is valuable behavioral context beyond annotations. It does not describe return schema details, but an output schema exists. Good disclosure of a known quirk.
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, tightly written, front-loaded with the core purpose followed by a single high-value caveat. No wasted words or filler.
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-only UI inspection tool with a single well-documented parameter, an output schema present, and readOnly/openWorld annotations covering safety, the description is largely sufficient. The coordinate-caveat adds meaningful operational context. Could slightly benefit from mentioning whether this is a tree of the full screen or focused window, but overall 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?
Only one parameter (serial) with 100% schema description coverage, so the schema already documents it adequately. The description adds no extra parameter semantics beyond what the schema provides, which is acceptable given complete schema coverage.
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?
Clear verb+resource: 'Dump the UI and return a clean Markdown-like tree of visible and clickable elements with viewport coordinates.' Distinguishes well from siblings like ui_dump and ui_find_element by specifying the tree structure and coordinates. However, the relationship to ui_dump is not explicitly clarified, leaving some ambiguity about which to choose.
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?
Includes a practical NOTE about WebView elements reporting identical y-coordinates when scrolled and recommends scroll_to_element first. This is actionable usage guidance. However, it doesn't explicitly contrast with ui_dump or state when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is well covered. The description adds the semantic context that filtering options exist (name partial match, system vs third-party), which is genuinely useful beyond annotations. However, it doesn't disclose output format, potential length limits, or pagination behavior, though with an output schema present and readOnlyHint already set, the description's contribution to transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. The opening states the core function, followed by optional filters and a cross-tool use case. Every word earns its place—no filler, no repetition of the schema, and it's front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With readOnlyHint and openWorldHint annotations covering the safety profile, 100% parameter schema coverage, and an output schema present, the description's role is minimal. Adding the cross-reference to app_start (the primary downstream consumer) is a smart, complete touch. For a simple list-style read tool, this is fully adequate.
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 all three parameters (filter, serial, system) are documented in the schema. The description's mention of 'filter by name or restrict to system/third-party apps' roughly mirrors what the schema already says. The description adds marginal value by framing these as use cases (finding apps by name, restricting to system/third-party), but doesn't go meaningfully beyond the 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 'List installed packages on the device' with a specific verb (list) and resource (packages). It distinguishes itself by offering optional filtering by name or system/third-party classification, and explicitly ties its use to finding package names for app_start, separating it from sibling tools like app_current, app_start, and device_info.
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 states the purpose context—'Use to find package names for app_start'—which implies when to use it. However, it doesn't explicitly state when NOT to use it or name alternative tools like device_info or app_current for different package-related queries. The system/third-party filter guidance is present but implicit in the filter semantics.
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?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds beyond annotations the performance benefit (10-50x faster), the scrcpy-server dependency, and that starting a session is a stateful operation (implicit via 'session is active'). This adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are efficient and front-loaded with the core purpose. The first sentence states the primary function and benefit; the second adds a critical prerequisite. Minimal waste, though the performance claim (10-50x) is slightly verbose but informative.
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?
With a full output schema, 100% parameter coverage, and detailed annotations, the description's job is largely done. It covers the key value proposition (speed gain), the prerequisite, and clearly explains what starting the session enables. Complete enough for an agent to correctly decide when to invoke this tool.
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 all three parameters (maxFps, serial, maxSize) are documented in the schema with defaults and ranges. The description adds no additional parameter detail beyond what the schema already provides, so baseline 3 is appropriate. The description mentions none of the parameters explicitly.
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's verb+resource: 'Start a scrcpy session for fast input control and screenshots.' It explicitly distinguishes from siblings like start_video_stream by referencing scrcpy and naming the specific operations (tap/swipe/text/screenshot) that become faster. The performance benefit (10-50x) adds concrete differentiation.
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 explains when to use it (when faster input control and screenshots are desired) and notes the prerequisite 'Requires scrcpy-server to be installed.' While it doesn't explicitly name stop_session as the counterpart, the clear pairing with stop_session is implied and the prerequisite condition provides practical 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?
Annotations state idempotentHint=true and destructiveHint=false, and the description aligns by mentioning the fallback behavior to ADB commands. The description adds the useful behavior that tools continue working via ADB afterward, which is beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. States the action and the fallback consequence concisely. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop command with one optional parameter, high schema coverage, output schema present, and clear annotations, the description is complete. The fallback behavior note adds important context for a simple tool.
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 coverage is 100% with the single 'serial' parameter documented as 'Device serial number'. The description doesn't add any further semantic meaning about the parameter beyond the schema, so baseline 3 applies.
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?
Clear verb+resource: 'Stop the active scrcpy session.' It specifies the action precisely. However, it doesn't distinguish itself from stop_video_stream or other stop-related siblings (screen_record_stop, stop_video_stream), though the scrcpy context implies different 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 sentence 'Tools will fall back to ADB commands' gives clear post-condition context about what happens after stopping. It implies usage when scrcpy-based interaction is no longer needed, but doesn't explicitly name when to use vs alternatives or provide exclusion criteria.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so no contradiction. The description adds useful context that results are a flat enumeration (serial, state, model) and lists all connected devices. With annotations carrying the safety profile, the description contributes meaningful detail about the return contents.
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?
Single sentence, zero waste, every word earns its place. Front-loaded with the verb and resource immediately.
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?
A 0-parameter list tool with a readOnlyHint and an output schema is well-served by this description. It names the three data fields returned, which effectively covers what's needed. Slight deduction because it doesn't hint that the output schema provides the full return shape, but for a simple listing tool this is close to complete.
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?
Zero parameters means the schema has nothing to cover; schema description coverage reports 100% trivially. The description explains what data is returned per device (serial, state, model), which gives the agent an accurate picture of expected output, compensating for the lack of an explicit return format explanation.
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?
Clear verb (list) + resource (Android devices) + specifics (serial numbers, state, model). Distinct from siblings like device_info (which focuses on single device detail) and version (tool versions). The readOnlyHint and openWorldHint annotations align with the descriptive, safe nature of listing devices.
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?
Implied usage is clear — this is the way to discover available devices before starting sessions or interactions. However, no explicit when-to-use guidance is offered, nor is an alternative named. Lacks the strong when-not guidance seen in top-tier tools.
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?
Annotations provide no readOnly/destructive warnings beyond defaults (readOnlyHint=false, destructiveHint=false), but the description does add useful behavioral context: it 'reports device context' and 'auto-detects and taps the send button' which implies two sequential actions. It doesn't disclose behavior when no element is found, focus failures, or typing speed/visibility limitations beyond what schema covers.
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?
Three sentences, all load-bearing. First sentence states core action, second covers the key option (submit), third covers the targeting mechanism. Zero filler or redundancy.
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?
A moderately complex tool (6 params, output schema present) with clear enough guidance. It covers primary action, optional submit behavior, and targeting alternatives. The output schema exists so return values are already documented. Missing context includes interplay with ui_tap_element or ui_wait_for_element, and behavior on validation failures, but overall adequate.
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 coverage is 100% and schema descriptions are decent, but the description adds meaningful nuance: elementText is explained with concrete examples ('Full Name', 'City/Domicile'), and it clarifies the targeting options are alternatives to auto-focus. The 'device context' reporting aspect for serial is a useful addition beyond the schema's bare 'Device serial number'.
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?
Clear verb+resource: 'Type text into the input field.' Distinguishes from siblings by noting it also reports device context and supports submit and targeted field selection. This differentiates it from related tools like ui_smart_fill, form_fill, and key_event.
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 clearly explains when submit=true is appropriate (auto-tap send for chat/messaging apps) and when to use targeted element selection instead of auto-focus. However, it doesn't explicitly state when to prefer input_text over helpers like ui_smart_fill or form_fill, or when auto-focus might fail.
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?
Annotations declare no readOnlyHint and idempotentHint=false, so mutation expectations are covered. Description adds meaningful behavioral context: the scrcpy fast path when session active vs ADB fallback, force-stop prefix behavior, and the explicit preference over manual UI navigation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, dense with useful information (purpose, preference, mechanism, fallback, force-stop option). No wasted words. Slight density reduction would bump to 5, but current structure earns every sentence.
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 launch operation with comprehensive annotations and schema, the description covers the core behavioral story: when to use, how it executes, and the force-stop variant. The aliasing of package/packageName is handled by the schema. Not exhaustive about failure cases or return values, but the output schema exists and annotations are solid.
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 coverage is 100% with the packageName parameter already described including the '+' force-stop prefix syntax. The description's mention of the force-stop prefix (+) is useful and reinforces the schema, but adds little beyond what packageName's description already documents. Baseline 3 is appropriate when schema carries the weight.
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?
Clear verb+resource: 'Launch an app by package name.' Distinguishes from sibling app_stop (which does the opposite) and app_list/app_current (query tools). Explicitly contrasts with swiping the app drawer / manual UI navigation, establishing what this tool does better than alternatives.
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?
Explicitly states when to use: PREFERRED over swiping app drawer/manual navigation. Communicates the fast scrcpy path when a session is active with a fallback to ADB am start. Mentions the force-stop prefix (+) option. This tells the agent when and why this tool beats alternatives like tap/swipe.
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?
The annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already established. The description adds context by explaining it's a non-interactive timing mechanism meant to be inserted between other actions, which is helpful behavioral context beyond what annotations alone convey.
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, zero waste. The purpose is stated first, followed by practical usage guidance. Every word earns its place and it's appropriately brief for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter utility tool with a clear output schema, full schema coverage, and appropriate annotations. The description fully covers what an agent needs to know: what it does, when to use it, and the parameter semantics are in the schema. Nothing material is missing.
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 coverage is 100% and the single parameter 'ms' is well-described in the schema as 'Milliseconds to wait'. The description doesn't add parameter detail beyond what the schema provides, which is fine given the schema already fully documents the one parameter. 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 it waits for a specified number of milliseconds. It names the resource (time) and the specific action (wait), which distinguishes it from sibling interaction tools. The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly states when to use it: between actions to wait for animations, page loads, or network responses. It gives clear usage context though it doesn't explicitly contrast with alternatives like ui_wait_for_element, which serves a different purpose (waiting for UI elements vs. fixed delays).
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:

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

Score Badge

Copy to your README.md:

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

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/1999AZZAR/scrcpy-mcp'

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