scrcpy-agent

by EF-Code

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct actions across devices, mirroring, UI, apps, permissions, logs, and evidence. A few pairs like screen_tap/ui_tap and ui_find/ui_dump could be confused, but description distinctions are clear enough.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern of <domain>_<action>, such as device_list, mirror_start, screen_swipe, and evidence_begin, with no mixed conventions or style deviations.
Tool Count2/5
At 29 tools, the server exceeds the 25-tool threshold for a well-scoped toolkit. While each tool has a purpose, the large count suggests potential consolidation (e.g., evidence session tools, mirror control tools).
Completeness4/5
The toolset covers major areas of Android device interaction including device selection, mirroring, UI interaction, app lifecycle, permissions, logs, and evidence collection. Notable gaps include no app uninstall and no direct file operations, but these are workable for testing scenarios.
Average 3.3/5 across 29 of 29 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 231 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation declares the operation safe, and the description aligns with that. However, the description adds only the vague qualifier 'bounded' without explaining what it means or how filters (system, enabled, etc.) affect the result. No meaningful behavioral context beyond the annotation is disclosed.
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, making it concise in length, but it is under-specified rather than efficiently informative. The term 'bounded' adds ambiguity without earning its place, and the structure lacks both clarity and precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema and five optional filters, the description is too sparse. It does not explain the return format, the meaning of 'bounded', or how the boolean filters are applied. The readOnlyHint annotation helps, but the overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has five parameters with zero descriptions, and the tool description does not mention any of them. The word 'bounded' might hint at a limit, but it is insufficient to convey the semantics of the boolean filters (system, enabled, disabled, third_party). Schema coverage is 0%, and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'package metadata' from the selected device, making the primary purpose clear. It distinguishes from siblings like app_info (single app) and device_info (device-level info), though the term 'bounded' is 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?
No guidance is provided on when to use this tool versus alternatives. Sibling context suggests it is for enumerating installed packages, but the description itself does not state use cases, exclusions, or prerequisites like needing a selected device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'bounded' and 'stationary', hinting at duration limits and lack of movement, but does not explain what 'bounded' means, what happens after the press, or whether any verification is involved. This is minimal and insufficient for a tool with no other safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, making it highly concise. It front-loads the core action. However, it lacks any structured additional context, which slightly lowers the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, yet the description only provides a basic action statement. It fails to convey essential details like coordinate space expectations, duration bounds, the role of verify_change, or the possible side effects. This is completely inadequate for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter-specific meaning. The terms 'bounded' and 'stationary' vaguely relate to duration and movement, but they do not clarify x, y, duration_ms, verify_change, or coordinate_space. The agent must rely on parameter names alone, which is inadequate for correct invocation.
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 (long press) and qualifies it as 'bounded stationary', distinguishing it from simple taps or swipes. The verb 'perform' is specific and the resource is implicitly the screen, as inferred from the tool name. However, 'bounded' is ambiguous without further explanation, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like screen_tap or screen_swipe. The description lacks any context about appropriate scenarios or prerequisites, leaving the agent to guess based solely on the name.
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 hints at boundedness and determinism, but does not explain side effects, failure modes, duration behavior, or the role of verify_change. This is insufficient for a swipe operation.
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 with no wasted words. However, it is under-specified; the brevity comes at the cost of missing critical information, so it earns a mid score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 7 parameters, no output schema, and no annotations. The description provides only one line, omitting return behavior, edge cases, and parameter usage. It is far from complete 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention start_x, end_y, direction, duration_ms, or verify_change at all. The description adds no meaning beyond what the schema structurally provides.
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 (swipe) and resource (screen), and distinguishes two modes: coordinate-based and directional. However, the terms 'bounded' and 'deterministic' are vague and not elaborated, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like screen_tap or screen_long_press, nor when to prefer coordinate versus directional swipes. There is no mention of 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?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does mention an approval requirement, hinting at authorization needs, but it does not explain side effects, permissions, the destructive nature of installation, or what 'allowed host root' means.
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 short sentence, making it concise in length. However, the unclear phrase 'under an allowed host root' introduces confusion, and the sentence omits critical parameter and usage details, earning it an average score.
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 annotations, no output schema, and no parameter documentation, the description leaves major gaps about return values, prerequisites, and operational semantics. For a tool that installs APKs—a significant mutating action—the description is severely under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (coverage 0%), and the description does not explain the parameters path, replace, or approved. The meaning of path is only vaguely implied by 'APK,' and approved by 'Approval-required,' but replace is completely undocumented, leaving agents uncertain about how to set these fields.
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 'installation of an APK,' which distinguishes it from sibling tools like app_launch and app_stop. However, the phrase 'under an allowed host root' is ambiguous and may confuse the agent about the target environment or prerequisites.
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 app_launch or app_stop. It mentions 'Approval-required' but does not specify conditions for use, exclusions, or alternative tools.
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 fully disclose behavior. It adds qualifiers 'sanitized, bounded, local' that hint at safety and scope, but does not explain what these mean in practice (e.g., session lifetime, data handling, side effects like clearing previous state). The agent gets little insight into the tool's actual behavioral traits beyond the vague qualifiers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It earns its place by stating the core purpose. However, given the complexity of a session-start tool with parameters, a slightly longer description would be acceptable, but as written it is efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and two undocumented parameters. The description is far too sparse to be considered complete for an agent to select and invoke it correctly. It leaves the agent without knowledge of parameter semantics, session behavior, return values, or workflow integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (label, metadata) with 0% description coverage, and the tool description does not mention them at all. The description adds no meaning to what these parameters are for, how they affect the session, or their format requirements. This is a critical gap.
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 ('Begin') and a specific resource ('sanitized, bounded local evidence session'), clearly distinguishing this tool from its siblings (evidence_note, evidence_finish). It conveys the core function of starting an evidence collection session without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention that it should be called before evidence_note or evidence_finish, nor any context about prerequisites or exclusions. The 'Begin' verb only implies sequencing from the name, not from the description.
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 only states the action without explaining consequences such as abrupt termination, potential data loss, or impact on app state. The term 'force-stop' is used but its implications are not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately sized for the scope of the tool.
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 simplicity of the tool (one parameter), the description still omits critical context like side effects, return behavior, or usage context. Without annotations or output schema, the agent lacks sufficient information to understand the full impact and safe invocation of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for package_name, and the description only says 'allowlisted package,' which hints at a constraint but does not clarify the expected format, such as an Android application ID, or how to retrieve it. With 0% schema coverage, this is inadequate.
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 ('allowlisted package'), making the tool's function unambiguous. It implicitly differentiates from siblings like app_launch by focusing on stopping rather than starting, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention scenarios for force-stopping, prerequisites beyond allowlisting, or conditions under which force-stop is appropriate. 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions 'allowlisted' but gives no information about side effects, permissions, or the role of parameters like allow_power or verify_change. The agent is left without insight into what actually happens when a key is pressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It efficiently conveys the core action without unnecessary elaboration.
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?
The tool is relatively simple, but with no annotations and no output schema, the description should provide more context about usage, parameter effects, and system impact. The one-liner does not sufficiently prepare an agent to invoke the tool correctly, especially for edge cases like the power key or the purpose of verify_change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description does not compensate. It does not explain the meaning of 'key', 'allow_power', or 'verify_change'. The enum on 'key' provides some context, but the other two boolean parameters remain completely ambiguous.
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 ('press') and the target ('an allowlisted Android testing key'), and the scope ('allowlisted') implies a constrained set of possible keys. This distinguishes it from sibling tools like ui_tap or screen_swipe, which involve touch interactions.
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 any conditions, exclusions, or related tools, 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, the description carries the full burden of behavioral disclosure. It mentions 'visible' and 'server-owned' but omits side effects, whether the mirror is long-running, failure modes, or the need for a previously selected device.
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, effectively stating the core purpose.
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 complexity (7 params, no annotations, no output schema), the description is too sparse. It lacks context about the mirror lifecycle, return behavior, prerequisites, and parameter effects, making it insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 7 parameters, and the description does not explain any of them (audio, control, max_fps, etc.), leaving their semantics completely undocumented.
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 ('Start') and the resource ('a visible server-owned scrcpy mirror for the selected device'), making it specific and distinguishable from siblings like mirror_stop and screen_capture.
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 screen_capture or device_select, nor are any prerequisites mentioned beyond the implied 'selected device' requirement.
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 full burden, but it only mentions 'validated' without explaining the validation process, failure behavior, or side effects of tapping. It does not disclose whether this is a system-level tap, requires permissions, or what happens if coordinates are invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It conveys the core action efficiently, though it errs on the side of being too terse.
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 4 parameters, no annotations, and no output schema, the description is insufficient. It omits key behavioral details, parameter semantics, and fallback context, making it inadequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it only uses the term 'device-pixel coordinates,' which is already encoded in the coordinate_space const. The purpose of x, y, and especially verify_change remain unexplained.
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 ('Tap') and the target ('validated native device-pixel coordinates'), and the phrase 'as a fallback' hints at being an alternative to other methods like ui_tap. However, it does not explicitly name the primary tool it falls back from, so differentiation is implicit.
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 phrase 'as a fallback' implies this tool should be used when other tapping methods (e.g., ui_tap) are unavailable, but it provides no explicit when/when-not guidance or named alternatives. The usage context is only implied, not fully spelled out.
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 full behavioral disclosure. It adds constraints like 'uniquely resolved' and 'visible', and states that it 'verify[ies] the result', but it does not explain what happens on non-unique match, whether it waits for UI changes, or what 'verify' entails. This is a significant gap for a tap action.
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, focused sentence with no filler. It front-loads the action and target, but it is so brief that it sacrifices essential details for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema (nested selector with many properties, 4 parameters), no annotations, and no output schema, the description is grossly incomplete. It fails to explain how to specify an element, what match_index means, how verify_change behaves, or what the return value represents. This is far below the minimum viable completeness for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (node_id, selector, match_index, verify_change) with 0% description coverage. The description does not explain any of these parameters, nor does it clarify how 'uniquely resolved' maps to selector or match_index. The nested selector structure is entirely undocumented in 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 the action ('Tap'), the target ('one uniquely resolved visible semantic UI element'), and the follow-up ('verify the result'). This distinguishes it from coordinate-based taps like screen_tap and from pure lookup tools like ui_find.
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 phrase 'uniquely resolved' implies that the element should already be resolved, perhaps via ui_find, but no explicit alternatives or exclusions are mentioned. It does not tell the user when to choose this over screen_tap or how to resolve uniqueness.
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 only says 'Poll' without mentioning blocking behavior, timeout handling, poll intervals, or failure modes. The schema exposes timeout_ms and poll_ms, but the description does not explain the actual execution semantics.
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, concise and front-loaded with the main action. It wastes no words and is appropriately sized for its content.
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?
The tool has 7 parameters, a complex nested selector, and no output schema, yet the description is only a short phrase. It lacks critical details like return values, timeout behavior, and how to construct a valid condition, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It vaguely references 'foreground', 'disappearance', and 'screen-change' which map to some parameters, but gives no explicit semantics for any of the 7 parameters or the nested selector object. This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Poll') and identifies the resource (UI condition), mentioning concrete conditions like foreground, disappearance, and screen-change. This distinguishes it from sibling tools like ui_find and ui_dump, though 'bounded UI' is somewhat ambiguous.
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 usage (polling for conditions) but never explicitly states when to choose this over alternatives like ui_find or ui_dump. There are no exclusions or alternative mentions, so it relies on the reader to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile (read-only operation), and the description adds scope ('selected device') and a processing detail ('normalize'). However, it does not explain what normalization entails, possible side effects (e.g., blocking on UI response), or error behavior. The description adds some but not rich 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, tightly worded sentence: 'Capture and normalize the selected device UIAutomator hierarchy.' It front-loads the primary verb and object, with no wasted words or redundant phrases.
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 parameter explanation, the description is insufficient for full comprehension. It does not state what the tool returns (presumably the hierarchy) or elaborate on the 'normalize' step. The tool is simple, but the lack of return-value and parameter details leaves gaps for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'compact', has zero description coverage in the schema and is not mentioned in the tool description. The agent cannot determine what 'compact' does, making the parameter's semantics completely opaque. This is a critical gap for a documented optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures and normalizes the UIAutomator hierarchy for the selected device. This specific verb+resource combination distinguishes it from sibling tools like screen_capture (image capture) and ui_find (searching UI), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. There is no mention of prerequisites (e.g., device must be selected via device_select), or scenarios where ui_dump is preferable to ui_find or screen_capture. The agent must 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 does not disclose what 'select' means in terms of state changes, error behavior if the serial is invalid, or whether authorization is checked. Minimal information is given beyond the operation 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?
The description is a single sentence with no unnecessary words, directly conveying the action and key constraint. It is appropriately concise.
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?
The tool is simple with one parameter, but the description lacks behavioral details such as side effects (does selecting change the active device for all subsequent commands?), error handling, and usage context relative to siblings. This makes it incomplete for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'serial' as a string with length constraints. The description adds useful semantics: 'exact' indicates an exact match requirement and 'authorized' suggests only authorized devices are selectable. However, it does not explain how to obtain a serial or what makes a device authorized, so partial compensation for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Select') and the resource ('authorized Android device') with a specific qualifier ('by exact serial'). It distinguishes itself from sibling tools like device_list and device_info by indicating a selection action rather than listing or querying information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., need to call device_list first to see available serials), and no exclusions. The context of being a selection step is implied but not stated.
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, and the description does not disclose behavioral traits beyond the basic action. It does not mention prerequisites, side effects, or what 'redacted' implies, leaving the agent to guess about session state and write 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 a single, front-loaded sentence with no redundant or generic filler. Every word contributes to the purpose, making it highly concise and well-structured.
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 annotations, no output schema, and 0% parameter coverage, the description omits critical context such as the need for an active session, return behavior, and parameter meanings. It is under-specified for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining the parameters, but it fails to mention 'message' or 'details', leaving their semantics entirely to 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 identifies the action (add), the object (a redacted note), and the context (active evidence session), which distinguishes it from sibling tools like evidence_begin and evidence_finish.
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 phrase 'active evidence session' implies when to use it, but there is no explicit guidance on alternatives or when not to use it. It is adequate but lacks clear 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?
No annotations are provided, so the description carries the full burden. It discloses that the operation is 'Approval-required,' which is a meaningful behavioral trait, but it does not explain side effects, prerequisites, or what occurs if approval is denied. For a mutation tool, this leaves significant ambiguity.
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, succinct sentence that communicates the core function without redundancy. It is front-loaded and every word contributes to the message, though this brevity sacrifices necessary detail.
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 mutation tool with no annotations, no output schema, and 4 parameters, yet the description fails to address the approval flow, side effects, or usage context. It is minimally viable but leaves major gaps that an agent would need to resolve elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the parameters. It only implies the 'action' (grant/revoke) and the concept of a permission, but it does not explain package_name, the permission string, or the approved boolean. This is insufficient for an agent to correctly map the schema fields to the intended use.
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 (grant or revoke) and the resource (a requested runtime permission), using specific verbs. It distinguishes from the sibling permissions_list tool, which lists permissions rather than modifying them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to change runtime permissions, but it does not provide explicit when-to-use guidance, exclusions, or alternatives. The 'Approval-required' hint suggests a workflow, but the description lacks clarity on when to invoke this tool versus others.
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 indicates a mutating action ('Stop') but does not disclose consequences, reversibility, permission requirements, or any side effects. The only behavioral context is the scope 'server-owned,' which is more about purpose than 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 a single clear sentence that directly states the action and scope. No superfluous words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description is minimally viable. However, it does not explain what 'server-owned' means, what happens after the stop, or how this relates to mirror_status or mirror_start. For a low-complexity tool, this 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?
The tool has zero parameters, which makes parameter-semantics discussion moot. Per the rubric, 0 params earns a baseline of 4, and there is no schema information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stop' and clearly identifies the resource as 'the server-owned scrcpy mirror.' This distinguishes it from mirror_start and mirror_status, though it does not explicitly contrast with other stop tools like app_stop.
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 phrase 'server-owned' implies a filter against other mirrors, giving some contextual guidance. However, there is no explicit when-to-use or when-not-to-use guidance relative to sibling tools, and no alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that output is bounded, filtered, and redacted, which goes beyond the readOnlyHint annotation by specifying behavioral characteristics of the captured output. It does not contradict the annotation and adds context about the tool's constraints.
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, compact sentence that immediately states the tool's purpose. Every word contributes meaning, with no redundancy or filler.
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 complexity of 9 optional parameters with no schema descriptions and no output schema, this one-sentence description is too minimal. It does not explain return format, device prerequisites, or how parameters map to the filtering/bounding behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 9 parameters, and the description does not mention any parameter names or explain their semantics. The phrase 'bounded, filtered, and redacted' only generically hints at filtering and size limits, leaving the agent to infer meaning from parameter names alone. This is insufficient for a tool with this many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Capture' and identifies the resource as 'logcat output' with modifiers 'bounded, filtered, and redacted' that clarify the tool's scope. This distinguishes it from the sibling 'logcat_crashes', which appears focused on crash logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided regarding when to use this tool vs alternatives such as 'logcat_crashes'. The description lacks any mention of prerequisites, device selection, or comparison with other logging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds context about using 'fresh or retained' snapshots, which is a behavioral trait beyond the annotation. However, it does not disclose how criteria in the selector are combined (AND/OR), what happens when no snapshot_id is provided, or what the return value looks like. Thus, some value is added but significant gaps remain.
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 conveys the primary action and scope. Every word contributes: 'Find matching elements' states the purpose, and 'fresh or retained UI snapshot' distinguishes the two modes. No fluff or repetition.
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 tool has a complex, nested selector schema with numerous matchable properties and no output schema. The description provides only the core idea, omitting how to construct a selector, how matches are returned, or how snapshot retention works. It is too sparse for an AI agent to use effectively without further assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, so the description must compensate. It only vaguely hints at snapshot_id via 'retained UI snapshot' and at selector via 'matching elements,' but does not explain that selector is a rich search criteria object or how to use its many fields. This is insufficient for a complex two-parameter tool with a recursive selector 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: 'Find matching elements in a fresh or retained UI snapshot.' This specifies a concrete action (find) on a clear resource (UI elements) and distinguishes it from sibling tools like ui_dump (which captures the hierarchy) and ui_tap (which interacts). The 'fresh or retained' scope adds operational nuance.
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—it's for querying elements within a UI snapshot—but does not explicitly state when to prefer this over ui_dump or wait_for_ui. The phrase 'fresh or retained' hints at scenarios with or without an existing snapshot, but no alternatives or exclusions are mentioned. This is implied guidance, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already establishes this is a safe read operation. The description adds the behavioral constraint that the package must be allowlisted, which is useful context beyond the annotation. However, it does not disclose what happens if the package is not allowlisted or what metadata is returned, so transparency is only partially enhanced.
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 action ('Inspect metadata') and immediately specifies the scope ('for an allowlisted package'). There is no redundant or unrelated information, and it is highly concise.
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?
The tool has no output schema, so the description should provide some indication of what is returned. Saying 'metadata' is vague and does not convey the breadth or structure of the returned information. Given there are sibling tools like permissions_list and app_list, more context about what distinguishes this tool's output would be valuable. The description is too minimal for full 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 schema provides package_name as a string with length limits, but no description. The tool description says 'allowlisted package', which adds semantic meaning to the parameter: the package must be allowlisted. This is helpful, but it does not explain the format or other constraints beyond that. Since schema coverage is 0%, the description partially compensates but not fully.
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: inspect metadata for an allowlisted package. The verb 'inspect' and resource 'metadata' are specific, and the scope 'allowlisted package' distinguishes it from siblings like app_list which lists packages. It is immediately clear what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need metadata for a specific package, but it does not explicitly state when to use it over alternatives like app_list or permissions_list. No prerequisites or exclusions are mentioned beyond the allowlisting constraint, which is inferred rather than explained. Thus, usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds minimal context with 'validated' and 'selected device'. However, it fails to disclose what happens to the captured screenshot (e.g., returned path, whether it's automatically saved), so additional behavioral context is missing.
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 redundant or superfluous words. It conveys the core purpose efficiently.
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 capture tool, the description covers the basic function but omits key operational details such as parameter semantics, return value, and whether the screenshot is automatically saved. This is adequate but leaves gaps for an agent to function autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description does not explain the parameters 'label' or 'save_to_evidence'. The agent must infer their meaning solely from names, which may lead to incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Capture') and resource ('validated PNG screenshot') with a context ('from the selected device'). This unambiguously distinguishes it from sibling tools like ui_dump or screen_tap.
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 usage is implied (when a screenshot is needed), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The description doesn't mention prerequisites like requiring a selected device.
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 a key behavioral trait: verification that the app becomes foreground. However, with no annotations provided, it does not cover failure behavior, prerequisites beyond allowlisting, or what happens if verification fails. This is partial 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?
A single, front-loaded sentence that conveys the core action and verification without unnecessary words. Highly 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?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. It states the action and verification, but lacks details on edge cases like non-allowlisted packages or failed foreground verification, which would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify what package_name should contain (e.g., package ID vs. app name). The schema only states type and length, leaving the meaning of the parameter under-specified.
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 ('Launch') and identifies the resource (allowlisted package) plus the verification aspect (becomes foreground). This clearly distinguishes it from sibling tools like app_stop or app_install.
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 launching an app and confirming it reaches the foreground, but does not explicitly state when to choose this tool over alternatives or mention exclusions. The 'allowlisted' constraint is mentioned 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?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention side effects like destroying the session, what the summary contains, how it is returned/written, or error behavior if no active session exists. This lack of detail 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 concise sentence with no filler. It front-loads the primary action ('Finish') and clearly states the secondary outcome ('write its summary').
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 parameters and no output schema, which lowers the burden. However, given the lack of annotations, the description should clarify prerequisites (e.g., an active session must exist) and consequences (e.g., session is closed, summary is persisted). The current description is minimal but adequate for a simple tool, yet leaves important behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty, so schema coverage is 100%. The description needs no parameter explanation, and the baseline of 4 applies since parameters are absent.
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: 'Finish the active evidence session and write its summary.' The verb 'finish' combined with the resource 'evidence session' and the outcome 'write its summary' leaves no ambiguity. It is distinct from siblings like evidence_begin and evidence_note, which handle session start and note-taking respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the final step in an evidence session by referencing the 'active evidence session.' It provides clear context for when to use the tool but does not explicitly mention alternatives or exclusions (e.g., 'do not use if you need to add more notes; use evidence_note instead'). The context is strong enough to guide usage.
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 provided, the description carries the full burden of disclosure. It explicitly states that the operation is irreversible, requires approval, and is restricted to allowlisted packages. This communicates the most critical behavioral traits, though it does not detail the exact extent of data cleared or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads critical qualifiers ('Approval-required irreversible') and wastes no words. Every term adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two parameters and no output schema, the description covers the essential context: approval requirement, irreversibility, and package restriction. It does not mention prerequisites like whether the package must be installed, but the overall usage context is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It mentions 'Approval-required' and 'allowlisted test package', which loosely map to the 'approved' and 'package_name' parameters, but it does not explicitly explain how to use each parameter, such as setting 'approved' to true to confirm. Partial guidance is provided.
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 clears local data for a specific resource (an allowlisted test package). It uses the specific verb 'clearing' and includes important qualifiers ('approval-required', 'irreversible') that distinguish it from any sibling tool.
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 you need to clear local data for a test package), but it does not explicitly contrast it with alternatives or state when not to use it. There is no mention of other app-related tools like app_launch or app_stop, which would help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no side effects. The description adds useful context like 'normalized' and 'selected device,' but it does not disclose what fields are returned or how the tool behaves if no device is selected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the action and clearly states the target 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?
Given the tool is simple (zero parameters) and covered by readOnlyHint, the description is largely complete. It would benefit from listing example data fields or error behavior, but it is adequate for an agent to invoke it 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, so the schema provides complete coverage. The description correctly avoids inventing parameter details, and per rubric a baseline of 4 applies for zero-parameter tools.
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 verb 'Return' and the resource 'normalized information for the selected device' clearly identify the tool's function. It is distinct from siblings like device_list (which lists devices) and device_select (which changes selection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when needing info about the currently selected device), but it does not explicitly mention alternatives or exclusions, such as using device_list for available devices or app_info for app details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds meaningful behavioral context by noting 'bounded', 'recent', and 'allowlisted' — constraints that are not obvious from the name or annotations. However, it does not specify the exact bound (e.g., number of items, time window) or the behavior for non-allowlisted packages, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that front-loads the core action ('Return bounded recent crash and ANR evidence') followed by the scope ('for an allowlisted package'). There is no redundant or filler content; 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?
Given the tool has only one parameter and no output schema, the description is reasonably complete: it conveys what the tool returns, the restriction, and the bounded nature. However, it does not describe the exact output format or the meaning of 'bounded', which would be helpful for an agent to interpret the result, but the simplicity of the tool lowers the need for extensive extra detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter package_name. The description mentions 'allowlisted package', which adds context about a restriction, but does not detail the package_name format or provide examples. Since there is only one parameter and its name is fairly self-explanatory, the description provides minimal but adequate compensation for the lack of schema descriptions.
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 ('Return') and clearly states a resource scope: 'crash and ANR evidence for an allowlisted package.' This distinguishes it from sibling tools like logcat_capture, which captures general logcat output, by focusing specifically on crashes and ANRs for a single package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a specific use case (getting crash/ANR evidence) but does not explicitly state when to use it over alternatives like logcat_capture. It lacks exclusion criteria or explicit 'use this when...' guidance, so the context is implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description's 'List' is consistent. The description adds no additional behavioral context beyond what the annotation provides (e.g., no mention of output format, pagination, or special conditions). There is no contradiction.
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 verb and object. No wasted words, and it conveys the essential purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description plus readOnlyHint and schema provide sufficient context. The term 'allowlisted' is somewhat ambiguous and could be clarified, but overall the description is complete for the tool's simplicity and lack of output schema.
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?
With 0% schema description coverage, the description compensates by clarifying that the package_name parameter refers to an 'allowlisted package'. This adds semantic meaning beyond the schema's bare string constraints, though it does not explicitly name the parameter or provide format examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('requested and granted runtime permissions') and scope ('for an allowlisted package'). It effectively distinguishes from siblings like permissions_set, which handles setting permissions.
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 (use to list permissions for a package) but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The sibling context suggests it complements permissions_set, but that is not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description clarifies the specific process being queried (server-owned scrcpy) but does not disclose additional behaviors such as return format or potential latency, which is minor given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that states exactly what the tool does with no 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?
The tool is simple with no parameters and a read-only annotation. The description adequately covers its purpose, though it does not specify the return format (e.g., 'running' or 'not running'), which could be useful given there is no output schema.
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 no parameters, so the schema fully covers the input. The description does not need to elaborate on parameters; the baseline of 4 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 'Return the status' and identifies the resource as the 'server-owned scrcpy process', clearly distinguishing it from sibling tools like mirror_start and mirror_stop.
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 or how it compares to alternatives like mirror_start or mirror_stop, but the name and action imply it is for checking the current mirroring state.
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 adds useful constraints like 'safe printable ASCII' and the warning against secrets, but it does not disclose details such as whether the tool overwrites existing content, how non-ASCII characters are handled, or any logging implications. For a simple tool this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the verb 'Type' and the resource. Every word earns its place, including the security warning. No 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 (one parameter, no output schema), the description is complete enough: it specifies the target ('focused field'), the input type ('safe printable ASCII'), and the usage caveat (secrets). It could potentially mention prerequisites like ensuring focus, but 'focused field' already implies that requirement, so the description is sufficiently 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 has 0% description coverage, and the description compensates by specifying that the 'text' parameter should contain 'safe printable ASCII test text'. This adds meaning beyond the schema's raw string type and length constraints. It does not mention the 1024 max length, but that is already present in the schema, so the description adds valuable semantic context without needing to repeat schema details.
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 'Type safe printable ASCII test text into the focused field', specifying the action (type), the resource (focused field), and the input scope (safe printable ASCII). It distinguishes itself from sibling tools like key_press and ui_tap by emphasizing text input rather than individual keys or taps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to type text into a focused field, with an explicit exclusion 'never use for secrets'. However, it does not explicitly name alternative sibling tools (e.g., key_press for individual keys) or describe scenarios where other tools would be preferable, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds meaningful context by specifying that the output includes ADB authorization states, which is not trivial and helps the agent understand the tool's behavior. It does not discuss edge cases like no devices connected, but the added detail justifies a score above baseline.
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 starts with the action verb and immediately states the resource. Every word contributes to the meaning, with no redundancy. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's trivial complexity (no parameters, no output schema), the description provides sufficient context for an agent to know what the tool does and what kind of output to expect. It names the key output elements (devices and authorization states), making the tool adequately specified.
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 and description naturally cover everything. The baseline for 0 parameters is 4, and there is no additional parameter semantics needed. The description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('connected Android devices') and the scope ('their ADB authorization states'). This distinguishes it from sibling tools like device_info, which likely focuses on a single device, and mirror_status, which pertains to mirroring. The purpose 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 usage for enumerating connected devices, but it does not explicitly state when to choose this over alternatives like device_info, nor does it provide any situational guidance or exclusions. The user must infer that this is the go-to tool for a device list based on its name and description.
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:

[![android-agent-mcp MCP server](https://glama.ai/mcp/servers/EF-Code/android-agent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/EF-Code/android-agent-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EF-Code/android-agent-mcp'

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