ADB MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target distinct resources and actions, but there are clusters around UI hierarchy (dump_ui/wait_for_ui_node/assert_ui_node), device listing (list_devices/list_avds), and key input (press_key/press_key_sequence) that could cause misselection without careful reading. Descriptions help, but the boundaries are close.
Naming Consistency4/5The vast majority of tools follow a snake_case verb_noun pattern (list_devices, get_device_info, install_apk). A few outliers like 'tap', 'swipe', and 'screenshot' break the pattern by using bare verbs or nouns, but the overall convention is consistent.
Tool Count2/5With 30 tools, the server is on the heavy side. It bundles ADB operations with OBS recording and build profiles, stretching the scope beyond typical ADB interactions. While each tool has a purpose, the sheer number suggests possible consolidation.
Completeness3/5The tool set covers device management, UI automation, app lifecycle, and logs, which is adequate for UI testing workflows. However, notable ADB gaps include file transfer (push/pull), shell command execution, and more granular UI interactions like long press or drag. These are workaroundable but represent missing operations.
Average 3.9/5 across 30 of 30 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the agent knows it's a mutating operation. The description adds the term 'safe' and the scope of supported keys, which is useful but doesn't disclose side effects (e.g., POWER may sleep/wake device). No contradiction with annotations, but limited extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence front-loaded with the core purpose. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with multiple sibling input methods (press_key_sequence, tap, swipe, type_text), the description lacks an explicit pointer to alternatives. No output schema, but the lack of return-value info is acceptable for a fire-and-forget key press. Slightly incomplete for disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Send') and the resource ('Android key event'), with specific scope ('named', 'D-pad and Fire TV remote navigation keys'). It distinguishes from touch-based siblings like tap/swipe, but does not explicitly differentiate from the closely related press_key_sequence, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It implies use for named key events but doesn't mention press_key_sequence for multiple keys or type_text for text input. 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?
The description adds minimal behavioral context beyond the annotations. It mentions 'absolute screen coordinates' and 'bounded duration,' but these are somewhat redundant with the schema's min/max values. It does not disclose side effects, error behavior, or device selection implications, which is a gap given the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes essential scope ('absolute screen coordinates' and 'bounded duration') without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple gesture tool but lacks details about return values, error conditions, or device prerequisites. Given no output schema and minimal annotations, it could be more complete, but it does cover the core action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by clarifying that coordinates are absolute and that the duration is bounded, which helps interpret the x1/y1/x2/y2 and duration_ms parameters. However, it does not explain the start/end relationship or units, and schema coverage is low, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: swiping between two absolute screen coordinates with a duration. It uses a specific verb ('swipe') and resource ('screen coordinates'), distinguishing it from siblings like tap or type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like tap or type_text, nor does it mention any exclusions or prerequisites. Usage is only implied by the verb itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what annotations already convey (readOnlyHint=false). It does not disclose potential side effects, failure conditions, or what the tool returns after execution, leaving the agent with minimal insight into the action's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the verb and resource, making it immediately scannable and efficient for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required coordinate parameters, no output schema), the one-line description is minimally adequate. However, it lacks any mention of return values or failure modes, and does not differentiate from sibling input tools, making it less complete for an agent that must decide among alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is only 33% (only device_serial has a description), so the description should compensate. The phrase 'absolute screen coordinate' clarifies that x and y represent absolute coordinates, adding meaning beyond raw integers. However, it does not explain coordinate origin or units, and device_serial's description is already in the schema, so the overall compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tap an absolute screen coordinate' uses a specific verb (Tap) and resource (screen coordinate), making the purpose immediately clear. The addition of 'absolute' distinguishes it from relative gestures like swipe, providing clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 swipe, press_key, or type_text. There is no mention of prerequisites (e.g., screen on) or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. While destructiveHint=true is present, the description does not elaborate on consequences such as app data removal (mitigated by keep_data) or process termination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single compact sentence, front-loaded with the verb and object, containing no filler or redundant details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate but minimal. The schema covers all parameters, yet the description lacks usage guidance and behavioral side effects. For a destructive tool, more context would help, but the core operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The description's mention of 'by package name' reinforces the required parameter but adds no semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'uninstall' with the resource 'Android application' and method 'by package name', clearly distinguishing it from sibling tools like install_apk or launch_app. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any prerequisites (e.g., device connection, package availability). The description simply states the action, leaving the agent to infer invocation 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 description discloses that this is an assertion on the current UI hierarchy, which aligns with the readOnlyHint. However, it does not explain what happens on assertion failure (e.g., throwing an error, returning false), which is crucial for an assertion tool and not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's function without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description covers the core behavior but omits important contextual details like failure semantics and return values. This is a notable gap for an assertion tool, but the overall context is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover 100% of parameters with clear semantics (e.g., 'Exact node text to match', 'Set false to assert that no matching node exists'). The description adds no additional parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: asserting whether the current Android UI Automator hierarchy contains or does not contain a matching node. It uses a specific verb ('Assert') and resource, and the 'does or does not' phrasing distinguishes it from dumping or waiting operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like wait_for_ui_node or dump_ui. It does not mention prerequisites, typical scenarios, or exclusions, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=false, so the agent knows it mutates state, but the description adds no behavioral context such as whether the app comes to foreground, what happens if already running, or what errors may occur. With minimal annotations, the description carries burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and resource, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, but the description lacks usage guidance and behavioral context, making it minimally viable rather than fully complete. There is no output schema, so return behavior is unclear, but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (package_name, activity, device_serial) at 100%, so the baseline is 3. The description only restates that activity is optional, adding no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Launch') and resource ('app by package name'), clearly distinguishing it from sibling tools like stop_app and install_apk. It also signals the optional activity component, which differentiates it from basic launchers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for starting an app, but it does not explicitly state when to use it versus alternatives like start_emulator or open_obs. There are no exclusions or conditions, so usage context 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?
The description adds context beyond the readOnlyHint=false annotation by disclosing that it selects and verifies the OBS source before starting recording. However, it does not mention potential side effects like launching OBS (as hinted by the launch_if_needed parameter) or failure modes when the source is not configured. With annotations providing the mutation hint, the description gives some added context but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action verb and resource. Every word contributes meaning, and it is not padded with redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has side effects, depends on OBS state, and has no output schema. The description does not explain return values, prerequisites (e.g., OBS must be running), or how it integrates with sibling tools like open_obs or get_obs_status. It is too minimal for a mutation tool with complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only avd_name has a description). The tool description helps clarify the 'target' parameter by mentioning emulator or physical device, but it provides no additional meaning for 'timeout_ms' or 'launch_if_needed'. With low schema coverage, the description carries a heavy burden and fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Select and verify the configured OBS source for an emulator or physical device, then start recording.' It specifies the verb (start recording), the resource (OBS source), and the target scope (emulator or physical device), distinguishing it from sibling tools like stop_obs_recording and get_obs_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to record screen activity for a specific target, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like OBS being open or checking status. There is no exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true directly contradicts the description's 'Clear' action, which implies a state change. No additional behavioral context is given, and the contradiction makes the tool's behavior unreliable to agents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. The verb and resource are front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), so the brief description is largely sufficient. However, it does not clarify the exact effect relative to disconnect_device, leaving ambiguity about whether the physical connection is affected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no additional parameter semantics, but none are needed since the schema fully covers the absence of arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and the target resource ('active device') scoped to the MCP session. This distinguishes it from sibling tools like select_device and disconnect_device, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies a session-management context but does not mention exclusions or refer to related tools like disconnect_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 readOnlyHint annotation already declares this as a safe read operation. The description adds the caveat 'when supported by the device,' which is useful, but it does not describe what happens on unsupported devices or any other behavioral details. The annotation lowers the burden, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the output and condition. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a clear output format ('XML hierarchy') and a single optional parameter, the description is nearly complete. The only gap is lack of detail about unsupported-device errors, but the 'when supported' clause covers the main caveat adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single well-described parameter (device_serial). The description itself does not add parameter-level detail, but the schema fully carries that responsibility, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the current Android UI Automator hierarchy as XML' with a specific scope ('when supported by the device'). This distinguishes it from sibling tools like screenshot (visual capture) and get_current_activity (activity name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The description mentions a device-support condition but does not state when to prefer dump_ui over screenshot or wait_for_ui_node, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses some behavioral traits: it opens OBS only 'if necessary' and optionally selects a scene. However, it does not detail side effects (e.g., window focus, scene switching) or error scenarios. Since annotations indicate a mutation (readOnlyHint=false), the description adds a bit of context but not rich behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action ('Open OBS') and efficiently adds the optional scene selection. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description covers the core functionality but leaves gaps: what 'configured' scene means, how 'if necessary' is determined, and what timeout_ms controls. It is adequate for a basic tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description fails to explain the parameters. It hints at 'target' via 'emulator or physical-device scene' but does not clarify that target is optional (no required params) or describe the purpose/meaning of timeout_ms. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Open OBS if necessary and optionally select the configured emulator or physical-device scene.' It uses a specific verb ('Open') and resource ('OBS'), and the optional scene selection differentiates it from sibling tools like get_obs_status or start_obs_recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implied usage context ('if necessary') but does not explicitly state when to use this tool versus alternatives such as get_obs_status or start_obs_recording. It lacks clear when-to-use or when-not-to-use guidance, making it adequate but 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?
Annotations already indicate a non-read-only operation (readOnlyHint=false) and an open world (openWorldHint=true). The description adds the prerequisite that the target must already be listening on TCP, which is useful context, but it does not mention side effects (e.g., device appearing in device lists) or failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It fully conveys the tool's purpose and the critical prerequisite, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description covers its core function and the required network target format. It could mention the post-connection state (e.g., the device becomes available for other ADB commands), but for a straightforward operation this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage for 'target' with an example of the expected format. The description itself adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Connect') with a clear resource ('ADB to a physical device or emulator already listening on TCP using host:port'). It clearly distinguishes from sibling tools like 'disconnect_device' and 'list_devices' by focusing on establishing a TCP connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'already listening on TCP' implies the intended context, and the host:port format gives a concrete usage. However, it does not explicitly state when to prefer this tool over alternatives or mention any prerequisites such as an ADB server running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds the behavior of filtering by a case-insensitive fragment, but does not disclose any other side effects or limitations beyond what annotations provide. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, approximately 15 words, directly starting with the verb and including only essential information. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three parameters and no output schema, the description is sufficiently complete. It explains the core action and the optional filter, and the device_serial parameter is documented in the schema. It could mention the return format, but logcat output is conventionally text and not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only device_serial has a description). The description adds meaning by stating 'recent' for the lines parameter and 'case-insensitive' for contains, but it does not detail the lines count limits or default, which are in the schema. This partially compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'read' with the resource 'logcat lines', and clarifies the optional filter for case-insensitive text. This clearly distinguishes it from all sibling tools, none of which deal with logcat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for reading logcat, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. Since there is no sibling logcat tool, the context is clear but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the key behavioral trait of polling (persistent waiting) until a condition is met, which goes beyond the annotation. It does not disclose what happens when the timeout is reached (e.g., error or return false), but the schema includes a timeout parameter, partially mitigating the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action ('Poll Android UI Automator') and then specifies the condition. There is no redundant information or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core purpose but omits important behavioral details such as what the tool returns (no output schema exists) and what happens on timeout. For a polling tool, specifying the timeout outcome and return type would significantly improve completeness. The current description is adequate but leaves clear gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, with 5 of 7 parameters described. The description adds value by clarifying that the match criteria (text, resource_id, content_desc, focused) can be combined using 'and/or', a nuance not present in the individual schema descriptions. However, it does not add meaning for timeout_ms, poll_interval_ms, or device_serial, which remain only partially specified in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: polling Android UI Automator until a node matching specified criteria exists. It names the specific verb 'Poll', the resource 'Android UI Automator node', and the matching conditions, distinguishing it from sibling tools like assert_ui_node which likely performs a one-shot check, and dump_ui which dumps the current hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for waiting until a UI node appears but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. For example, it does not mention 'use assert_ui_node for immediate existence checks' or 'use wait_for_ui_node when a node may appear asynchronously'. The context is implied by the 'poll until' language but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating action (readOnlyHint=false) and external world impact (openWorldHint=true). The description adds the scope limitation regarding USB devices but does not disclose side effects like connection loss or reversibility. This meets the lower bar set by annotations but adds only limited extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with the action. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations and no output schema, the description is sufficient to understand the tool's scope and effect. It could mention post-conditions, but the core behavior is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter 'target' with a description ('Connected host:port target'). The tool description adds no additional parameter semantics, so the baseline of 3 applies given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Disconnect' and the resource 'ADB-over-TCP target', which is specific and distinct from sibling tools like connect_device or clear_active_device. It also clarifies what it does not affect (USB devices), adding useful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ADB-over-TCP targets and explicitly excludes USB devices. This gives a clear context for when to use this tool, though it does not name alternative tools or explicit when-not scenarios beyond the USB caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description need not repeat that. It adds valuable context by specifying 'currently resumed' and 'activity/window', which clarifies the exact scope of the read operation. However, it does not describe return format, error cases, or device selection behavior beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It front-loads the verb and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description sufficiently states the tool's purpose and scope. The lack of an output schema is acceptable because the description implies the return value (the current activity/window), and the annotation covers the read-only safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the single parameter (device_serial) with a clear description. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource ('currently resumed Android activity/window') and its purpose ('for diagnosis and assertions'). This distinguishes it from sibling tools like screenshot or dump_ui, which operate on different aspects of the UI.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the tool is for 'diagnosis and assertions', implying when it should be used. However, it does not explicitly contrast with alternatives such as dump_ui or assert_ui_node, so it falls short of a 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 annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows the operation is safe. The description adds value by enumerating the exact data points retrieved and the nuance about the device self-reporting as an emulator. No side effects or failure modes are disclosed, but for a pure getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the verb 'Read' and lists all returned fields without extraneous wording. Every clause earns its place, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description lists all return data points, which serves as an implicit specification of the response content. The schema covers the device_serial behavior, including active device fallback, so the overall context is complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (device_serial) with a complete description covering 100% of the schema. The tool description adds nothing about parameter semantics beyond what the schema already states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads specific device attributes (model, manufacturer, Android version, SDK, screen info, emulator status) using a precise verb ('Read') and a defined resource. It distinguishes from sibling tools like list_devices by focusing on properties of a single target device rather than device discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when device details are needed but does not explicitly state when to prefer this tool over alternatives or provide exclusion conditions. Among the many sibling tools, no direct comparison or alternative guidance is given, so the agent must infer applicability.
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 indicate readOnlyHint=false and openWorldHint=false, so the tool is understood to be mutating. The description adds the 'safe' qualifier for key events and the concept of timed delays, but it does not disclose potential side effects, prerequisites like device connection, or error behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the key information: what it does and when to use it. The example is illustrative without being verbose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers the main purpose and usage scenario. The schema covers parameter details, so the description need not repeat them. It lacks information about return values, but that is not critical for a key event tool. Overall, the description is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% because the description references 'sequence' with an example but omits 'device_serial.' The example 'BACK, wait 1s, BACK' adds practical meaning to the sequence parameter beyond the schema. However, it does not compensate for the lack of description for device_serial, and the schema already provides basic defaults and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Send a timed sequence of safe, named Android key events.' It distinguishes from sibling 'press_key' by emphasizing 'timed sequence' and 'precise intervals,' making the tool's unique purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear intended use case: 'Use this for gestures requiring precise intervals.' It gives a concrete example ('BACK, wait 1s, BACK') that illustrates the timing aspect. It does not explicitly say when not to use it or mention alternatives, but the context from siblings and the example is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it discloses that the screenshot is 'resize and compress[ed]' into an 'analysis-friendly PNG' and 'return[ed] directly to the agent.' This explains post-capture processing and delivery mode, which are not evident from the readOnlyHint alone. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs capture, processing, and delivery into a clear sequence without superfluous words. Every phrase contributes meaning, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description is sufficiently complete. It explains the action, the output format (PNG), and that the result is returned to the agent. It does not cover edge cases like device unavailability or permission issues, but given the low complexity and strong schema/annotations, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema fully documents the optional 'device_serial' parameter, including examples and fallback behavior. The description adds no parameter-specific information, which is acceptable given the schema's completeness. Baseline 3 applies because the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Capture the current screen, resize and compress it as an analysis-friendly PNG, and return it directly to the agent.' It uses a specific verb ('Capture'), identifies the resource ('current screen'), and describes the output, distinguishing it from sibling tools like dump_ui which inspect UI hierarchy rather than produce a visual image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage timing is implied by the purpose—'Capture the current screen' suggests using it when a visual snapshot is needed—but the description does not explicitly state when to use this tool versus alternatives, nor does it name any alternative such as dump_ui. There is no exclusion guidance, leaving the agent to infer appropriate conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds the session-scoped nature of the selection, which is useful. It does not disclose details such as whether the device must be connected first or how a previously active device is replaced, but given the annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential information concisely and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, full schema coverage, and no output schema. The description plus schema sufficiently explain what it does and how to invoke it. It could mention that the active device will be used by subsequent commands, but 'active for this MCP session' covers this adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and the schema's parameter description is detailed (e.g., 'ADB serial such as emulator-5554, a USB serial, or host:port'). The tool description itself adds no parameter-related meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Select' and clearly identifies the resource (an emulator or physical device) and the scope ('active for this MCP session'). It distinguishes itself from sibling tools like list_devices, disconnect_device, and clear_active_device by focusing on making a device active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to set the active device for the current session. It does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous enough that an agent can infer when it applies.
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 destructiveHint=true and readOnlyHint=false, which the description aligns with by stating 'Force-stop'. The description adds no new behavioral context beyond the annotation (e.g., effect on app state, termination of all processes), but the safety profile is adequately disclosed by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It states the action, target, and required identifier efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, this description plus annotations is adequate. It does not explain return values or failure behavior, but the straightforward nature of force-stopping an app and the presence of destructive annotation make the tool's behavior reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with device_serial documented but package_name not. The description adds meaning to package_name by identifying it as a package name (rather than an app label), which helps distinguish the expected format. device_serial's semantics are fully covered in the schema, so overall parameter understanding is solid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Force-stop') and a clear resource ('Android application') with the scope ('by package name'). This distinguishes it from siblings like launch_app, uninstall_app, and install_apk, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for terminating an app without mentioning alternatives or exclusions. It does not explicitly state when to prefer this over uninstall_app or other app-control tools, but the name and wording make the core use case evident.
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=false annotation already signals a write operation. The description adds the behavioral detail that the recording is finalized and the saved file path is returned. However, it does not disclose what happens if no recording is active or if OBS is not running, which could be relevant edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates action, finalization, and return value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description provides sufficient context about the operation and its result. It could be slightly more explicit about prerequisites, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to describe. The baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Stop and finalize') and the target resource ('current OBS recording'), and also mentions the return value. It distinguishes from sibling tools like start_obs_recording and get_obs_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly explain when to use this tool or what conditions must be met (e.g., recording must be active). It offers no alternative comparisons, relying on the tool name and sibling context. While the purpose is clear, usage criteria are implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds specific behavioral context beyond the readOnlyHint annotation by disclosing that it checks both WebSocket reachability and recording state. This is useful and aligns with the annotation, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose efficiently, with no filler or redundant information. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with no output schema, the description adequately states what it does. However, it does not specify the return format (e.g., booleans or human-readable text), which might be helpful but is not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description does not add parameter-specific details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Report') and resource ('OBS WebSocket reachability' and 'whether OBS is currently recording'). This is specific and distinguishes it from sibling tools like start_obs_recording and stop_obs_recording, which control recording rather than report status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a status-check tool before or during OBS operations, but it does not explicitly state when to use it or how it relates to alternatives. No exclusions or alternative tool references are provided, so usage is inferred rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read nature is covered. The description adds valuable context beyond annotations by clarifying that the list is filtered by server-side permissions ('allowed to execute'), which is not apparent from the annotations alone. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, then scopes it with permission context and examples. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, no output schema, and read-only annotations, the description is largely complete. It states what is listed, the server-side scope, the permission filtering, and gives examples. It could optionally mention that the returned profiles are usable as inputs to run_build, but that is inferable from sibling tools and not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter details, which are irrelevant here. It adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List') and the resource ('server-side build profiles'), and specifies the scope ('that this MCP instance is allowed to execute') with concrete examples ('debug or release'). This fully differentiates it from sibling tools like 'run_build' which executes builds rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: you'd list profiles to know which ones are allowed before running a build. However, it does not explicitly name alternatives (e.g., 'use run_build to execute a profile') or provide when-to-use vs. when-not-to-use guidance. The 'allowed to execute' phrasing hints at a prerequisite roll but stops short of explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation by explaining that installation only happens 'when the profile declares artifactPath' and that the build is 'server-side'. This provides useful conditional behavior that the annotation alone does not convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action. Every word contributes meaning—no fluff, no repetition of schema or annotations. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, a destructive annotation, and no output schema, the description covers the core action and an important conditional side effect. It lacks details on error cases or prerequisites (e.g., profile must exist), but the schema provides enough parameter context. Overall, it is quite complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 3 parameters with descriptions, so the baseline is 3. The description adds extra semantic meaning by tying the install_after_build parameter to the artifactPath condition, which is not mentioned in the schema. This helps the agent understand when the install flag will actually take effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run a configured server-side build profile' with a specific verb and resource. It also mentions the optional install of the resulting APK, which distinguishes it from sibling tools like list_build_profiles (listing) and install_apk (installing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to build a profile, optionally install), but it does not explicitly mention alternatives or when not to use it. Sibling tools like list_build_profiles or install_apk are not referenced, so the agent has to infer the appropriate context from the description alone.
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 key behavioral traits: it initiates boot with quick or cold modes, waits for Android to finish booting, and selects the emulator as active. This adds context beyond the annotations (readOnly=false, openWorld=false), which only indicate mutation and non-open-world behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and includes all key behaviors without unnecessary words. It is concise and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema), the description adequately covers the main behavior: starting, booting, and activating. It does not explain return values or timeout failure behavior, but the schema and defaults cover timeout_ms. The context is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters described), so the baseline is 3. The description mentions 'quick or cold boot,' which maps to the boot_mode parameter, but this adds little beyond the schema's own enum and description. It does not elaborate on avd_name, headless, or timeout_ms beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: start an Android Virtual Device with specific boot modes, wait for boot completion, and select it as active. This specific verb+resource combination distinguishes it from sibling tools like list_avds or connect_device, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to start and activate an emulator) and provides clear context about waiting for boot and selecting active. However, it does not explicitly state alternatives or when not to use it, such as preferring connect_device for physical devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing that shell metacharacters are rejected for safety. This is a meaningful behavioral constraint not captured by readOnlyHint=false or openWorldHint=false. It also sets expectations about input restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that each serve a clear purpose: first stating the core action, second adding a critical safety detail. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple typing tool, the description covers the essential behavior and safety mechanism. It does not describe return values or error handling, but given the lack of an output schema and the tool's simplicity, this is not a significant gap. The device_serial parameter is properly explained in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (text parameter lacks description). The tool description compensates by clarifying that text is 'restricted plain text' and that metacharacters are rejected, adding meaning to the text parameter. The device_serial parameter is fully described in the schema, so no further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Type restricted plain text') and the target ('focused field'), making it distinct from sibling tools like press_key or tap. The qualifier 'restricted plain text' helps differentiate it from other input methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicitly stated. The description does not mention when to use this tool over alternatives, nor does it provide exclusions. However, the context of 'focused field' and the sibling list make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral detail by noting it reports which AVDs are currently running, going beyond a simple listing. This extra context helps the agent understand the tool's output without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence that starts with the main action ('List configured Android Virtual Devices') and adds only the key extra detail about running status. Every word is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, read-only operation), the description is complete. It states what it lists and what it reports, which is sufficient for an agent to use the tool effectively. The lack of return-format detail is acceptable for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameters to explain, and the description doesn't need to add parameter semantics. It appropriately focuses on the tool's action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists configured Android Virtual Devices and reports running status. The verb 'List' and resource 'configured Android Virtual Devices' are specific, and the addition of 'report which ones are currently running' distinguishes it from sibling tools like list_devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need to see configured AVDs and their running state. However, there is no explicit when/when-not guidance or mention of alternatives such as list_devices for physical devices, so it relies on the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is safe. The description adds the detail that authorization state is included, which is a useful behavioral trait not in the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that starts with the verb 'List' and immediately conveys the key information. It covers all relevant aspects without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is complete. It specifies the scope (emulators, USB, network), the system (ADB), and an important detail (authorization state). The presence of sibling tools does not create ambiguity that the description fails to address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameters because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Android emulators, USB devices, and network-connected devices visible to ADB, and specifies that it includes authorization state. This distinguishes it from siblings like connect_device, get_device_info, or disconnect_device by focusing on the enumeration of available devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering devices connected to ADB, but it does not explicitly state when to use it over alternatives or provide exclusions. There is no mention of 'use this before connecting' or 'for details on a specific device, see get_device_info'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=false, but the description adds meaningful context: 'user-confirmed' indicates a validation step, and the condition about install_apk only accepting APKs within the directory is a behavioral constraint. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose. Every word earns its place, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description sufficiently explains the purpose, the side-effect relationship with install_apk, and is complete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is already clear. The tool description adds no further detail about the parameter beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Set') and resource ('repository root for this MCP session'). It also differentiates itself from siblings by linking to install_apk, explaining why the root matters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by explaining that install_apk depends on it, giving clear context. It does not explicitly name alternatives or exclusions, but the usage scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a destructive, non-read-only operation. The description adds valuable behavioral context by constraining the APK to be within the session root or ADB_APK_ROOT, and clarifies the fallback behavior when no session root is set. This goes beyond the safe-read baseline and discloses path restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action and key constraint efficiently, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five parameters with full schema descriptions and the destructive annotation, the description is adequately complete. It covers purpose and location restrictions, while device selection and permission handling are already documented in the schema. The lack of an output schema reduces the need for return-value narration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds meaningful semantics for apk_path by requiring it to be contained within the session root or ADB_APK_ROOT, which is not stated in the schema's apk_path description. This enriches the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install an APK') and specifies the resource scope (APK within the active session project root or ADB_APK_ROOT). This distinguishes it from sibling tools like uninstall_app, launch_app, or run_build, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying where the APK must be located and the fallback root when no session root is set. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient to guide the agent on when this tool is appropriate.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/francbonet/Adb-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server