Android Mobile MCP Server

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation4/5
Most tools map to clearly distinct actions and objects, and the descriptions generally resolve potential confusion. However, mobile_take_screenshot and mobile_save_screenshot have overlapping purposes, and mobile_press_button vs. mobile_click_on_screen_at_coordinates could be misread without careful attention.
Naming Consistency4/5
All tools share a consistent mobile_ prefix and mostly follow a verb_noun pattern, making the set predictable. Minor deviations exist with longer prepositional names like mobile_click_on_screen_at_coordinates and mobile_long_press_on_screen_at_coordinates, but they do not break readability.
Tool Count3/5
27 tools is on the heavy side for a typical MCP server, but the broad mobile automation scope—UI interaction, app lifecycle, screenshots/recording, crash reporting, and remote device management—largely justifies the count. Still, the surface feels larger than ideal and could be tightened.
Completeness4/5
The server covers the core mobile automation lifecycle well: app install/uninstall/launch/terminate, screen interaction, navigation, screenshots, recording, and crash retrieval. Notable gaps include file push/pull, device health/battery info, and an explicit wait-for-element/condition tool, but these are workable around.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, so the operation may have side effects, but the description adds no behavioral context. It does not mention that pressing HOME, BACK, or VOLUME buttons can change device state or navigation. No contradiction exists, but no value is added beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is concise and front-loads the core action, though it is perhaps too terse to provide useful disambiguation.
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 simple two-parameter tool with full schema coverage and annotations, the description is minimally viable. However, it leaves a gap around the hardware-button semantics and when to use it relative to screen-click tools, so it is not fully 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%, and the button parameter already lists all supported values and device gives lookup guidance. The description itself adds no parameter-level meaning, so it meets the baseline for fully documented 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 states a clear action and resource: 'Press a button on device.' It is not fully tautological, but it does not explicitly say it handles hardware/system buttons rather than on-screen elements, so it lacks sibling differentiation from mobile_click_on_screen_at_coordinates.
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 this tool versus alternatives such as mobile_click_on_screen_at_coordinates or mobile_type_keys. The supported button list in the schema hints at its purpose, but the description itself provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely restates the action implied by the title and adds no behavioral context beyond what annotations already provide. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not disclose side effects, motion, or platform-specific 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 a single sentence with no filler, and the core action is front-loaded. However, it is nearly identical to the title and the available space could have been used more valuably.
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 schema fully documents all five parameters, including defaults and device discovery, so the parameter context is complete. Still, the description lacks behavioral or usage context beyond the action, leaving the agent to infer the effects and appropriate use of the swipe gesture.
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 parameters are already well-documented with details like defaults and device discovery. The description itself adds no parameter meaning, but the schema carries the full burden appropriately.
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 specific verb ('Swipe') and resource ('the screen'), which clearly distinguishes it from sibling click, tap, and press tools. It is essentially a rephrasing of the title, but the action is unambiguous.
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 about when to use a swipe versus alternatives like mobile_click_on_screen_at_coordinates or mobile_long_press_on_screen_at_coordinates. There is no mention of scroll semantics, gestures, or any condition favoring this tool.
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 already mark the operation as non-read-only and non-destructive, but the description adds little beyond the basic 'terminate' behavior. It does not disclose details such as whether the app is force-stopped, whether background processes are killed, or whether unsaved state is discarded.
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 short for a simple tool. The phrase 'Stop and terminate' is slightly redundant, but the sentence is front-loaded and contains no unnecessary filler.
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 simple two-parameter action with a complete schema and no output schema, the description is minimally viable. However, it omits any note about side effects, success behavior, or relation to the app lifecycle, so an agent gets only the most basic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters device and packageName are fully documented there. The tool description adds no additional semantic detail, so it stays at the baseline 3.
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 ('terminate an app') and resource ('app on mobile device'). It is distinguishable from siblings like mobile_uninstall_app and mobile_launch_app by the verb, though it does not explicitly name or contrast those alternatives.
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 this tool versus alternatives such as mobile_uninstall_app or mobile_launch_app. The description says only what the tool does, not when it should be selected.
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 indicate readOnlyHint=false, so the write behavior is already implied. The description adds only that the output is 'to a file', which is also reflected in the saveTo parameter. It does not disclose overwrite behavior, required permissions, or side effects beyond what annotations already 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?
The description is a single concise sentence with no redundant or unnecessary wording. It is front-loaded with the action and target, making it easy to scan.
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 simple two-parameter tool with strong schema coverage, the description is mostly adequate. However, it misses an opportunity to clarify when to use save versus take_screenshot, and the phrase 'to a file' leaves ambiguous whether the path is on the device or the host. These gaps prevent full contextual 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%; both device and saveTo have clear descriptions, including how to discover devices and the required filename extensions. The tool description itself adds no additional parameter meaning, so the baseline score of 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 states a specific verb ('save'), a resource ('screenshot of the mobile device'), and a destination ('to a file'). This clearly communicates the core operation, though it does not explicitly distinguish itself from the closely related sibling mobile_take_screenshot.
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. Given that mobile_take_screenshot is a sibling, the absence of any comparison or selection criteria leaves the agent to infer the distinction from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the annotations. Annotations already indicate this is not read-only and not destructive, but the description does not disclose potential side effects, prerequisites (e.g., screen on), or response behavior. It essentially restates the tool's purpose without additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and coordinates. There is no wasted wording, and it is appropriately sized for the tool's simplicity.
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 action with three fully documented parameters and no output schema, the description is sufficient to invoke the tool correctly. It might benefit from mentioning its distinctness from sibling tap tools, but that gap is covered by usage guidelines, not contextual completeness. The core information is 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%, so the parameters (x, y, device) are fully described in the schema. The description merely repeats 'x,y coordinates' without adding new meaning, which meets the baseline of 3 for high 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 action (double-tap) and the resource (screen at coordinates). It is concise and specific, but it does not explicitly differentiate from sibling tools like mobile_click_on_screen_at_coordinates or mobile_long_press_on_screen_at_coordinates; the distinction is implied by the verb 'double-tap'.
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 this tool versus alternatives. It does not mention that single taps should use mobile_click_on_screen_at_coordinates, or that double-taps are for specific gestures like zoom. The description provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare `readOnlyHint: true`, so the safe read-only nature is covered. The description adds no additional behavioral context, such as what values may be returned or whether orientation is sensed versus stored, but it also does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words or repetition. It is front-loaded and easy to parse.
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 no output schema, the description should explain what the tool returns, but it only says it gets the orientation. It also omits any indication of return value format, possible values, or behavior on unsupported devices, leaving the agent to guess.
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 provides 100% coverage with a clear description for the `device` parameter, including how to discover available devices. The tool description only says 'of the device', adding no meaningful detail beyond what the schema already documents.
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 ('get') and the resource ('current screen orientation of the device'), so an agent can understand the tool's basic purpose. It is distinguishable from `mobile_set_orientation` by the get/set contrast, though it does not explicitly call out that sibling.
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 gives no guidance on when to use this tool versus alternatives such as `mobile_set_orientation`. It does not mention preconditions, context, or when this read operation is appropriate.
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?
The description adds no behavioral context beyond what the annotations already provide. Annotations show readOnlyHint=false and destructiveHint=false, meaning this is a state-changing but non-destructive operation; the description does not mention potential side effects like overwriting existing apps, permission requirements, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words, making it appropriately concise. It is front-loaded with the action, though it borders on restating the tool title.
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 two fully documented parameters and the absence of an output schema, the description is minimally sufficient for an agent to invoke the tool. However, it leaves gaps around return behavior, side effects, and the need for a valid installed-file path, which are not covered elsewhere except partially in parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including detailed descriptions for both 'path' and 'device', so the baseline is 3. The description itself adds no extra parameter semantics beyond restating that an app is installed.
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 uses the specific verb 'Install' with the resource 'an app on mobile device', clearly distinguishing it from siblings like mobile_uninstall_app, mobile_launch_app, and mobile_terminate_app. It directly states the operation and scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The schema hints at using mobile_list_available_devices to find devices, but this is in a parameter description, not in the tool description, and no alternatives are named.
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 read-only. The description adds little behavior beyond that, such as what 'available' means, whether reports are sorted, or whether the list is empty-capable. With annotations covering the safety profile, a mid-range score 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, front-loaded sentence with no filler. It is appropriately brief for such a simple tool, though it borders on redundant with the title and could add useful information without becoming too long.
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 simple list tool with one well-documented parameter and read-only annotations, the description is minimally sufficient. However, it leaves out what the returned list contains, whether items can be passed to mobile_get_crash, and any details about crash report availability. A sentence connecting this tool to mobile_get_crash would make it noticeably more 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?
The input schema provides 100% coverage for the single 'device' parameter, including a clear description and a pointer to mobile_list_available_devices. The main description does not discuss parameters, but the schema carries the burden adequately, so the description need not repeat it.
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 ('List') and resource ('crash reports') and scopes them to the device, making the basic purpose clear. It is distinguishable from the sibling mobile_get_crash by the list-vs-get operation, though it does not explicitly call out that distinction.
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 gives no indication of when to use this tool versus mobile_get_crash or other siblings. The only contextual hint is 'available on the device,' which weakly implies local scope, but there is no mention of prerequisites, alternatives, or how the returned list should be consumed.
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 already declare destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond that. It does not mention that uninstallation is typically permanent, may affect app data, or requires the app to exist on the device. No contradiction exists, but the description contributes nothing beyond the structured 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 clear, front-loaded sentence with no filler. It is concise, though slightly redundant ('from mobile device' is implied by the tool's context), but the brevity is appropriate for such a straightforward action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is minimally viable for a simple two-parameter destructive operation, with the schema covering argument semantics and annotations covering safety. However, it lacks any description of expected outcomes, return behavior, or prerequisite conditions, leaving some ambiguity for an agent about what happens after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'device' and 'bundle_id' already well-documented, including how to find available devices. The description itself adds no parameter-level meaning, so the baseline of 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 states a specific verb ('Uninstall') and resource ('an app from mobile device'), making the tool's function immediately clear. It is distinct from sibling tools like mobile_install_app, mobile_launch_app, and mobile_terminate_app because only this one performs uninstallation.
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, no mention of prerequisites (e.g., app must be installed), and no exclusion criteria. The agent must infer usage entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive, and openWorldHint is true. The description adds no behavioral context beyond that, such as potential effects like triggering a context menu, whether the press is injected as a system-level gesture, or what happens if the coordinates are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and the second sentence provides a directly useful coordinate-discovery tip. Every word contributes.
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 coordinate-based gesture tool, the description alongside the full schema is nearly sufficient. It lacks an explicit statement about coordinate origin or what visual/behavioral feedback the user will see, but neither is essential for correctly invoking the 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%, so the schema already explains x, y, device, and duration in sufficient detail. The description reinforces using list_elements_on_screen for coordinates but does not add meaningful parameter semantics beyond the schema.
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 specific action and resource: 'Long press on the screen at given x,y coordinates.' This clearly conveys what the tool does. However, it doesn't explicitly distinguish itself from similar sibling gestures like mobile_click_on_screen_at_coordinates or mobile_double_tap_on_screen beyond the gesture name itself.
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 offers one concrete usage hint: 'If long pressing on an element, use the list_elements_on_screen tool to find the coordinates.' This helps with coordinate lookup, but it doesn't say when to prefer long press over alternatives like click or double tap, or when long press would be inappropriate.
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 disclose that the tool is not read-only and has open-world effects, and the description aligns with that. It adds minimal context beyond the annotations — no mention of which browser is used, whether it navigates away from the current app state, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence that front-loads the verb and object with zero filler. Every word earns its place, making it a model of conciseness.
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 low-complexity two-parameter action, the fully documented schema plus side-effect annotations make the definition nearly complete. Remaining gaps are minor: unspecified return behavior (no output schema) and which browser is selected as the target.
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 device parameter's schema description already points to mobile_list_available_devices, which is strong guidance. The tool description adds no parameter-specific detail, so the baseline of 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?
States a specific verb (open), resource (URL), and target (browser on device), which distinguishes it from siblings like mobile_launch_app (apps) and mobile_press_button (UI interaction). Slightly generic phrasing, but unambiguous about the action it performs.
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?
Provides no guidance on when to use this tool versus alternatives. Nothing tells the agent to prefer this over launching a browser via mobile_launch_app, or whether a browser must already be installed on the target device.
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 already indicate this is not read-only (readOnlyHint=false), and the description merely restates that mutation without adding behavioral context such as effects on the current app or whether the change persists. It is consistent with the annotations but adds no extra transparency beyond them.
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 clear sentence with no filler. Every word contributes to conveying the tool's action.
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 two-parameter setter with full schema coverage, the description is sufficient to call the tool correctly. It does not describe return values, but this is minor for a state-changing action and no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented, including the enum for orientation and device discovery guidance in the schema. The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and resource ('screen orientation of the device'), clearly identifying the action. The verb differentiates it from the sibling mobile_get_orientation without needing to name the sibling.
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 about when this tool should be used instead of alternatives such as mobile_get_orientation. The description states the action but gives no context, exclusions, or preconditions, leaving the agent to infer usage from the name.
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 convey that the operation is not read-only and is not destructive. The description adds little behavioral context beyond the basic act of launching, so it earns a middle score rather than higher.
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 short sentences with no filler. The main action is front-loaded, and the supporting guidance about package name discovery is efficiently placed.
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 description is adequate for a simple launch operation, and all parameters are documented in the schema. However, it references 'list_apps_on_device' while the actual sibling is 'mobile_list_apps', which could mislead an agent attempting to follow the guidance.
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%, establishing a baseline of 3. The description adds value by telling the agent how to discover the packageName parameter's value via a list-apps call, going beyond the schema.
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 specific verb-resource pair: 'Launch an app on mobile device' and clarifies it means opening a specific app. It is clear, but it does not explicitly distinguish itself from sibling tools like mobile_open_url or mobile_terminate_app.
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?
'Use this to open a specific app' gives a clear condition for use, and the pointer to list apps for finding the package name offers useful context. It does not explicitly state when not to use this tool or name alternative launch mechanisms.
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 indicate readOnlyHint=false and destructiveHint=false, so the description is not required to restate those. It adds the useful context that input targets the focused element, but it does not disclose whether text appends to or replaces existing content, whether special keys are supported, or what happens after submission. These are moderate gaps but not contradictions.
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, front-loaded sentence that communicates the essential action and target without any filler. Every word earns its place, and it is appropriately sized for a simple input 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?
For a simple tool with fully documented parameters and no output schema, the description is mostly complete: it states the action and the target element. It could be slightly richer by noting that the element must already be focused, but that is already implied by the phrase 'focused element'.
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 three parameters (text, device, submit) clearly described in the input schema. The description adds no additional parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type') and a clear resource ('the focused element'), making the tool's function immediately obvious. It is easily distinguished from sibling tools like mobile_click_on_screen_at_coordinates or mobile_press_button because it specifically handles text input.
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 tool should be used when text needs to be entered into an already-focused element, but it does not explicitly state when to use it versus alternatives or mention any prerequisites beyond focus. There is no exclusion guidance or comparison to other input-related 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 already indicate this is not read-only, not destructive, and operates in an open world. The description adds little behavioral detail beyond the coordinate-based click itself. It does not disclose possible return behavior, coordinate system origin, or feedback after clicking, but for a simple click action the annotation coverage provides a reasonable baseline. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence provides a practical prerequisite tip. 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 coordinate-click tool with fully documented parameters and adequate annotations, the description covers what an agent needs: the action, the coordinate basis, and a pointer to the element-listing tool for finding coordinates. No output schema is present, but click actions typically need no elaborate return-value explanation, so this is sufficiently 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%, so x, y, and device are already well-defined with their own descriptions. The tool description adds only a workflow hint about using list_elements_on_screen to find coordinates, which supports parameter usage but does not add new semantic meaning to the parameters themselves. 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 action: 'Click on the screen at given x,y coordinates.' It identifies the resource (screen) and the approach (coordinates), and it distinguishes from coordinate-based siblings like double-tap or long-press by naming the specific 'click' action. However, it does not explicitly contrast itself with those sibling gesture tools, so it stops short of full sibling 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 gives clear operational context: 'If clicking on an element, use the list_elements_on_screen tool to find the coordinates.' This tells the agent how to obtain valid coordinates before invoking the tool. It does not, however, give explicit when-not-to-use guidance against alternatives like double_tap or long_press, so it lacks full exclusionary 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, so the agent knows this is a safe read operation. The description adds that it returns the crash report's 'full content,' but does not disclose details like response format or whether the report is returned in raw form. With annotations covering safety, a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no redundant wording. The primary action is front-loaded and the useful pointer to the sibling list tool is included without extra 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 two-parameter read-only retrieval tool with fully documented schema properties and appropriate annotations, the description is nearly complete. It could mention what kind of content the crash report contains or the response shape since there is no output schema, but the core instructions for invoking the tool are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'id' and 'device.' The description reinforces that the ID identifies the crash report, but it does not add meaning beyond the schema. Baseline 3 applies because the schema carries the parameter documentation burden.
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 states a specific verb ('Get'), a precise resource ('full content of a crash report'), and the lookup key ('by its ID'). It also distinguishes itself from the sibling listing tool by referencing mobile_list_crashes, so an agent can tell retrieval apart from enumeration.
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 instructs the agent to use mobile_list_crashes to find available crash IDs, providing clear context for when this tool is appropriate. It does not mention exclusions or alternatives beyond the list step, but for a simple get-by-ID tool that is sufficient.
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 readOnlyHint annotation already communicates that this is a safe read operation. The description adds the 'in pixels' unit, which is helpful, but it does not disclose the return shape (e.g., width and height values) despite there being no output schema to fill that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant phrasing. It states the operation, target, and unit efficiently, earning its place without excess words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only getter, the description is largely complete: the parameter is fully documented in the schema and the annotations cover the safety profile. The only minor gap is the exact return format, which is relevant because no output schema is provided.
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 already provides 100% coverage for the single 'device' parameter and even instructs the agent to use mobile_list_available_devices. The description itself adds no parameter-level meaning, but the baseline of 3 applies because the schema carries the full burden successfully.
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 uses a specific verb ('Get'), a clear resource ('screen size'), and a precise unit ('in pixels'). It is unambiguous and distinguishes itself from related siblings like mobile_get_orientation, which concern a different device property.
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 intended use is clear: call this tool when the agent needs the mobile device's screen dimensions. There are no meaningful alternatives among the siblings for this exact purpose, so explicit exclusions are unnecessary, though the description does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint=true, so the description does not need to restate safety. The description adds no additional behavioral details such as output format, completeness guarantees, or potential limitations. There is 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?
The description is a single clear sentence with no filler or redundant phrasing. It conveys the complete functional scope of the tool efficiently.
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 read-only tool with one documented required parameter and annotations declaring safety, the description is sufficiently complete. It could specify the output format, but the returned data is reasonably inferable from 'List all the installed apps.'
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%, and the schema already explains the device parameter and recommends mobile_list_available_devices. The tool description does not need to add parameter-level information, so the baseline of 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 uses a specific verb ('List') and resource ('installed apps on the device'), which clearly distinguishes it from app-manipulation siblings like mobile_launch_app, mobile_terminate_app, mobile_install_app, and mobile_uninstall_app. It communicates exactly what the tool returns.
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 tool's intended use is obvious from 'List all the installed apps on the device.' The parameter description adds helpful context by pointing to mobile_list_available_devices for discovering device identifiers, though it does not explicitly state exclusions or when to prefer other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by warning against caching the result, signaling that the output is time-sensitive and may change between calls, and by clarifying that elements are identified via display text or accessibility label.
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 short sentences with no filler. The core purpose is front-loaded, the output contents are specified, and the caching caveat is a meaningful addition that 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 read-only tool with one parameter and no output schema, the description covers the main behavior, output contents, coordinate presence, and freshness requirement. It does not detail coordinate units or element ordering, but these are minor given the simplicity and the read-only annotation.
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%, and the schema already explains the device parameter and even points to mobile_list_available_devices. The tool description itself adds no new parameter semantics, which matches the baseline for a fully documented single parameter.
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 states a specific verb ('List'), a clear resource ('elements on screen'), and the exact output contents (coordinates, display text, accessibility label). This distinguishes it from sibling tools like mobile_get_screen_size, which only returns screen dimensions, and the interaction tools that operate on elements rather than listing 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 instruction 'Do not cache this result' gives an important usage constraint, implying the agent should call this fresh each time the current screen state matters. However, it does not explicitly say when to choose this tool over siblings or name alternatives, leaving the usage context mostly implicit.
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 meaningful behavioral information beyond the annotations: it discloses the return values (file path, size, approximate duration). readOnlyHint=false is consistent with a state-changing stop action, and the description further clarifies that the result is a saved recording artifact rather than merely a confirmation.
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 one efficient sentence that front-loads the core action and then lists the key outputs. There is no filler or redundant restating of the title.
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 one-parameter tool, the description covers the action, the precondition ('active'), and the return values. It could mention failure behavior when no recording is active, but this is a minor gap given the simplicity and clarity of the overall definition.
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% for the single device parameter, and the schema already provides helpful guidance on discovering available devices via mobile_list_available_devices. The tool description does not add additional parameter semantics, so the baseline of 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 clearly states the action ('Stop'), the target resource ('an active screen recording on a mobile device'), and the expected output. It distinguishes itself from the sibling mobile_start_screen_recording by saying 'Stop' and 'active'.
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 tells the agent this is for ending a currently active screen recording, which makes the usage context clear. It does not explicitly mention that a recording must have been started first, but 'active' implies that precondition strongly enough.
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 key behavioral trait that the recording runs in the background until explicitly stopped, and that a save path is returned. Annotations already indicate mutability (readOnlyHint=false), and the description adds useful stateful context without contradicting them.
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 three sentences long, front-loads the main action, and every sentence adds necessary information: the action, the background lifecycle, and the return value.
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?
The description, combined with the fully covered schema and annotations, gives the agent everything needed to invoke and manage the recording. It explains how the recording is stopped and what the tool returns, with no missing operational details.
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 three parameters already well documented. The description adds value by stating that the result is a saved path, but it does not need to restate parameter meanings.
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 a specific verb and resource: starting screen recording on a mobile device. It also distinguishes itself from the closely related mobile_stop_screen_recording by explicitly naming that sibling as the stop counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: recording runs in the background and is stopped with mobile_stop_screen_recording, which tells the agent how to pair these calls. It does not explicitly discuss alternatives like screenshots, but the lifecycle guidance is sufficient for correct use.
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 the safe-read and dynamic-world aspects. The description adds value beyond annotations by warning 'Do not cache this result,' which complements the openWorldHint and is non-obvious. It also clarifies that a screenshot is a visual observation, not an interaction mechanism, which is a meaningful behavioral trait beyond what annotations express.
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 three sentences with no filler. The primary purpose is front-loaded, followed by a relevant usage exclusion and a concise caching directive. Every sentence 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 tool with one well-documented parameter, clear annotations (readOnlyHint, openWorldHint), and no output schema, the description covers the essential context: what it does, when to use it, when not to, and a handling caveat. The only minor gap is that it doesn't explicitly describe the return format, but this is a minor omission for such a simple, self-evident 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%, so the schema already fully documents the single 'device' parameter, including pointing to mobile_list_available_devices. The description itself adds no parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate since the schema carries the semantic 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?
The description states a specific action ('Take a screenshot') and resource ('the mobile device'), and clarifies its purpose: 'Use this to understand what's on screen.' It also distinguishes itself from the sibling mobile_list_elements_on_screen by noting that if the agent needs to press an element available through the view hierarchy, it must list elements instead. This makes the tool's role unambiguous relative to its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Use this to understand what's on screen') and explicit when-not-to-use guidance with a named alternative ('if you need to press an element that is available through view hierarchy then you must list elements on screen instead'). It also adds a direct operational instruction: 'Do not cache this result.' This fully orients an agent on when to invoke this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the device is shared and billed, borrowed for the session only, and that releasing wipes the device's state. It also exposes the authentication dependency and the retry-on-auth-error behavior. These are material behavioral traits not already present in readOnlyHint/openWorldHint/destructiveHint, and there is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational weight: purpose, exclusivity/billing caveat, explicit user-consent constraint, auth prerequisite, listing prerequisite, and release/wipe warning. The most important selection information is front-loaded in the first sentence, and the warnings come after the core usage context.
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 state-changing cloud allocation tool with no output schema, the description explains what the call returns (a usable device identifier), how long the device is held, what must happen before and after, and how to handle a common auth failure. Nothing needed to invoke it correctly 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 description coverage is 100%, so the baseline is 3; the schema already documents every parameter including filters, wait behavior, and timeout semantics. The description adds useful operational advice to call mobile_list_remote_devices before filtering by name/version, but it does not materially expand on the parameter meanings themselves.
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 first sentence names a specific verb ('Reserve'), a specific resource ('physical device from the remote cloud fleet'), and the key output ('a device identifier usable with the other mobile_* tools'). It clearly distinguishes remote allocation from local devices and from listing remote devices, so an agent can select it correctly among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: only after the user explicitly asks for a remote/cloud device, never speculatively or as a fallback. It also states ordering prerequisites (login first, list devices before filtering), an error-and-retry path for authentication failures, and the required release step afterward.
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 mark readOnlyHint true. Description adds useful context beyond annotations: the tools lists physical and simulated devices, covers both platforms, and indicates devices are local, connected, and free to use. Does not describe return format, but this is a simple list operation.
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 short sentences front-load the core action, then add relevant detail, then provide alternative guidance. No wasted words or repetition.
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 parameterless read-only list tool, the description fully covers what an agent needs: what is listed, platform coverage, local availability, and when to choose the sibling remote-device tool. No output schema is present, but the description gives enough expectation about the return content.
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?
There are zero parameters, so parameter semantics are not needed. The description's context about what is being listed is sufficient and adds no conflicting or missing parameter guidance.
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?
Description uses specific verb 'List' and resource 'available devices', and elaborates that these include physical devices, simulators, emulators, Android and iOS. It clearly differentiates from sibling tool mobile_list_remote_devices by naming it explicitly.
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?
States exactly when to use this tool: for local devices already connected to this machine, ready to use immediately at no cost. Explicitly routes to mobile_list_remote_devices for shared remote cloud fleet devices.
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 provide readOnlyHint=true, and the description does not contradict this. It adds valuable operational context: remote devices are not usable until reserved, reservations may be limited or billed, and authentication is required. This goes beyond what the annotations 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?
The description is front-loaded with the core purpose, then differentiates from the sibling tool, then explains constraints and prerequisites. Every sentence earns its place and there is no filler.
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 zero-parameter, read-only listing tool, the description is complete. It explains what the tool returns, how it differs from the local-device tool, when reservation is needed, billing implications, and the authentication prerequisite.
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 zero parameters and the empty schema already fully documents this. The description adds no parameter details because none are needed, and it instead usefully describes what the returned catalog contains.
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 states a specific verb ('List') and resource ('catalog of device models ... remote cloud device fleet'), including the returned fields (make, platform, OS version). It also explicitly distinguishes this from mobile_list_available_devices, making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when this tool is appropriate: when the user needs remote cloud devices, not locally connected devices. It names the alternative tool (mobile_list_available_devices), states the prerequisite (mobile_login_to_cloud_provider), and provides a retry strategy on authentication failure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It richly discloses behavior beyond the annotations: the call returns quickly without waiting, the login continues in the background, a URL and one-time code are returned for the user, and the caller should retry after user confirmation. This is exactly the kind of temporal and interaction context annotations cannot 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?
The description is longer than average but every sentence earns its place: purpose, prerequisite relationship, failure trigger, non-blocking behavior, user handoff, and retry instruction. It is well-structured and front-loaded with the core 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?
For a zero-parameter tool with no output schema, the description is fully self-sufficient. It covers when to call, what the call returns, what does not happen, what the user must do, and what to do next. Nothing an agent needs to invoke it correctly is missing.
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 zero parameters and the schema coverage is 100%, so the empty schema already communicates there are no inputs. The description reinforces this by framing the tool as a simple action trigger rather than a parameterized operation.
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 opens with a specific verb and resource: 'Start authenticating this machine with the remote device cloud provider.' It clearly differentiates this login/setup tool from the UI-interaction and remote-device siblings by naming the specific commands that depend on it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool: once before mobile_list_remote_devices or mobile_allocate_remote_device, and after those fail with an authentication error. It also gives a firm exclusion: never call speculatively, only after the user explicitly asks to use remote/cloud devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds critical details: state loss (apps, files, changes), reallocation delays, and the possibility of a different physical unit. It also warns about the cost of releasing prematurely. This substantially enhances transparency beyond the structured annotations, making the operation's consequences clear.
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?
Concise, efficient three-sentence description. The purpose is front-loaded, followed by critical consequences, then usage guidance. No redundant information; every sentence 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 single-parameter tool with destructive side effects and a clear counterpart, the description covers purpose, usage timing, consequences, and the relationship to allocation. An agent has everything needed to invoke and interpret the tool correctly, given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the 'device' parameter (100% coverage), so baseline is 3. The description adds meaning by specifying that the device must have been 'previously reserved with mobile_allocate_remote_device', which clarifies the expected source of the identifier. This adds value beyond the schema, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Release'), the resource ('a device previously reserved with mobile_allocate_remote_device'), and the outcome ('back to the remote cloud fleet so it becomes available to others'). It directly distinguishes from the sibling mobile_allocate_remote_device by referencing it explicitly, making the tool's role unambiguous.
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?
Provides explicit guidance on when to use: 'Only release once the whole task is finished' and when not to: 'if there is more work to do on the same device shortly, keep holding it rather than releasing and reallocating.' This goes beyond typical usage hints and gives clear conditions, making it easy for an agent to decide correctly.
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:

[![DevAutoFlow-MCP MCP server](https://glama.ai/mcp/servers/PaboluManohar/DevAutoFlow-MCP/badges/card.svg)](https://glama.ai/mcp/servers/PaboluManohar/DevAutoFlow-MCP)

Score Badge

Copy to your README.md:

[![DevAutoFlow-MCP MCP server](https://glama.ai/mcp/servers/PaboluManohar/DevAutoFlow-MCP/badges/score.svg)](https://glama.ai/mcp/servers/PaboluManohar/DevAutoFlow-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/PaboluManohar/DevAutoFlow-MCP'

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