mcp-android-emulator

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but tap_text and tap_element overlap significantly (both find by text and tap), and type_text vs set_text are similar. Descriptions help, but these pairs could cause misselection.
Naming Consistency4/5
Tool names are consistently snake_case with a verb_noun pattern, but there are minor deviations like 'screenshot' and 'device_info' instead of a 'get_' prefix. Overall pattern is predictable.
Tool Count2/5
With 42 tools, the set is significantly over-scoped for typical emulator interaction. Many granular gesture variants (tap, tap_safe, tap_element, double_tap, multi_tap, long_press) could be consolidated.
Completeness4/5
The set covers core emulator workflows well: UI inspection, gestures, text input, app management, waiting, and assertions. Minor gaps exist (e.g., long-press by element selector, screenshot comparison) but are workaroundable.
Average 3.5/5 across 36 of 42 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'Get information' without explaining what information is returned, whether any permissions are required, or what the response format is. The description adds no behavioral context beyond the tool's name, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence making it concise in size. However, it is under-specified and lacks useful detail, so it does not fully earn its place. It is not verbose, but it could be more informative without significantly increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description needs to compensate by explaining what 'information' includes. It does not mention device model, OS version, or any specifics, and the lack of an output schema makes the return value uncertain. This incompleteness is problematic when selecting among sibling tools.
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, so the schema is fully covered (100% coverage). The description appropriately adds no parameter details because there are none to describe. This aligns with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Get information about the connected device'), which is more than a tautology. However, 'information' is vague and does not distinguish this tool from siblings like get_screen_size or get_ui_tree, which also provide device-related information. The purpose is clear at a high level but lacks specificity.
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. The description provides no context, exclusions, or mention of other tools, leaving the agent without direction for selecting this tool among the many siblings listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself, but it only repeats the tool's name. It fails to mention the optional duration parameter, whether coordinates are absolute or relative, or how the gesture interacts with the UI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it concise. However, its brevity means it also lacks informative content, so it is not particularly helpful beyond being brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (five parameters, no output schema), the description is too sparse to provide adequate context. The agent must infer the tool's purpose from the name and schema, and there's no guidance on behavioral expectations or selection among siblings.
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 thoroughly describes all five parameters with ranges and descriptions, so the description adds no extra parameter semantics. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as a swipe gesture on the screen, which is a specific verb and resource. However, it doesn't distinguish from similar gestures like drag or scroll, which may also involve coordinates. Lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description doesn't explain when to use swipe versus alternative tools such as scroll or drag, nor does it mention any prerequisites like screen state or element visibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not explain what happens on failure (e.g., error, assertion exception), whether it scrolls or waits, case sensitivity, or how the 'exact' parameter affects behavior. This is a significant gap for an assertion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded, but the parenthetical '(useful for testing)' adds little and the wording could be more informative. It is concise but not optimally structured for an agent needing behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must convey key behavioral aspects, but it omits failure behavior, exact-match semantics, and any mention of waiting or scrolling. This is incomplete for a tool that executes a test assertion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add anything beyond the schema; 'specific text' merely echoes the parameter name. No extra meaning is provided for the 'exact' boolean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Assert') and target ('specific text is visible on screen'). It distinguishes itself from query tools like get_all_text and get_ui_tree, but does not explicitly contrast with similar assertion or visibility tools (e.g., is_element_visible), so it falls short of a 5.
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 only a vague context ('useful for testing') with no guidance on when to choose this tool over alternatives like wait_for_element or get_all_text. It does not mention under what conditions to use the 'exact' parameter or any 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'clear all data' which implies a destructive operation, but it does not explain that this is irreversible, whether the app must be closed, what permissions are required, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that leads with the verb and resource, making it efficient and easy to scan. However, it is arguably under-specified, missing important safety or context information; yet that is more a completeness issue than a conciseness flaw.
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?
This is a destructive tool with no annotations, no output schema, and only one parameter. The brief description does not outline prerequisites, expected outcomes, or side effects, leaving significant gaps for an agent trying to understand the full impact of invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'package' with its own description ('Package name of the app'), covering 100% of schema parameters. The description does not add any extra meaning beyond what the schema already provides, so it rests at 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 'Clear all data for an application' clearly states a specific verb and resource, making the tool's primary function obvious. It is distinct from sibling tools like force_stop or clear_input, but it does not explicitly acknowledge or differentiate from those alternatives, so it stops short of a 5.
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 situations where this tool is appropriate or inappropriate, nor does it name any sibling tool that could be used instead. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does not disclose details such as coordinate system (absolute vs relative), the timing between taps, or the expected system response. The phrase 'double tap' implies a gesture but omits behavioral nuances that could affect interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. No waste, but it is slightly under-specified for a tool with behavioral nuances. Still, it earns credit for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the basic function and the schema covers parameters. However, it lacks usage guidelines and behavioral transparency, and it does not differentiate from numerous sibling tools, leaving gaps for an AI agent trying to select the correct action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'x' and 'y' as coordinates with 100% coverage. The description merely restates 'at the specified coordinates', adding no new meaning about units, origin, or how the parameters influence the gesture. Baseline 3 applies because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Perform a double tap') and specifies the target ('at the specified coordinates'), clearly identifying the tool's function. It distinguishes itself from the sibling 'tap' by using 'double tap', though it does not explicitly contrast with 'multi_tap'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives like 'tap' or 'long_press'. The description lacks any contextual guidance or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what it gets, not the return format, potential failure modes, or side effects. It implies a read-only operation but provides no behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence. It is appropriately sized for a simple getter, though slightly more detail could be included without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no parameter context, the description is incomplete. It does not explain what the returned activity/screen looks like, when it might be null, or how it relates to other UI inspection tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is effectively 100%. The baseline for 0-param tools is 4, and the description adds no parameter information since none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the currently focused activity/screen, with a specific verb and resource. It distinguishes from siblings like get_ui_tree (hierarchy) and get_focused_element (element details), though it doesn't explicitly name alternatives and 'activity/screen' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as when to prefer get_ui_tree or get_focused_element. No context or exclusions are 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?
With no annotations, the description carries the full burden of disclosure. 'Force stop' implies abrupt termination but does not mention whether app data is preserved, what side effects occur, or any prerequisites. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at five words, with every word contributing meaning. There is no redundancy or irrelevant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-parameter tool with complete schema coverage, but lacks usage context and side-effect details. It is minimally viable but leaves gaps in guidance and behavioral disclosure.
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% coverage, already describing the package parameter with a clear definition. The description adds no additional semantic value beyond the schema, so the baseline 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 clearly states the action (force stop) and the resource (an application). It is distinct from siblings like launch_app and clear_app_data, but does not explicitly contrast with them.
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 clear_app_data or launch_app. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says 'get information' without disclosing what specific fields are returned, what happens when there is no focused element, or 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?
The description is a single short sentence with no redundancy or padding. It is front-loaded and immediately communicates the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should specify what 'information' is returned, but it does not. This makes the tool's output behavior unclear for an agent selecting and invoking it.
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, so the schema already provides complete coverage. Baseline for zero-parameter tools is 4; no additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets information about the currently focused UI element, using a specific verb and resource. However, it does not distinguish this from sibling tools like get_focused_input_value or get_ui_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_focused_input_value or get_clickable_elements, and no exclusion criteria or context is 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'rapid' but does not clarify default tap count or interval, nor any side effects or prerequisites. The behavior of the taps parameter (e.g., what happens if omitted) is left entirely to the schema, which is insufficient for a tool that could be used in varied automation contexts.
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 information. It efficiently conveys the core action and position, making it easy for an agent to process 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?
The tool is simple and the schema covers all parameters (including defaults), so the description need not explain return values. However, the absence of usage context and behavioral details (defaults, differentiation from siblings) leaves the description minimally viable but not fully informative for agents that need to choose among similar tap tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond 'rapid', which loosely corresponds to the interval parameter but does not specify or enhance understanding of the parameters. It neither hinders nor significantly helps beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('perform multiple rapid taps') and location ('same position'), distinguishing it from single tap (tap) and double tap (double_tap) in scope. However, it does not explicitly name alternative tools or highlight the customizability of the tap count, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like tap or double_tap. The context of 'multiple rapid taps' implies a use case, but there is no 'use when' or 'instead of' language, leaving the agent to infer the appropriate scenario.
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?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It only states the action and direction, but does not explain how scrolling behaves (e.g., default amount, whether it scrolls the entire viewport or a focused element, or whether it is a continuous or discrete scroll). This is very thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and target. It contains no fluff or repeated information, making it maximally concise.
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 tool with only two parameters and no output schema, the description plus schema may be minimally adequate for invocation. However, the absence of usage guidelines and behavioral context means the description is not fully complete for selecting the right tool among many similar UI interaction siblings.
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 covers both parameters (direction with enum, amount with default 500) and has 100% description coverage. The description adds no param-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll the screen in a direction' clearly identifies the action (scroll), target (screen), and a modifier (direction). However, it does not explicitly distinguish from sibling tools like swipe or scroll_to_text, so it falls short of a full 5.
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 swipe, drag, or scroll_to_text. There are no exclusions, prerequisites, or context hints, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a meaningful trait: filtering is applied in-process, not on the device shell. However, it omits return format, potential side effects, and permission requirements, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences front-load the core purpose and add a relevant behavioral detail. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and parameters are fully documented, but no output schema exists. The description doesn't state what the tool returns (e.g., list of log lines) or provide usage context. Adequate for a basic getter, but with real gaps.
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 each parameter well-described. The description's in-process filtering note is already mirrored in the filter parameter's schema description, so it adds no new semantic info. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('device logs (logcat)'), and adds a specific detail about filtering. It is distinct from sibling tools, which focus on UI interaction and device control. However, it doesn't name any alternative log tool, but none appear to exist among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or alternatives. The note about in-process filtering hints at a behavioral difference, but it doesn't explain when an agent should choose this over other tools or what scenarios it's suited for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only restates the basic action. It does not disclose behavioral details such as coordinate system origin, error handling for out-of-bounds coordinates, return values, or 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?
A single clear sentence with no filler words. Everything present serves to convey the tool's function.
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 integer parameters and no output schema, so a brief description is acceptable. However, it lacks any mention of usage context or behavioral specifics that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters fully with descriptions ('X coordinate', 'Y coordinate'), so the description adds no additional meaning. Baseline of 3 is appropriate given 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 a specific action ('Tap') applied to a clear resource ('the screen at specified coordinates'). This distinguishes it from sibling tools like tap_element or tap_text which target UI elements rather than raw coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use coordinate-based tapping versus alternatives like tap_element or tap_safe. The description mentions coordinates but does not state when this is preferred or when another tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the basic function and fails to disclose what the tool returns, how it behaves when the element is not found, whether it waits or is non-destructive, or any error handling. This is a significant gap for a check 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 is front-loaded with the core function. Every word earns its place, and there is no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description should explain return values and behavioral nuances. It does neither. For a simple tool, it lacks critical details such as what is returned (e.g., boolean), and the parameter combination rule (at least one required). This makes it less complete than expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters (text and resourceId), so baseline is 3. The description adds the word 'or', implying one of them is used, but it does not clarify whether both can be provided or how they combine. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check if an element with specific text or resource-id is visible on screen'. It uses a specific verb ('check') and specifies the resource (element) and the condition (visible). It also distinguishes itself from siblings like wait_for_element (which waits) and assert_screen_contains (which asserts) by focusing on visibility rather than mere existence.
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 checking visibility, but it does not explicitly state when to use this tool versus alternatives. There are no exclusions or references to sibling tools. The guidance is only implied through the tool's purpose, not explicitly 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core 'wait for appear' action, but omits critical behaviors: what happens on timeout (error vs false return), whether text matching is exact/substring, and whether it waits if the element is already visible. This is a significant gap for a wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to the core meaning.
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?
Despite having complete parameter documentation, the tool lacks an output schema or annotations, and the description does not explain return values or failure behavior. For a wait tool, knowing what happens on timeout is essential; this omission leaves the tool under-specified for an agent to handle errors correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'text' and 'timeout' already documented. The description adds minimal semantic value beyond the schema (only 'specific text'), 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 the specific verb 'Wait for' and clearly identifies the resource: a UI element with specific text, with the outcome 'to appear'. This distinguishes it from related tools like wait_for_element_gone ('disappear') and is_element_visible (immediate check).
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 waiting until an element appears, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and does not disclose timeout behavior, polling interval, exception handling, or what happens if the element never disappears. This is a significant lack of transparency for a waiting operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the core function. It is front-loaded and contains no irrelevant information, earning a top score for conciseness.
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 documents parameters, the description lacks essential context about timeout handling and return values. With no output schema, the description should clarify what happens on success/failure, but it simply says 'wait for disappearance' without addressing these 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?
The input schema already describes both 'text' and 'timeout' with specific details (text purpose, timeout range and default). The description adds no additional parameter semantics, but the schema's 100% coverage justifies a 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 'wait for' and the resource 'an element' with condition 'disappear', clearly distinguishing it from the sibling tool wait_for_element. It is a precise, unambiguous statement of the tool's function.
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 an element needs to be gone from the screen before continuing. However, it does not explicitly mention alternative tools such as wait_for_element or is_element_visible, nor does it provide exceptions or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply says 'Clear' but does not mention that maxChars limits deletion to a maximum (default 100), meaning the field may not be fully cleared if it exceeds that length. It also omits behavior when no field is focused, such as whether it errors or does nothing.
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 with no wasted words. It front-loads the action and object, making it immediately scannable and easy to understand.
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 tool with one optional parameter and no output schema, the description is minimally adequate but incomplete. It fails to clarify the maxChars default limitation or the behavior when there is no focused input, which could lead an agent to invoke it incorrectly or misinterpret the result.
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 single parameter maxChars is already fully documented in the input schema with type, range, and default. The description adds no further meaning about how this parameter affects the clearing behavior, so it meets the baseline but does not exceed it.
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 ('Clear') and a precise resource ('currently focused text input field'), making the tool's function immediately clear. It distinguishes itself from siblings like type_text or set_text by targeting only the focused input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when a text input is focused and needs to be cleared—but it does not explicitly state when not to use it or mention alternatives such as set_text for replacing content. The context is understandable but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool gets bounds and center; it does not mention what happens if the element is not found, whether coordinates are in pixels or dp, whether the element must be visible, or any other behavioral traits. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to the core purpose, 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 has no annotations and no output schema, and the description is very brief. It explains the core function but omits details such as the return format, failure behavior, and how the element is matched when multiple parameters are provided. For a simple getter, this is minimally adequate but leaves room for improved 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?
The input schema provides 100% coverage for all three parameters (text, index, resourceId) with clear descriptions. The tool description adds no additional meaning beyond the schema, 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 ('Get') and names the resource ('element') and the exact output ('bounds and center coordinates'). This clearly distinguishes the tool from siblings like 'get_ui_tree' (which returns the tree) or 'get_screen_size' (which returns screen dimensions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need an element's bounds/center) but provides no explicit guidance on when to choose this over alternatives, no exclusions, and no mention of prerequisites such as element visibility. It is not misleading, but it lacks direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the core action but omits any side effects, potential failure modes, or permission requirements. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and includes the key parameter options. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but could benefit from noting behavioral aspects like whether the rotation is immediate, whether it triggers any side effects, or whether it fails on unsupported orientations.
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% coverage, with the parameter fully described ('Target orientation') and its enum values defined. The description merely restates the enum values ('portrait or landscape'), adding no new semantic detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (rotate) and resource (device), and clearly states the orientation options. It distinguishes itself from all sibling tools, none of which are rotation-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need to change device orientation. However, it provides no explicit when-not-to-use guidance or references to alternative tools, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions avoiding navigation bars. It omits the status bar avoidance (shown in the schema as default true) and does not explain what happens if coordinates fall within the avoided areas. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, and every word adds value. It is 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 description is adequate for a simple tap tool, especially with a fully documented schema. However, it lacks behavioral details about status bar avoidance and edge-case handling, and does not clarify the distinction from the 'tap' sibling beyond the basic avoidance feature.
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 all four parameters, so the schema already documents parameter semantics. The description adds no extra syntax or format details beyond the schema, so a 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 clearly states the action ('Tap at coordinates') and the distinguishing feature ('while avoiding system navigation bars'), differentiating it from the sibling tool 'tap'. This is a specific verb+resource with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when tapping at coordinates that might overlap with system navigation bars, but it does not explicitly compare with the 'tap' sibling or state when not to use it. The usage context is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only mentions the high-level action (find and tap) but omits key behaviors such as partial match handling, what happens on multiple matches, whether the tool scrolls to the element, and failure behavior. The schema documents the exact parameter but the description itself adds little beyond the core action.
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 is front-loaded with the action and object. Every word earns its place, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two params, no output schema), but the description misses behavior that would be relevant in the context of sibling tools, such as whether the tap is performed directly or after scrolling/waiting. The description provides only the essential purpose but lacks detail on edge cases or additional semantics, making it adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema: it simply restates the text parameter's purpose ('find by text content'). The 'exact' parameter's semantics are entirely explained in the schema and not enriched by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Find an element by its text content and tap on it') with a clear resource (element) and method (text content). This distinguishes it from sibling tools like 'tap' (which typically uses coordinates) and 'tap_element' (which likely uses a selector).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you want to tap an element identified by its visible text, but it does not explicitly state when to use this tool versus alternatives such as 'tap_safe' or 'tap_element'. No exclusions or alternative recommendations are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects (e.g., POWER may lock the screen, VOLUME_UP changes volume) or whether the key event is simulated. This minimal disclosure is a gap for a system-level action.
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 efficiently conveys the action and examples while remaining concise.
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 action with no output schema, the description is largely complete. The schema fully documents the key parameter. The only omission is potential side effects of specific keys, but given the tool's simplicity, the description 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 already has 100% coverage with an enum and a description ('Key to press'). The tool description adds the phrase 'system key' and examples, but this is marginal and does not significantly enhance meaning beyond the schema, 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 states a specific verb ('Press') and resource ('system key'), with examples (BACK, HOME, ENTER) that clarify the scope. This clearly distinguishes it from sibling tools like tap (which presses coordinates) and type_text (which sends text input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever a system key press is needed) but does not explicitly mention alternatives or exclusion criteria. It is adequate for a simple tool but lacks explicit guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure, but it only states the action without any side effects, conditions, or failure behavior (e.g., what happens if no input is focused). This lack of extra context makes it difficult for the agent to anticipate the tool's behavior in edge cases.
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 immediately conveys the action and target. It contains no fluff or redundant phrasing, making it highly concise 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—no parameters, no output schema, no annotations—the description fully specifies the operation in a single sentence. While it omits edge-case context like 'requires a focused input,' the simplicity of the action means the basic description is largely sufficient for an agent to understand and invoke it.
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, so the schema is trivially complete and the description need not elaborate on argument semantics. The baseline of 4 is appropriate since no parameter information is required.
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 ('Select all text') and the target resource ('currently focused input field'), making the tool's purpose unambiguous. It also distinguishes from siblings like clear_input and type_text, which perform different operations on the same resource.
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 clear_input or set_text. It does not mention scenarios like overwriting existing text or prerequisites (e.g., focusing an input field first), leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It warns about shell metacharacters, implying a shell-based operation, but does not disclose side effects such as overwriting an existing app, required permissions, or success/failure behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It states the purpose first, then the key constraint, with no wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description is adequate but not comprehensive. It provides the essential path precondition but omits details about return values, error conditions, or installation side effects. For a simple install tool, this is sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'path' as 'Path to the APK file on the host', so coverage is 100%. The tool description adds valuable constraints beyond the schema: the path must end in .apk and contain no shell metacharacters. This enhances parameter understanding.
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: 'Install an APK file on the device.' The verb 'Install' and resource 'APK file on the device' are specific and unambiguous. No other sibling tool performs this action, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (installing an APK) but does not explicitly state when to use it vs. alternatives or provide exclusions. The path constraint ('must end in .apk and contain no shell metacharacters') gives important preconditions but not broad usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It notes the Android 8+ requirement but does not disclose other behavioral traits such as how the gesture is performed (e.g., whether it uses two fingers, whether it requires a stable UI, or how scale relates to screen coordinates). This is a minimal disclosure for a gesture tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the action and a key prerequisite. No wasted words; it is appropriately minimal for a tool whose parameters are fully described in the schema.
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 gesture tool with a fully self-describing schema, the description is minimally sufficient. However, it lacks context about return values (though no output schema is provided) and does not mention how this tool relates to other gestures or when the Android version matters. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters including center coordinates, scale factor, and duration. The description adds no extra meaning, but the schema fully compensates, and the baseline for high coverage is 3; a small bonus is given because the scale parameter's semantics (>1 zoom in, <1 zoom out) are explicitly clear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Perform') and resource ('pinch zoom gesture'), clearly distinguishing it from sibling gesture tools like swipe, drag, and double_tap. The Android 8+ requirement adds a useful constraint 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a gesture tool but does not explicitly state when to use pinch zoom versus alternatives (e.g., zoom via buttons or double_tap). The Android version requirement is a form of prerequisite guidance, but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (scroll until visible) but omits important details such as what happens if the element is never found after max scrolls, whether it respects the 'direction' parameter, and any side effects. With no annotations, the description carries the full burden and falls short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and purpose. No unnecessary words 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?
The tool has 3 parameters, no output schema, and no annotations. The description clearly explains the tool's goal but does not address what happens on success/failure, how direction and maxScrolls affect behavior, or return values. It is adequate for a simple scroll tool but lacks edge-case 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?
The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add any additional meaning beyond the schema; it only restates the 'text' concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (scroll) and resource (element with specific text), with a clear stopping condition (until visible). It distinguishes itself from the sibling 'scroll' tool, which presumably scrolls by offset, and from 'tap_text' which would tap rather than scroll.
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 its use case: when you need to bring an element with specific text into view. However, it provides no explicit guidance on when to use this over alternative tools like 'scroll' or 'tap_text', nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It states what it does but doesn't disclose failure behavior, waiting/timeout behavior, or side effects beyond tapping. The reliability note is comparative, not a disclosure of how the tool behaves internally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with core action, includes the comparative advantage without waste. Perfectly concise.
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 4-param tool with no annotations and no output schema, the description is adequate but minimal. It covers core purpose and a comparative advantage, but lacks details on precedence when both text and resourceId are given, error handling, or element-not-found behavior.
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 covers all four parameters with descriptions (text, exact, index, resourceId), so description adds no new parameter semantics beyond echoing text and resource-id. Baseline 3 applies due to 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?
Clear verb+resource: 'Find and tap an element by text or resource-id' distinguishes from sibling tap_text by noting higher reliability. Also specifies the two key search modes.
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 positions itself against tap_text ('more reliable than tap_text'), giving clear preference context. Doesn't delineate when not to use it or mention alternatives like coordinate-based tap, but the comparative note provides actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the core function ('get all visible text elements') without explaining return format, behavior regarding empty text, or whether it operates on the accessibility tree. Minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a parenthetical use case. No wasted words, all necessary information is front-loaded. Very concise 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?
For a simple read-only tool with one optional parameter and no output schema, the description is mostly sufficient but lacks explicit statement of return type. Slightly more detail (e.g., 'returns list of strings') would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for the single parameter includeEmpty, with a clear description in the schema. The tool description does not mention parameters, but since schema already handles semantics, 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?
Description uses specific verb 'Get' and resource 'all visible text elements on screen', clearly distinguished from siblings like get_ui_tree (which returns UI hierarchy) and screenshot (which returns an image). The scope is explicit and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'useful for debugging and verification' provides clear context on when to use the tool, but it does not explicitly mention alternatives or exclusions. This fits 'clear context, no exclusions' at a level 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral transparency. It only states a read operation ('get') without mentioning potential side effects, permission requirements, or what happens if the clipboard is empty or inaccessible. This lacks the depth expected for a tool with no annotation support.
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 conveys the tool's purpose. No filler or redundant information is present, and it is front-loaded with the verb and resource.
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 parameterless getter, the description is largely sufficient: it states the core function. However, with no output schema and no annotations, it leaves some uncertainty about the exact return format and edge cases (e.g., empty clipboard), making it slightly incomplete compared to a fully specified 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 tool has zero parameters, so there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description correctly avoids adding irrelevant parameter information.
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' and the resource 'device clipboard content'. It distinguishes itself from sibling tools like set_clipboard and other getters (e.g., get_screen_size) by specifying the unique clipboard resource.
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 intended usage is implied: use when you need the clipboard content. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites or exclusions. The description provides no context about formatting, permission needs, or when clipboard access might be restricted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely restates the return values and does not disclose any behavioral traits such as read-only nature, units (pixels/dp), or potential side effects. For a getter, more detail on return format would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundant words. It is front-loaded and gets straight to the point.
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 (no parameters, no output schema), and the description provides the core information. However, it lacks explicit units or return format, so it is slightly incomplete for an agent.
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, which is the baseline score of 4. Since there are no parameters, the description does not need to add parameter semantics.
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: getting the device's screen dimensions and density. This specific verb+resource combination distinguishes it from sibling tools like screenshot (captures an image) and device_info (broader device details).
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 (if you need screen dimensions, use this), but there is no explicit guidance on when to use this vs alternatives. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the result is returned as a base64 image, but it does not specify the image format (e.g., PNG vs JPEG), whether it captures the current visible screen, or any error conditions. For a simple read-only operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes the key detail about base64 output. It avoids any filler, redundancy, or unnecessary elaboration.
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 (no params, no output schema), the description adequately conveys the core purpose and return value. However, it omits the specific image format and any usage context, which slightly limits completeness relative to what an agent might need for a totally self-contained description.
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 trivially complete at 100%. With no parameters to explain, the baseline of 4 applies; the description does not need to add parameter meaning.
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 (take), the resource (Android device/emulator), and the output format (base64 image). It distinguishes the tool from siblings like get_ui_tree or get_clipboard by focusing on visual capture of the screen.
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 get_ui_tree or get_clipboard. It does not mention prerequisites, ideal scenarios, or any exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the transfer mechanism (adb push) and Unicode support, but does not cover side effects (e.g., overwriting existing clipboard), permissions, or failure modes. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose. The second sentence adds a technical detail without unnecessary verbosity. 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 one-parameter tool with no output schema and no annotations, the description is fairly complete. It conveys the action and the transfer method. Minor gaps include no mention of prerequsites (e.g., ADB availability) or return value, but these are implicit for a set 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 description coverage is 100%, so the schema already documents the 'text' parameter well. The description adds no additional parameter semantics beyond what the schema states ('Text to copy to clipboard'). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb+resource: 'Set text to the device clipboard.' This distinguishes it from the sibling tool get_clipboard and other text-related tools. The implementation detail about adb push further clarifies the operation.
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 does not explicitly state when to use this tool over alternatives or include exclusions. However, the mention of 'full Unicode support' and 'binary transfer' implies a use case for handling text with special characters or encoding, providing indirect 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?
With no annotations, the description carries the burden of behavioral disclosure. It states the action ('get') but does not mention edge cases, such as behavior when no input field is focused, whether it returns an empty string, or if it throws an error. The read-only nature is implied but not explicitly stated. This is basic functionality with limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no redundancy, filler, or extraneous detail. It is perfectly front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter getter, the description is complete. It specifies what is being retrieved (text value) and from where (focused input field). Without an output schema or complex behavior, no additional details are necessary for an agent to understand 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 the schema confirms this. The description does not need to explain parameters because there are none. Per the rubric, 0 params warrants a baseline score of 4. The description adds no parameter-related information, which 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 tool's function: 'Get the current text value of the focused input field'. The verb 'Get' and the resource 'current text value of the focused input field' are specific and unambiguous. It also distinguishes itself from sibling tools like 'get_focused_element' which retrieves the element, not its value.
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. There is no mention of exclusions, prerequisites (e.g., an input must be focused), or comparison to siblings like 'get_ui_tree' or 'get_all_text'. Usage must be inferred from the tool's name and description 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?
No annotations are provided, so the description carries the full burden. It discloses that the package name is validated against Android naming conventions, but does not mention failure behavior (e.g., app not installed), side effects, or permissions. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the action stated upfront and no redundant information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema, no annotations), the description covers the main purpose and validation, but lacks important context such as what happens if the app is not installed or any side effects. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description and pattern for the 'package' parameter, achieving 100% schema coverage. The description adds little beyond repeating the example and validation concept, so it does not significantly enhance parameter understanding beyond 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 clearly states the tool's action: 'Launch an application by its package name.' It uses a specific verb ('launch') and resource ('application'), and distinguishes it from siblings like install_apk and force_stop. The example package name adds clarity.
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 context is clear: use when you need to launch an app by its package name. However, it does not explicitly state when not to use it or mention alternatives (e.g., install_apk if the app is not installed) or preconditions like app installation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It usefully notes that the optional filter is applied in-process (JavaScript) rather than on the device shell, which prevents misinterpretation about shell execution. However, it does not state that the operation is read-only or describe any other behavioral traits, leaving some ambiguity about side effects and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a technical refinement. Every word earns its place, with no redundant or vague content. The structure is ideal for quick comprehension.
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 one optional parameter and no output schema. The description explains what the tool does and adds a behavioral note about filtering, but it does not describe the return format or whether system packages are included. Given the absence of an output schema, the agent would benefit from more details about the expected return value, leaving a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter's description already says 'Filter packages by name (optional)'. The tool description adds meaningful context about how the filter is executed—'applied in-process (JavaScript), never on the device shell'—which clarifies the filtering mechanism and security implications. This goes beyond the schema, justifying a score above 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 explicitly states 'List installed packages on the device' with a clear verb and resource. This tool is distinct from all sibling tools, as no other tool claims to list packages. The purpose is unambiguous and immediately actionable.
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 all installed packages need to be listed, but it does not explicitly state when to use this tool versus alternatives. No alternatives are mentioned, and no exclusions are given. The context of sibling tools suggests no overlap, but the lack of explicit guidance prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (waiting for UI stability) but does not state the outcome when the timeout is reached (e.g., whether it errors or returns a boolean). No annotation contradiction since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, direct, with a parenthetical giving context. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the return/error behavior on timeout. The output schema is absent, so the description should clarify what happens after the wait completes or times out. Otherwise, the description covers the main purpose and usage 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?
Both parameters (timeout, checkInterval) are fully described in the input schema with defaults and ranges. The description adds no additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Wait' with the resource 'UI' and specifies the condition 'stop changing'. This clearly distinguishes it from sibling tools like wait_for_element and wait_for_element_gone, which target specific elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a usage scenario: 'useful after animations'. This gives clear context for when to use the tool, though it does not mention exclusions or contrast with alternative wait 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds some context by highlighting the slower speed and drag-and-drop purpose, but it does not describe the internal gesture mechanics (press, move, release), coordinate system details, or any return value. This is minimal but not entirely absent.
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 immediately states the action ('Perform a drag gesture') and then adds a concise, valuable parenthetical ('slower than swipe, for drag & drop') that distinguishes it from a sibling. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate parameter set (5 params, 4 required) with complete schema descriptions, and no output schema. The description adds the key usage distinction from swipe and clarifies the drag-and-drop purpose. While it doesn't address return values or edge cases, the simplicity of the gesture and strong schema coverage make this reasonably 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 schema already provides descriptions for all five parameters (100% coverage), including starting/ending coordinates and duration with a default. The description does not add additional parameter-level meaning beyond what the schema already states, 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 clearly states the action: 'Perform a drag gesture from one point to another.' It identifies the resource (gesture) and the specific verb (perform), and it distinguishes this from the sibling tool 'swipe' by adding 'slower than swipe, for drag & drop,' which clarifies its unique purpose.
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 useful usage context by noting this is 'slower than swipe, for drag & drop,' implying it should be used for drag-and-drop interactions rather than fast swipes. However, it does not explicitly state when NOT to use it or list alternative tools beyond the implicit contrast with swipe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the return contents (text, resource-id, coordinates) and implies a read-only operation, but does not disclose potential side effects, prerequisites (e.g., accessibility service), or edge cases (e.g., off-screen elements). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and key output fields, and adds a practical use case. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is fairly complete: it defines the output content and a usage scenario. It lacks details on return structure (e.g., list vs. array) but the listed fields (text, resource-id, coordinates) give sufficient context for an agent to invoke and 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 one parameter (includeDisabled) with a description, giving 100% schema coverage. The tool description adds no parameter-specific meaning 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 tool's function: getting all clickable elements on screen with their text, resource-id, and coordinates. It uses a specific verb ('Get') and a resource ('clickable elements'), and the output details distinguish it from general UI tree tools.
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 a clear use case: when tap_text fails. This gives context for when to use the tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose that the tool returns clickable elements with coordinates, which is a behavioral detail. However, it does not clarify whether the full tree is returned or only the clickable subset, nor does it state that the operation is safe/read-only. This is a minor gap for a simple getter.
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-loading the core purpose ('Get the UI element tree') and using a helpful analogy ('like DOM but for Android') to add clarity. Every word earns its place; no fluff 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 parameterless tool with no output schema, the description covers the essential behavior and return content. The only ambiguity is whether the tree includes all elements or just clickable ones, which could confuse an agent. Otherwise, the description is sufficiently complete for the tool's simplicity.
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%, so there is nothing to explain. The description does not need to compensate for missing parameter information. The baseline of 4 applies because with no parameters the description fully covers the input side.
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 gets the UI element tree of the device, using the DOM analogy to make it immediately understandable. It also specifies the key output (clickable elements with coordinates), which distinguishes it from siblings like screenshot or get_clipboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting the UI hierarchy ('like DOM but for Android'), but it does not explicitly contrast with overlapping siblings such as get_clickable_elements or get_all_text. No exclusion criteria or alternative recommendations are provided, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core behavior (checking visibility) but does not explicitly mention that it returns a boolean, has no side effects, or is a non-destructive read operation. The description adds some clarity but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. Every word is meaningful and there is no superfluous 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?
Given the tool's extreme simplicity (no parameters, no output schema), the description provides sufficient context for an agent to understand its function. However, it does not explicitly state the return value (e.g., true/false), which would make it slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description does not need to add parameter information. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not detract from this.
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 ('Check') and resource ('soft keyboard visible on screen'). It is distinct from sibling tools like 'is_element_visible' by specifying the keyboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (checking keyboard visibility) but does not explicitly discuss when to use this tool versus alternatives or provide exclusions. Since the tool name is self-explanatory, the implied usage is acceptable but not thoroughly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains the core action and the intended effect (context menus), but it does not disclose whether the operation is blocking, how duration is applied, or any side effects beyond the gesture. The schema covers duration, but the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a helpful parenthetical. Every word earns its place, and the structure is immediately scannable.
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 gesture tool with no output schema, the description plus schema adequately covers the action, parameters, and a typical use case. It could mention that duration is optional (schema already does), but it provides enough context for an agent to select and invoke the tool. The parenthetical about context menus adds 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?
The input schema already provides full descriptions for all three parameters (x, y, duration with default). The description merely rephrases 'at the specified coordinates,' adding no new semantic information beyond the schema. Baseline is 3 because coverage is 100%.
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 ('Perform a long press') and the target ('at the specified coordinates'), plus a practical use case ('useful for context menus'). This distinguishes it from sibling tools like tap and double_tap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'useful for context menus' provides a clear use context, but it does not explicitly name alternatives or exclusion criteria. It implies when to use long press (for context menus) but doesn't contrast with tap or other gestures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool clears before typing, supports Unicode via URL-encoding, and rejects shell metacharacters—important behavioral traits beyond bare schema. It does not mention limits like maxClearChars behavior, but the disclosed traits are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The primary action is front-loaded, followed by two critical constraints. Ideal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema. The description covers purpose and key constraints. Minor gaps exist (e.g., precise meaning of 'current input field', behavior when exceeding maxClearChars), but overall it is complete enough for an agent to use 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?
Schema coverage is 100% with descriptions for both text and maxClearChars, so baseline is 3. The description adds semantics for the text parameter by noting Unicode URL-encoding and shell metacharacter rejection, which are meaningful constraints not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Clear the current input field and type new text.' This distinctively combines clearing and typing, differentiating it from siblings like 'clear_input' and 'type_text'. The verb-resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario (replacing existing text in a focused field) but does not explicitly mention when to use this tool over alternatives or when not to use it. No alternatives are named, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: Unicode support via URL-encoding and rejection of shell metacharacters. However, it does not mention error handling when no input is focused or whether typing replaces existing content.
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 primary action and followed by critical constraints. Every word adds value, with no redundancy 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?
For a single-parameter tool with no output schema, the description covers the essential behavior and constraints. It could add a note about error conditions or what happens if the field is not focused, but it is largely complete for typical automation use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes 'text' as 'Text to type', but the description adds meaningful semantic details: Unicode must be URL-encoded, and shell metacharacters are rejected. This goes beyond the schema and clarifies how the parameter should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Type text') and a specific target ('currently focused input field'), which clearly distinguishes it from other text-related tools like set_text or tap_text. It is unambiguous and action-oriented.
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 typing into a focused input field, but it does not explicitly compare with alternatives or say when not to use this tool. While the context is implied, there is no guidance on choosing this over set_text or press_key.
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-android-emulator MCP server](https://glama.ai/mcp/servers/Anjos2/mcp-android-emulator/badges/card.svg)](https://glama.ai/mcp/servers/Anjos2/mcp-android-emulator)

Score Badge

Copy to your README.md:

[![mcp-android-emulator MCP server](https://glama.ai/mcp/servers/Anjos2/mcp-android-emulator/badges/score.svg)](https://glama.ai/mcp/servers/Anjos2/mcp-android-emulator)

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/Anjos2/mcp-android-emulator'

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