Mobile Next MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity; actions like click, double-tap, long press, swipe, and type are well-differentiated, and resource targets (e.g., apps, screen, orientation) are specific. The descriptions provide clear guidance on when to use each tool, preventing misselection.
Naming Consistency5/5
All tool names follow a consistent 'mobile_verb_noun' pattern with snake_case throughout, such as mobile_click_on_screen_at_coordinates and mobile_list_apps. This predictability makes the set easy to navigate and understand at a glance.
Tool Count5/5
With 19 tools, the count is well-scoped for mobile device automation, covering essential actions like interaction, app management, and device control. Each tool earns its place by addressing a specific need without redundancy, fitting the domain's complexity appropriately.
Completeness5/5
The toolset provides complete coverage for mobile automation, including CRUD-like operations for apps (install, launch, terminate, uninstall), screen interaction (click, swipe, type), device management (orientation, screen size), and diagnostics (screenshot, element listing). No obvious gaps exist for core workflows.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations provide. The destructiveHint: true annotation already indicates this is a potentially destructive operation, but the description doesn't elaborate on what might be destroyed (e.g., UI state, navigation) or any other behavioral traits like performance characteristics or side effects. However, it doesn't contradict 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 extremely concise at just three words, which is appropriately brief for a simple action. However, this brevity comes at the cost of being under-specified rather than efficiently informative, as it lacks necessary context that would make it truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mobile interaction tool with no output schema, the description is incomplete. It doesn't explain what happens after the swipe (navigation effects, state changes), doesn't mention the mobile testing context implied by sibling tools, and provides insufficient guidance for proper use despite the tool having multiple parameters and being marked as destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all 5 parameters including their purposes, defaults, and constraints. The description adds no additional parameter semantics beyond what's already in the structured 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swipe on the screen' is a tautology that merely restates the tool name/title without adding meaningful specificity. It doesn't distinguish this swipe action from other mobile interaction tools like mobile_click_on_screen_at_coordinates or mobile_long_press_on_screen_at_coordinates, nor does it clarify what resource or context this swipe operates on.
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 this tool versus alternatives. While the input schema mentions using mobile_list_available_devices to find devices, the description itself offers no context about appropriate use cases, prerequisites, or distinctions from sibling tools like mobile_double_tap_on_screen or mobile_press_button.
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 provide 'destructiveHint: true', which already indicates this is a destructive operation. The description adds minimal behavioral context beyond this - it confirms the destructive nature ('Uninstall') but doesn't elaborate on what 'uninstall' entails (permanent removal, requires permissions, potential side effects). 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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward destructive operation and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is insufficient. It doesn't explain what happens after uninstallation (success/failure indicators, error conditions, or what the tool returns). Given the destructive nature and lack of output schema, more behavioral context about the operation's consequences would be needed for 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?
With 100% schema description coverage, both parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema descriptions. The baseline score of 3 reflects adequate coverage through the schema alone.
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 ('Uninstall') and target ('app from mobile device'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'mobile_terminate_app' or 'mobile_list_apps', which would require mentioning it's a permanent removal operation rather than just stopping an app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to identify the device first using 'mobile_list_available_devices'), when not to use it, or how it differs from related tools like 'mobile_terminate_app' (which stops but doesn't remove).
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', indicating this is a mutation operation, which the description's 'Install' action aligns with. The description adds minimal behavioral context beyond this, such as platform-specific file requirements implied by the schema but not explicitly stated. It doesn't contradict annotations, but offers little extra insight into effects like app overwriting or installation time.
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 ('Install an app on mobile device') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive operation with 2 parameters), the description is minimal but adequate with annotations covering the destructive hint and schema covering parameters. However, without an output schema, it doesn't explain return values or potential errors, and it misses usage context, leaving gaps in completeness for effective agent 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?
With 100% schema description coverage, the input schema fully documents both parameters ('device' and 'path'), including their purposes and formats. The description adds no additional meaning beyond what's in the schema, such as clarifying parameter interactions or constraints, so it meets the baseline for high coverage without compensating value.
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 resource ('app on mobile device'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'mobile_launch_app' or 'mobile_uninstall_app' beyond the basic action, missing specific scope or constraints that would make it fully distinctive.
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' for starting an already installed app or 'mobile_uninstall_app' for removal. It lacks context about prerequisites (e.g., needing a device from 'mobile_list_available_devices') or exclusions, leaving usage unclear.
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, indicating potential side effects, but the description adds minimal behavioral context beyond the basic action. It doesn't explain what 'destructive' entails (e.g., might interrupt apps, change device state) or mention rate limits, permissions, or error conditions. With annotations covering safety, the description meets a low bar but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words—'Press a button on device' directly conveys the core action. It's front-loaded and appropriately sized for a simple tool, avoiding unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive action with device interaction), no output schema, and rich schema coverage, the description is minimally adequate. It covers the basic purpose but lacks context on outcomes (e.g., what happens after pressing), error handling, or integration with siblings like mobile_list_available_devices. Annotations help, but more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear docs for 'device' and 'button' parameters, including supported button values. The description adds no extra semantic meaning beyond what's in the schema (e.g., no examples of button usage or device constraints). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press') and target ('a button on device'), which is specific and unambiguous. It distinguishes from siblings like mobile_click_on_screen_at_coordinates or mobile_type_keys by focusing on button interactions rather than screen taps or keyboard input. However, it doesn't explicitly mention device types (e.g., Android vs. iOS) or differentiate from mobile_swipe_on_screen, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be connected), exclusions (e.g., not for virtual buttons), or compare to siblings like mobile_double_tap_on_screen. The input schema hints at device availability via mobile_list_available_devices, but the description itself lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, indicating this tool performs a destructive operation (likely writing a file). The description adds that it saves to a file, which aligns with the destructive hint but doesn't provide additional behavioral context such as file format, overwrite behavior, or error handling. 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive operation with two parameters) and lack of output schema, the description is minimally adequate. It covers the basic action but misses details like output format, error conditions, or differentiation from siblings, leaving gaps for the agent to infer.
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 clear descriptions for both parameters (device identifier and save path). The description doesn't add any semantic details beyond what the schema provides, such as file format expectations or device availability constraints, so it meets the baseline 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 ('Save a screenshot') and the resource ('mobile device to a file'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from 'mobile_take_screenshot' in the sibling list, which appears to be a similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mobile_take_screenshot' or other mobile interaction tools. The description lacks context about prerequisites, timing, or exclusions, leaving the agent without usage direction.
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 destructiveHint=true, so the agent knows this is a destructive operation. The description adds minimal context beyond this - it confirms the destructive nature ('terminate') but doesn't elaborate on what termination entails (e.g., force stop vs graceful shutdown, whether data is preserved, permissions required, or potential side effects). 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 a single, efficient sentence that communicates the core purpose without unnecessary words. It's front-loaded with the essential action and resource, making it immediately scannable and understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with good schema coverage but no output schema, the description is minimally adequate. It identifies the tool's purpose and destructive nature, but lacks details about what termination means operationally, success/failure indicators, or error conditions. The annotations cover the safety profile, but more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, both parameters are fully documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stop and terminate') and resource ('an app on mobile device'), making the purpose immediately understandable. It distinguishes from siblings like mobile_launch_app (which starts apps) and mobile_uninstall_app (which removes apps), though it doesn't explicitly mention these distinctions in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when termination is appropriate versus other app control methods, nor does it reference sibling tools like mobile_launch_app or mobile_uninstall_app for context. The input schema hints at mobile_list_available_devices for device discovery, but this isn't explicit usage 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?
The annotation destructiveHint=true already indicates this is a mutation operation. The description adds minimal behavioral context by specifying 'into the focused element,' which clarifies the target but doesn't elaborate on side effects, error conditions, or interaction patterns. 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters, destructive operation, no output schema), the description is minimally adequate. It covers the basic action but lacks details on error handling, what 'focused element' means contextually, or how it integrates with other mobile interaction tools, leaving gaps for an agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all three parameters (device, text, submit). The description adds no additional parameter semantics beyond what the schema provides, such as examples or edge cases, so it meets the baseline 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 ('Type text') and target ('into the focused element'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like mobile_press_button or mobile_click_on_screen_at_coordinates, which might also input text in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a focused element), exclusions, or comparisons to sibling tools like mobile_press_button for submitting forms or mobile_click_on_screen_at_coordinates for interacting with specific UI elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true, indicating potential side effects. The description adds context by specifying 'in browser on device,' which clarifies the action's scope, but doesn't elaborate on what 'destructive' entails (e.g., interrupting current app, requiring permissions). It doesn't contradict annotations, but offers limited behavioral details 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, destructive hint, no output schema), the description is minimal but functional. It covers the basic action but lacks details on outcomes, error handling, or integration with sibling tools like mobile_list_available_devices, leaving some gaps in 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%, with clear parameter descriptions in the schema. The description doesn't add meaning beyond the schema, as it doesn't explain parameter interactions or usage nuances. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a URL') and target ('in browser on device'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like mobile_launch_app or mobile_install_app, which might also involve opening applications or content on the device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for opening URLs in a browser context on a mobile device, but doesn't explicitly state when to use this tool versus alternatives like mobile_launch_app for apps or other navigation tools. It provides basic context but lacks explicit exclusions or comparisons with 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 declare readOnlyHint=true, indicating a safe read operation. The description adds context about including physical devices and simulators and the need for user selection if multiple devices are returned, which is useful beyond annotations. However, it doesn't detail behavioral aspects like rate limits, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a practical note on user selection. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no meaningful parameters, read-only operation), annotations cover safety, and the description adds necessary context about device types and user interaction. Without an output schema, it could benefit from details on return format, but it's largely complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (noParams) with 0% description coverage, but the description compensates by implying no parameters are needed for listing devices. Since there are effectively 0 meaningful parameters, the baseline is 4, as the description adequately conveys that no inputs are required.
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 ('List') and resource ('available devices'), specifying it includes both physical devices and simulators. It distinguishes from siblings like mobile_list_apps by focusing on devices rather than apps, though it doesn't explicitly contrast with all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to list devices, with a note about user selection if multiple are returned, but lacks explicit guidance on when to use this vs. alternatives like mobile_get_screen_size or prerequisites. It provides some context but no clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, which already indicates this is a potentially disruptive operation. The description adds context by specifying it's for launching apps on mobile devices, but doesn't elaborate on behavioral traits like whether it requires device permissions, if it affects other running apps, or any rate limits. With annotations covering the destructive nature, the description provides basic context but lacks richer 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?
The description is extremely concise and front-loaded: the first sentence states the core purpose, and the second provides essential usage guidance. Every sentence earns its place with no wasted words, making it easy for an AI agent to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, destructive operation) and the absence of an output schema, the description is reasonably complete. It covers the purpose, basic usage, and parameter context. However, it could be more comprehensive by addressing potential side effects or error conditions, especially since it's marked as destructive.
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 (device and packageName) fully documented in the schema. The description adds minimal value beyond the schema by mentioning that package names can be found via list_apps_on_device, but doesn't provide additional semantic context about parameter usage or constraints. This 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 ('Launch an app') and resource ('on mobile device'), making the purpose immediately understandable. It distinguishes itself from siblings like mobile_install_app and mobile_terminate_app by focusing on opening apps rather than installing or closing them. However, it doesn't explicitly contrast with mobile_open_url, which might also open apps via URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to open a specific app on a mobile device. It also offers guidance on prerequisites by mentioning that package names can be found using list_apps_on_device. However, it doesn't explicitly state when NOT to use it or name alternatives like mobile_open_url for URL-based app launching.
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 context beyond annotations: it indicates a change operation ('change the screen orientation'), which aligns with the destructiveHint: true annotation (implying a state-altering action). It doesn't contradict annotations, and while annotations cover the destructive nature, the description clarifies the specific behavioral effect (orientation change) without detailing side effects like screen refresh or app state impacts, which could be useful but aren't required for a good score.
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, direct sentence ('Change the screen orientation of the device') that front-loads the core action and resource without unnecessary words. It efficiently conveys the purpose without redundancy or fluff, making it easy for an agent to parse and apply quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, destructive operation), annotations provide safety context (destructiveHint: true), and schema covers parameters fully. The description adequately explains what the tool does, though it lacks output details (no output schema) and doesn't fully guide usage relative to siblings. For a state-changing tool with good schema support, this is reasonably complete but could benefit from more explicit sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents both parameters (device and orientation with enum values). The description adds no additional parameter semantics beyond what's in the schema, such as explaining orientation effects or device requirements. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't compensate or enhance understanding further.
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 ('change') and target ('screen orientation of the device'), making the purpose immediately understandable. It distinguishes from siblings like mobile_get_orientation (which reads rather than sets) and mobile_list_available_devices (which lists devices). However, it doesn't explicitly mention the specific resource (device) beyond the general 'device', which slightly limits differentiation from tools like mobile_click_on_screen_at_coordinates that also target devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the parameter descriptions in the schema (e.g., 'Use mobile_list_available_devices to find which devices are available'), but the description itself lacks explicit guidance on when to use this tool versus alternatives. It doesn't state prerequisites like needing a device identifier from mobile_list_available_devices or contrast with mobile_get_orientation for read operations, leaving the agent to infer context from the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, indicating potential side effects. The description adds context by specifying the action is a 'double-tap' gesture, which implies it might trigger UI interactions (e.g., opening apps, confirming actions). However, it doesn't detail specific risks (e.g., data loss) or rate limits beyond the annotation's safety warning.
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 directly states the tool's function without unnecessary words. Every part ('Double-tap on the screen at given x,y coordinates') is essential and earns its place, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive action with 3 parameters), no output schema, and rich annotations, the description is mostly complete. It clearly defines the action but lacks details on expected outcomes (e.g., what happens after double-tap) or error conditions. However, annotations cover safety, and schema covers parameters adequately.
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 clear descriptions for device, x, and y parameters. The description adds no additional semantic meaning beyond the schema, such as coordinate system details (e.g., origin at top-left) or device selection tips. Baseline score of 3 is appropriate as the schema fully documents 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 specific action ('double-tap') on a specific resource ('screen') at specific coordinates ('given x,y coordinates'). It distinguishes from siblings like mobile_click_on_screen_at_coordinates (single tap) and mobile_long_press_on_screen_at_coordinates (long press) by specifying the double-tap gesture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for double-tapping at coordinates but doesn't explicitly state when to use this vs. alternatives like single tap or long press. It provides no guidance on prerequisites (e.g., device must be unlocked) or exclusions (e.g., not for scrolling). Usage is contextually implied but not explicitly defined.
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, indicating a safe read operation. The description adds no behavioral traits beyond this (e.g., performance, rate limits, or return format details). It doesn't contradict annotations, but provides minimal additional 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, efficient sentence with no wasted words, clearly front-loading the tool's purpose. It's appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter fully covered by schema and readOnlyHint annotation, the description is mostly complete. However, without an output schema, it doesn't specify the return format (e.g., dimensions structure), leaving a minor gap in 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%, with the parameter 'device' fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('screen size of the mobile device in pixels'), distinguishing it from siblings like mobile_get_orientation (orientation) or mobile_list_elements_on_screen (UI elements). It precisely defines what the tool retrieves.
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 implies usage when screen size information is needed, and the input schema's parameter description provides explicit guidance to use mobile_list_available_devices to find devices. However, it doesn't explicitly state when not to use this tool or name alternatives for related queries.
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, indicating this is a safe read operation. The description adds context by specifying it lists 'installed apps,' which clarifies the scope beyond just apps, but it doesn't disclose additional behavioral traits like rate limits, pagination, or error conditions. 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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words, making it highly concise and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, read-only annotation), no output schema, and simple purpose, the description is complete enough for an agent to use it correctly. It could be slightly improved by mentioning the output format, but the lack of an output schema doesn't severely hinder usability in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'device' parameter well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('List') and resource ('all the installed apps on the device'), and it distinguishes this tool from siblings like mobile_install_app, mobile_launch_app, and mobile_uninstall_app by focusing on listing rather than modifying apps.
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 implies usage for retrieving installed apps, and the input schema's description for the 'device' parameter references mobile_list_available_devices as an alternative for finding devices, providing clear context. However, it doesn't explicitly state when not to use this tool or compare it to all relevant siblings like mobile_list_elements_on_screen.
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, indicating this is a safe read operation. The description adds useful behavioral context beyond annotations by specifying 'Do not cache this result,' which informs the agent about data freshness expectations. However, it does not describe other behavioral traits like performance characteristics, error conditions, or output format 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?
The description is extremely concise and front-loaded, consisting of just two sentences that directly convey the tool's purpose and a key behavioral instruction ('Do not cache this result'). Every word earns its place with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing UI elements), the presence of annotations (readOnlyHint=true), and the lack of an output schema, the description is mostly complete. It clearly states what the tool does and adds a behavioral note, but it does not describe the structure or format of the returned element list, which could be helpful for an agent to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the device parameter fully documented in the schema itself. The description does not add any additional meaning or details about the device parameter beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List elements on screen'), the resource ('elements'), and the output details ('coordinates, with display text or accessibility label'). It distinguishes from siblings like mobile_click_on_screen_at_coordinates (which interacts with elements) and mobile_get_screen_size (which provides screen dimensions only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('List elements on screen and their coordinates'), and the input schema's device parameter description explicitly references the sibling tool mobile_list_available_devices for finding devices. However, it does not explicitly state when NOT to use this tool or compare it to all alternatives like mobile_take_screenshot for visual inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true, indicating this is a safe read operation. The description adds value by specifying what information is retrieved (screen orientation) and that it's current/real-time data. It doesn't contradict annotations, and while it doesn't mention rate limits or authentication needs, the annotations cover the safety profile adequately for this simple query 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, clear sentence that directly states the tool's purpose without any wasted words. It's front-loaded with the core functionality and appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter fully documented in the schema and readOnlyHint annotations, the description provides adequate context about what information is retrieved. The main gap is the lack of output schema, but the description implies the return value (orientation information), making it reasonably complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the single required 'device' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('current screen orientation of the device'), distinguishing it from sibling tools like mobile_set_orientation (which sets orientation) and mobile_get_screen_size (which gets screen dimensions). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need to know the device's orientation), and the input schema's parameter description provides guidance on how to obtain the device identifier via mobile_list_available_devices. However, it doesn't explicitly state when NOT to use this tool or compare it to alternatives like mobile_get_screen_size, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, indicating potential side effects, but the description adds valuable context by specifying that it's for clicking on coordinates and referencing element-based alternatives. It doesn't contradict annotations and provides additional behavioral insight beyond the destructive hint, though it could mention more about effects like app navigation or UI changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action in the first sentence and uses a second sentence for crucial guidance, with no wasted words. Every sentence adds value, making it efficient and well-structured for quick comprehension.
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 complexity (destructive action with 3 parameters) and lack of output schema, the description is mostly complete by stating the action, usage guidelines, and referencing related tools. However, it could improve by briefly mentioning expected outcomes or error cases, though annotations cover the destructive aspect adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents parameters (device, x, y). The description adds minimal semantics by implying coordinate-based interaction but doesn't provide extra details like coordinate ranges or device selection nuances. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Click on the screen') with the target resource ('at given x,y coordinates'), distinguishing it from siblings like mobile_double_tap_on_screen or mobile_long_press_on_screen_at_coordinates by specifying a single click action. It also references mobile_list_elements_on_screen for alternative use cases, enhancing differentiation.
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 provides when to use this tool ('Click on the screen at given x,y coordinates') and when not to ('If clicking on an element, use the list_elements_on_screen tool to find the coordinates'), offering clear alternatives and context for usage versus other tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, indicating potential side effects. The description doesn't contradict this (long pressing could trigger destructive actions like context menus or deletions), but it adds useful context about coordinate-based interaction and references another tool for element discovery. However, it doesn't elaborate on specific destructive outcomes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by a specific usage guideline. Every sentence adds value: the first defines the tool's purpose, and the second provides critical context for effective use. No wasted 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?
Given the tool's moderate complexity (coordinate-based interaction with destructive potential), the description is reasonably complete. It covers purpose, usage guidance, and references sibling tools. However, without an output schema, it doesn't describe return values (e.g., success/failure status), and behavioral details like error conditions are omitted, though annotations help with safety 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%, with clear descriptions for all parameters (device, x, y, duration). The description adds no additional parameter semantics beyond what's in the schema, such as coordinate system details or device selection nuances. Baseline 3 is appropriate given the comprehensive 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 specific action ('long press') on a specific resource ('screen at given x,y coordinates'), distinguishing it from siblings like mobile_click_on_screen_at_coordinates (single click) and mobile_double_tap_on_screen (double tap). It explicitly mentions the verb and target coordinates.
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 vs. alternatives: 'If long pressing on an element, use the list_elements_on_screen tool to find the coordinates.' This clearly differentiates it from element-based interactions and directs users to a sibling tool for coordinate discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation, which the description aligns with by not implying any destructive action. The description adds valuable behavioral context beyond annotations by specifying 'Do not cache this result,' which informs the agent about result handling, though it doesn't detail output format or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with three sentences that each serve a distinct purpose: stating the action, providing usage guidelines, and adding behavioral context. There is no redundant or unnecessary information, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, read-only), no output schema, and rich annotations, the description is largely complete. It covers purpose, usage, and a key behavioral note, though it could enhance completeness by mentioning the screenshot format or storage details, which are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'device' fully documented in the schema. The description does not add any additional semantic information about parameters beyond what the schema provides, such as device format or constraints, so it meets the baseline 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 verb ('take a screenshot') and resource ('mobile device'), specifying the action precisely. It distinguishes from sibling tools like 'mobile_list_elements_on_screen' by emphasizing visual capture rather than element listing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ('to understand what's on screen') and when not to use it ('if you need to press an element... then you must list elements on screen instead'), directly naming the alternative tool 'list elements on screen' for interaction purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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