mobile-mcp

by Kavya55

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation3/5
Most tools are distinct, but 'mobile_take_screenshot' and 'mobile_save_screenshot' overlap significantly in purpose, which could confuse an agent. Additionally, gesture tools like 'mobile_click_on_screen_at_coordinates' and 'mobile_double_tap_on_screen' have similar naming, though their actions are clearly different.
Naming Consistency4/5
The 'mobile_' prefix and verb_noun pattern are mostly consistent, but there are deviations such as 'mobile_click_on_screen_at_coordinates' versus 'mobile_double_tap_on_screen' which omits the 'at_coordinates' suffix. A few tool names are longer and less uniform, but overall the pattern is recognizable.
Tool Count4/5
With 23 tools, the server is above the typical well-scoped range of 3-15, but the breadth of mobile automation features (app management, gestures, orientation, screenshots, etc.) justifies most tools. The count feels slightly heavy but not redundant.
Completeness4/5
The tool set covers core mobile device operations well: app lifecycle, screen interaction, orientation, screenshots, and crash retrieval. Minor gaps exist, such as no explicit device info tool (e.g., model, OS version) and no update for existing apps, but these are not critical for most workflows.
Average 3.7/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 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.
This repository includes a glama.json configuration file.
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?
The destructiveHint annotation is present, but the description adds no behavioral context beyond restating the action. It does not mention potential side effects like navigation changes or platform-specific behavior, which would be valuable despite the annotation.
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 unnecessary words. It is front-loaded and to the point, though it could be slightly more informative without losing brevity.
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 rich schema and destructiveHint annotation help compensate for the sparse description. However, it lacks contextual cues to differentiate from sibling input tools and does not explicitly state that it handles hardware/device buttons, relying on the schema for that distinction.
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 includes detailed descriptions for both parameters, including a list of supported buttons and a reference to mobile_list_available_devices. The tool description itself adds no parameter semantics, 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 'Press a button on device', which is a clear verb+resource. However, it does not explicitly distinguish from sibling input tools like clicking on screen or typing keys, so it is clear but lacks strong differentiation.
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. No mention of platform limitations or use cases is provided, leaving the agent to infer from the schema.
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 details beyond the annotation destructiveHint: true. It does not explain what side effects a swipe might have, whether it triggers scrolling or navigation, or how it interacts with the app's UI. The burden is partially on the annotation, but the description itself contributes nothing about potential consequences.
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: 'Swipe on the screen.' It is concise and front-loaded with the key verb and object, with no wasted words. However, its brevity borders on under-specification, as it omits any context about direction or intended use, but it remains appropriately size for a simple gesture 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?
For a straightforward swipe tool, the description plus schema and annotations provide a minimally viable level of information. The schema explains parameters, and the annotation flags destructive potential, but the description lacks contextual guidance on when to choose this tool over siblings and what the effect will be on the app state. This leaves some gaps for an agent to reason about.
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 with descriptions for all five parameters, including units, defaults, and how to discover device identifiers. The description adds no additional parameter information, so it relies on the schema, which is already sufficient. This aligns with the baseline score of 3 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 'Swipe on the screen' clearly states the action (swipe) and the target (screen), making the tool's purpose obvious. It does not explicitly differentiate from sibling interaction tools like tap or long press, but the verb itself is distinct enough to convey the intended gesture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mobile_click_on_screen_at_coordinates or mobile_long_press_on_screen_at_coordinates. There are no usage scenarios, prerequisites, or conditions specified, leaving the agent to infer appropriateness 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description aligns by saying 'terminate'. However, the description adds no additional context about effects such as process termination vs. data removal, or whether stopping is reversible. Since annotations already convey destructiveness, the description provides minimal extra value.
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 and front-loaded. It is concise but includes slight redundancy with 'Stop and terminate'. Overall, it's appropriately sized but lacks extra useful content.
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, with full schema coverage and a destructive annotation, so the description meets a minimum viable threshold. However, it fails to clarify the distinction from uninstall and provides no usage context, making it only partially 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 descriptions for both parameters (device and packageName), covering 100% of the schema. The description itself adds no parameter-specific information, so it does not exceed the baseline.
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 'Stop and terminate' with a clear resource 'app on mobile device'. It clearly conveys the action, but doesn't explicitly distinguish this from mobile_uninstall_app, which could be a source of confusion.
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 provided on when to use this tool versus alternatives. The description doesn't mention that this only terminates the running app and does not uninstall it, nor does it reference sibling tools like mobile_uninstall_app.
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 include destructiveHint: true, which already informs the agent of the destructive nature. The description adds no additional behavioral context such as potential app replacement, permissions needed, or installation failure modes. Since the annotation covers the key safety aspect, the lack of extra disclosure is acceptable, keeping the score at a baseline 3.
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, focused sentence with no redundant words. It conveys the core action without elaboration, which is the pinnacle of conciseness and structure.
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, combined with the rich schema and annotation, covers the essential information for invoking the tool. However, it does not mention installation outcome or side effects beyond the annotation's destructive hint. Since there is no output schema, a bit more context on expected results would improve completeness, but the current level is minimally 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?
The input schema provides full descriptions for both parameters, including file format guidance for different platforms and device discovery instructions. With 100% schema description coverage, the description has no additional need to explain parameters, aligning with the baseline of 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 verb 'Install' and the resource 'an app on a mobile device', making the primary purpose obvious. It does not explicitly differentiate from sibling tools like mobile_launch_app or mobile_uninstall_app, but the action verb itself distinguishes the operation as an installation, which is specific enough for a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mobile_launch_app or mobile_uninstall_app. It also doesn't mention prerequisites like device availability. The only usage hint is in the schema's device parameter description, but the tool description itself is silent on when to invoke it.
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?
Description adds no behavioral context beyond the destructiveHint annotation. It does not mention permanence, data removal, or any side effects.
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 with no redundancy. Front-loaded with the action and resource, making it efficient and easy to parse.
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?
Simple tool with complete schema and destructive annotation. Description conveys the core function but lacks usage context, alternatives, or outcome 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 provides complete descriptions for both parameters (100% coverage), so the description need not add parametric details. 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?
Clear verb 'uninstall' with resource 'app' and location 'mobile device'. It distinguishes from sibling tools like install, launch, and terminate.
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 (e.g., terminate vs uninstall). No prerequisites or context provided.
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 mark destructiveHint as true, but the description adds no behavioral detail beyond 'launch' or 'open.' It does not explain what happens to the current app, whether the app is brought to the foreground, or why the operation is considered destructive. It provides no context beyond the annotation.
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 short sentences, front-loading the main purpose without unnecessary fluff. The package-finding hint is concise, even though the referenced tool name is incorrect.
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?
Although the schema is detailed, the description references a nonexistent tool for discovering the required packageName and provides no clarification around the destructive annotation. This leaves the agent without reliable guidance for successful 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?
The input schema already covers all parameters with descriptions, so the baseline is 3. The only additional hint in the description is to find packageName via 'list_apps_on_device,' which is an inaccurate tool reference; it adds nothing about device or locale 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 'Launch an app on mobile device' and 'Use this to open a specific app,' giving a specific verb and resource. This distinguishes it from siblings like mobile_terminate_app, mobile_install_app, and mobile_open_url.
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?
It provides clear context for when to use the tool ('Use this to open a specific app'). However, it instructs calling 'list_apps_on_device' to find package names, but that tool is not in the sibling list—mobile_list_apps is the actual tool. This makes the guidance partly misleading and there are no exclusions or alternatives 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?
The annotation readOnlyHint=true already signals a safe read operation, and the description's 'Get' is consistent with that. The description adds minor value by specifying the unit 'pixels' and the device scope, but does not disclose the return format or any other behavioral details.
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, clear sentence delivers the essential information with no filler. The action and subject are front-loaded, making it immediately 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?
The tool is simple, but since there is no output schema, the description leaves ambiguity about the exact return structure (e.g., width x height vs. diagonal). The phrase 'in pixels' offers the unit but not the shape of the result, which is a notable gap.
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 fully documents the single 'device' parameter, including guidance to use mobile_list_available_devices. The description itself does not add parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'screen size' with an explicit unit ('in pixels'). This sufficiently distinguishes it from sibling tools like mobile_get_orientation, which retrieves 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 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. The only contextual hint appears in the schema's parameter description (referencing mobile_list_available_devices), which helps with parameter selection but not tool selection.
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 annotation destructiveHint: true already informs the agent that this operation is potentially destructive. The description adds the context that the URL opens 'in browser on device', but does not disclose additional behavioral details such as navigation side effects, default browser behavior, or whether the current app will be left.
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 with no filler. Every word earns its place, making it highly concise and easy to parse.
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 with only two parameters, both documented, and the action is clear. However, the description lacks information about expected outcomes or side effects beyond the destructive annotation, and there is no output schema. It is adequate but leaves room for more 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 both 'device' and 'url' adequately documented in the schema. The description adds no additional semantic meaning beyond what the schema already provides, 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 ('Open') and resource ('a URL in browser on device'), clearly distinguishing it from sibling tools that launch apps, take screenshots, or manage devices. It is unambiguous and actionable.
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 prerequisites, and no exclusions. It simply states the action without contextual usage instructions.
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 annotation destructiveHint=true indicates the operation is potentially destructive, and the description adds the condition 'focused element' as the target. However, it does not explain side effects such as overwriting the current text, what happens if no element is focused, or the behavior when 'submit' is true (though this is partially covered in the schema).
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 of six words, front-loading the core action and target. Every word contributes meaning; there is no fluff or repetition.
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 typing tool, the description covers the basic operation and the schema covers parameters. However, it lacks usage context (e.g., when to use vs. alternatives, prerequisites like having a focused element clearly established) and does not compensate for the absence of an output schema with information about expected results or errors.
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 full descriptions for all three parameters (text, device, submit), including guidance for finding available devices. The tool description itself adds no additional parameter semantics, so the schema's 100% coverage establishes a baseline of 3.
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 function: 'Type text into the focused element.' The verb 'type' and the resource 'text into the focused element' distinguish it from sibling input tools like mobile_press_button or mobile_click_on_screen_at_coordinates, which involve different forms of interaction.
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 such as pressing a button or tapping coordinates. The only context is the parameter description for 'device' recommending mobile_list_available_devices, but this is not about tool selection 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 offers no behavioral context beyond the action itself. While the destructiveHint annotation indicates potential destructive effects, the description does not elaborate on consequences, such as triggering app actions or changing UI state, which would be valuable for an agent deciding to invoke this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and inputs. There is no unnecessary information, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool with three well-documented parameters and no output schema, the description is sufficient to convey its purpose and usage. However, it could be slightly enhanced by noting typical return behavior or potential side effects, but the current level is 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?
The input schema provides full descriptions for all three parameters (x, y, device), including units and a hint for finding devices. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (double-tap) and target (screen), and specifies the input as x,y coordinates. This distinguishes it from sibling tools like click, long press, and swipe, which involve different gestures.
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 a double-tap gesture is needed, but it does not explicitly state when to prefer this over alternatives such as single tap or long press. No exclusion or alternative guidance is provided beyond the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read operation. The description adds minimal context beyond the annotation—merely specifying 'current' orientation. This is not misleading, but it does not disclose any additional behavioral traits such as return format or potential platform limitations.
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 that immediately states the tool's function. Every word contributes to clarity, with no unnecessary filler or repetition.
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 getter with one parameter, the description is sufficient. The lack of an output schema is somewhat mitigated by the clarity of 'screen orientation,' though the exact return format is not specified. Given the low complexity, this is not a significant gap.
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 only parameter 'device' has a full description in the schema, including a pointer to mobile_list_available_devices. Since schema coverage is 100%, the description does not need to add parameter details. 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 'Get the current screen orientation of the device' uses a specific verb (get) and identifies the exact resource (screen orientation), clearly distinguishing it from the sibling tool mobile_set_orientation. It is unambiguous and not a tautology.
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 does not mention that it is the read counterpart to mobile_set_orientation, nor does it reference sibling tools like mobile_get_screen_size. No explicit or implied usage context 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?
The description adds no behavioral context beyond what annotations already indicate (destructiveHint=true). It does not disclose side effects, reversibility, or any device-specific behavior. Given that this is a mutating operation, more transparency would be valuable, but the annotation covers the basic destructive nature.
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, front-loaded sentence with no filler. It efficiently states the action and target resource, earning a high score for 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 simple tool with two well-documented parameters and no output schema, the description and schema provide sufficient information. The only minor gap is the lack of usage guidance, but overall the definition is complete enough for its 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 coverage is 100% and both parameters are fully described, including the enum values for orientation. The description adds no extra parameter semantics, 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 a clear resource ('screen orientation'), making the tool's purpose unambiguous. It naturally distinguishes from sibling mobile_get_orientation, which reads orientation rather than changing it.
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 setter role opposite to mobile_get_orientation, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or side effects. Usage context is only inferred from the verb 'change' and the sibling tool name.
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?
Beyond the readOnlyHint, the description adds the specific instruction 'Do not cache this result,' indicating the output is dynamic. It also specifies the output content (coordinates, text/label), providing transparency about what to expect. However, it does not discuss potential failures, required permissions, or return structure, so it's not a 5.
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 concise sentences, front-loaded with the primary action. Every word adds value, with no redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description is fairly complete: it states what is listed (elements, coordinates, text/label) and adds a caching caution. It could benefit from clarifying what qualifies as an 'element' or whether the output is a list, but overall it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the 'device' parameter, including a pointer to mobile_list_available_devices. The tool description adds no parameter-specific information, but since schema coverage is 100%, 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 tool's function: listing on-screen elements with coordinates and display text or accessibility label. It distinguishes from sibling tools like mobile_take_screenshot or mobile_get_screen_size by focusing on UI element hierarchy rather than images or dimensions.
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 does not explicitly state when to use this tool versus alternatives. It only includes 'Do not cache this result,' which is a usage caution, but there is no mention of alternatives or contextual triggers. The schema's parameter description references sibling tool mobile_list_available_devices, but that's for parameter resolution, not tool selection.
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 tool has a destructiveHint: true annotation, so the bar for additional behavioral disclosure is lower. The description accurately describes a file-writing operation but adds no extra context such as potential overwriting of existing files, required permissions, or side effects beyond what the annotation already signals.
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 with no redundant words. It succinctly conveys the tool's purpose without unnecessary detail.
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 tool with a well-documented schema and clear annotations. The description is sufficient for the agent to understand the basic operation, though a note about overwriting behavior or file path handling would enhance completeness. Overall, it is adequate for the tool's simplicity.
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 of both parameters with clear descriptions. The tool description itself adds no parameter-level meaning beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('save') and clearly identifies the resource ('screenshot of the mobile device') and the target ('to a file'). This distinguishes it from the sibling tool mobile_take_screenshot, which likely captures a screenshot without saving to a 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 use when you need to persist a screenshot to a file, but it does not explicitly state when to use this tool versus alternatives like mobile_take_screenshot, nor does it mention 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?
The destructiveHint annotation already flags this as potentially destructive, and the description doesn't add further behavioral details beyond the click action. It provides a useful workflow hint but not additional side-effect information, which is acceptable given the simple nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the action first. No redundant phrases, every sentence serves a 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?
The tool is simple, all params are documented, and the annotation covers the destructive nature. The description gives enough context for using coordinates and when to use list_elements. Minor lack of success/failure details is acceptable without an output schema.
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 descriptions for x, y, and device. The description doesn't add new semantics beyond the schema, but the guidance about element coordinates complements the parameter meaning. 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 identifies the action as clicking at x,y coordinates with a specific verb and resource. It differentiates from sibling tools like double_tap or long_press by focusing on a single coordinate-based click. It also mentions an alternative for element-based clicking.
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?
It explicitly states that for clicking on an element, one should first use list_elements_on_screen to find coordinates, providing direct guidance on when to use this tool versus the alternative. It doesn't explicitly exclude other gesture tools, but the guidance is clear and actionable.
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 is consistent with the readOnlyHint annotation and adds the scope detail 'all installed apps'. However, it does not disclose return format, whether system apps are included, or any permission requirements. With annotations already declaring read-only, the description provides minimal additional behavioral context beyond the scope.
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 of six words. No filler or redundancy, 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 read-only list tool, the description combined with the schema and annotation is largely sufficient. It does not mention return format or app name specifics, but given the tool's simplicity and lack of output schema, the current description is nearly complete for selection purposes.
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 device parameter is fully explained as the identifier to use, with a pointer to mobile_list_available_devices. The description does not add any parameter-specific detail beyond referencing 'the device', so it relies on the schema, matching the baseline.
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 'List' with a clear resource 'installed apps on the device'. This clearly distinguishes it from sibling tools like mobile_launch_app, mobile_install_app, and mobile_list_crashes, which target different actions or data types.
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?
While no explicit alternatives or exclusions are given, the phrase 'List all the installed apps' provides clear context for when to use this tool. The schema also points to mobile_list_available_devices for device selection, which is useful guidance even though it's not in the description itself.
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 the scope 'on the device' but does not disclose any additional behavioral traits such as return format or ordering. With annotations covering the safety profile, a 3 is appropriate for the minimal added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the tool's function. No unnecessary words 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?
For a simple, one-parameter, read-only listing tool, the description covers the essential purpose and scope. It could optionally mention that the returned crash reports could be used with 'mobile_get_crash,' but this is not strictly necessary given the tool's simplicity and the lack of an output schema.
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 single parameter 'device' already has a helpful description with a pointer to a companion tool. The tool description adds no additional parameter semantics beyond what the schema provides, 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.
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' with a clear resource 'crash reports' and scope 'on the device,' making its purpose unambiguous. It also distinguishes itself from the sibling tool 'mobile_get_crash,' which likely retrieves a single crash, by focusing on the listing action.
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 input schema description provides usage guidance by directing the user to 'mobile_list_available_devices' to find valid device identifiers. However, the tool description itself does not explicitly state when to use this over alternatives like 'mobile_get_crash,' though the use case is clear from the context.
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 readOnlyHint=true annotation already signals a safe read operation. The description adds that it retrieves the full crash report content, clarifying the scope beyond just retrieving an ID. No additional behavioral disclosures are necessary for this straightforward read.
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, front-loaded with the primary purpose. The second sentence adds essential guidance on finding IDs. No wasted words or redundant information.
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 get tool with complete schema and annotations, the description covers the prerequisite (mobile_list_crashes) and indicates the output type ('full content'). It does not describe return format, but given the simplicity and lack of an output schema, this is acceptable.
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?
Both parameters are fully described in the input schema, which already explains their purpose. The description's phrase 'by its ID' reinforces the id parameter but does not introduce new semantic information beyond what the schema provides.
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 ('Get the full content of a crash report') and the resource ('by its ID'). It distinguishes from sibling tools like mobile_list_crashes by emphasizing 'full content' retrieval.
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?
Explicitly directs users to mobile_list_crashes to find available crash IDs, providing a clear prerequisite workflow. The schema also references mobile_list_available_devices for device selection, but the description does not explicitly exclude alternative 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?
The annotation destructiveHint: true already signals potential destructive behavior. The description adds minimal extra context beyond the action itself, only noting how to find coordinates for elements. It does not contradict the annotation, but it also doesn't disclose additional behavioral traits such as side effects or system behavior. Given the annotation covers the safety profile, a score of 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?
The description is two sentences, concise, and front-loaded with the core action. The second sentence provides a practical tip without redundancy. Every word earns its place, and it avoids repeating schema details.
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 action tool with no output schema and a single annotation. The description covers the core action and a key usage tip. It omits details like duration default, but that is already in the schema. For a tool of this complexity, the description is sufficiently complete, though it could theoretically mention that a long press may trigger context menus or custom actions.
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 all parameters (x, y, device, duration) described. The description adds value by instructing to use list_elements_on_screen to find coordinates, which clarifies the expected format of x/y parameters in a real workflow. This goes beyond the schema's bare pixel descriptions, earning 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 'Long press on the screen at given x,y coordinates', identifying the specific action (long press) and resource (screen coordinates). It distinguishes from sibling tools like click, double tap, and swipe by the verb 'long press', and the second sentence adds a usage hint without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for one common scenario: 'If long pressing on an element, use the list_elements_on_screen tool to find the coordinates.' This tells the agent how to obtain coordinate input and implies this tool is for coordinate-based presses. However, it does not explicitly contrast with click/double-tap tools, so it's not a full when-to-use vs alternatives guideline.
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 destructiveHint=true, and the description adds value by specifying that the tool returns file path, size, and approximate duration. This discloses the outcome of stopping a recording, which is not captured by the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and then tersely lists the return values. Every word earns its place with no 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?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose and return values. It could mention error behavior if no recording is active, but this is a minor omission for such a straightforward stop operation.
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% for the sole parameter 'device', and its description already provides complete guidance including a reference to mobile_list_available_devices. The tool description does not need to add further parameter details beyond what the schema already 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 clearly states the action ('Stop') and the resource ('an active screen recording on a mobile device'). It is distinct from siblings, especially the paired mobile_start_screen_recording, and adds return value information that makes the tool's purpose 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 phrase 'Stop an active screen recording' implies the tool should be used only when a recording is in progress. This provides clear context, but the description does not explicitly state what happens if no recording is active or mention any alternatives, though the sibling list makes the pairing obvious.
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 annotation destructiveHint:true already signals potential harm, and the description adds behavioral context: the recording runs in the background, requires an explicit stop, and returns a save path. No contradiction with annotations is present.
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, front-loaded with the action, and no fluff or repetition of schema details.
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 start-recording tool with no output schema, the description conveys the key return value (path), the background lifecycle, and the stop counterpart. The schema covers parameter details, making this description 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?
Input schema covers all three parameters with descriptions (100% coverage), so the description adds little beyond noting the returned path. This aligns with the baseline score of 3.
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 'Start recording' with the resource 'screen of a mobile device,' clearly distinguishing the tool from its sibling mobile_stop_screen_recording, which is explicitly named. It states the action and the object precisely.
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?
It explains that the recording runs in the background until stopped with mobile_stop_screen_recording, giving clear context for when to use this tool and naming its counterpart. It lacks explicit 'when not to use' guidance, but the context is unambiguous.
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, so the read-only nature is covered. The description adds valuable behavioral context beyond annotations: 'Do not cache this result,' which is a non-obvious constraint that the agent must know. It also clarifies that the screenshot is for understanding the screen, not for saving or interaction, which supplements the annotation's minimal safety signal.
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 compact: two sentences, with the main purpose stated first, followed by usage guidance and a cache warning. Every sentence serves a distinct and valuable purpose, with 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?
For a simple tool with one well-documented parameter and a read-only annotation, the description is quite complete. It covers purpose, usage guidelines, and a behavioral note about caching. It does not explicitly describe the return format, but given the tool's nature and the lack of an output schema, the omission is acceptable because the screenshot result is inherently visual and the description implies its purpose.
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 has 100% coverage for the single parameter, and its description already explains how to find available devices. The tool description adds no additional parameter detail, so the schema carries the full burden, which matches 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.
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 function with a specific verb and resource: 'Take a screenshot of the mobile device.' It also distinguishes its purpose from the sibling tool for listing elements by explaining when each should be used, which is exactly what a clear purpose statement should do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: use it to understand what's on screen, but if you need to press an element available through the view hierarchy, you must list elements on screen instead. It also adds a constraint not to cache the result, giving clear usage context.
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. The description adds valuable behavioral context beyond that: it lists physical devices, simulators, and emulators, and clarifies that both Android and iOS are included. It does not mention output format details, but the added scope information is meaningful for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the main action front-loaded ('List all available devices'). Every sentence contributes meaning, and there is no redundancy or 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 tool with no input parameters and no output schema, the description adequately covers the tool's purpose and scope. It explains what devices are returned (physical, simulator, emulator; Android, iOS), which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% by default. The description adds no parameter-specific details because none exist, but the baseline of 4 is appropriate for a no-parameter tool, and the description clarifies the result set (available devices across platforms).
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 ('available devices'), clearly distinguishing it from sibling tools related to orientation, screen recording, crashes, and apps. It also specifies the scope: physical devices, simulators, and emulators, across both Android and iOS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool returns (both platforms, physical and virtual devices), effectively indicating when to use it. It does not explicitly name alternatives or exclusions, but no sibling tool performs a similar listing function, so the usage context is sufficient.
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:

[![mobile_mcp_latest MCP server](https://glama.ai/mcp/servers/Kavya55/mobile_mcp_latest/badges/card.svg)](https://glama.ai/mcp/servers/Kavya55/mobile_mcp_latest)

Score Badge

Copy to your README.md:

[![mobile_mcp_latest MCP server](https://glama.ai/mcp/servers/Kavya55/mobile_mcp_latest/badges/score.svg)](https://glama.ai/mcp/servers/Kavya55/mobile_mcp_latest)

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/Kavya55/mobile_mcp_latest'

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