agent-droid-bridge

by Neverlow512

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: detect_ui_change monitors for changes, get_ui_hierarchy reads screen content, snapshot_ui captures state tokens, and actions like tap_screen, swipe_screen, type_text, press_key, launch_app, take_screenshot, list_devices, and execute_adb_command each handle specific interactions. Descriptions explicitly differentiate usage scenarios, preventing misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., detect_ui_change, get_ui_hierarchy, tap_screen). This uniformity makes the set predictable and easy to understand, with no deviations in style or convention.
Tool Count5/5
With 11 tools, this server is well-scoped for Android device automation, covering essential actions like UI interaction, navigation, input, and device management. Each tool serves a clear role without redundancy, making the count appropriate for the domain.
Completeness5/5
The toolset provides complete coverage for Android automation: UI reading (get_ui_hierarchy), change detection (detect_ui_change, snapshot_ui), interactions (tap_screen, swipe_screen, type_text, press_key), app control (launch_app), device management (list_devices, execute_adb_command), and visual feedback (take_screenshot). No obvious gaps exist for core workflows.
Average 4/5 across 11 of 11 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the action but doesn't disclose critical traits like whether this requires device interaction permissions, if it's synchronous/asynchronous, error handling for invalid coordinates, or side effects on the UI state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action and directly lists the key parameters without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 100% schema coverage, and an output schema, the description is minimally adequate. However, as a device interaction tool with no annotations, it lacks context about prerequisites, error conditions, and behavioral expectations that would help an agent use it correctly in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds minimal value beyond the schema, only implying that parameters define a swipe gesture from start to end points over time, which is already evident from parameter names and schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('swipe gesture') and target ('Android screen'), specifying coordinates and duration. It distinguishes from siblings like tap_screen or press_key by describing a swipe motion, but doesn't explicitly differentiate from similar gesture tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., device connectivity), appropriate contexts, or comparisons to other interaction tools like tap_screen or execute_adb_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output format but fails to mention critical behavioral aspects such as whether this operation requires specific device states, if it's read-only or has side effects, potential performance impacts, or error handling. The description is purely output-focused without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's output without unnecessary words. It's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which presumably describes the return structure), the description doesn't need to explain return values. However, for a tool with no annotations and potential device interaction complexity, the description is minimal—it covers the output but lacks context about when and how to use it effectively with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter. The description adds no parameter information beyond what's in the schema, maintaining the baseline score of 3 since the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does ('A PNG screenshot of the current Android device screen') with specific details about the output format (PNG, width, height, base64-encoded image data). It distinguishes from siblings like 'snapshot_ui' by focusing on raw screen capture rather than UI analysis, though the distinction could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'snapshot_ui' or 'detect_ui_change'. The input schema includes detailed instructions about device selection, but the description itself lacks explicit usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses safety traits (parsed safely via shlex, no shell injection) and implies execution behavior, but doesn't cover rate limits, auth needs, or error handling beyond device serial instructions in the schema. It adds useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loaded with the core purpose. It's appropriately sized and structured without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 100% schema coverage, and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It covers safety aspects but could benefit from more context on tool scope versus siblings. The output schema likely handles return values, reducing the need for description details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool executes an ADB command and mentions safe parsing via shlex, but it's vague about what ADB commands are (Android Debug Bridge) and doesn't clearly distinguish from siblings like press_key or type_text which are specific ADB operations. It doesn't specify the verb+resource combination explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like press_key or type_text, which are specific ADB operations. The description lacks explicit when/when-not instructions or alternatives, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires device accessibility services, what happens on invalid coordinates, if it waits for UI response, or potential side effects. The schema's device_serial description adds some behavioral context about multi-device handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste - every word contributes to understanding the tool's function. Front-loaded with the core action, appropriately sized for a simple gesture tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations but 100% schema coverage and an output schema, the description is minimally adequate. It covers the basic action but lacks context about Android-specific requirements, error conditions, or interaction patterns with sibling tools. The schema compensates for parameter documentation, but behavioral context is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond implying coordinate-based interaction. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have explained coordinate system orientation or tap duration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('tap gesture') and target resource ('Android screen'), with precise scope ('at the given pixel coordinates'). It distinguishes from siblings like swipe_screen (continuous gesture) or press_key (keyboard input), providing unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (Android device interaction) but doesn't explicitly state when to use this versus alternatives like detect_ui_change or get_ui_hierarchy. However, the input schema's device_serial parameter description provides strong operational guidance about device selection and error handling, which compensates partially.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior regarding device selection, error handling, and session persistence for the 'device_serial' parameter, though it doesn't cover aspects like permissions, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, stating the core purpose in a single sentence. The detailed usage guidelines are efficiently integrated into the parameter descriptions in the schema, avoiding redundancy and maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (device management, error handling) and the presence of an output schema (which reduces need to describe return values), the description is mostly complete. It covers key behavioral aspects but lacks details on permissions, side effects, or Android-specific constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal semantic context beyond the schema, such as implying the tool's focus on Android apps, but doesn't provide additional parameter insights beyond what's in the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as launching an Android app using a component name, specifying the format. It distinguishes itself from siblings like 'press_key' or 'tap_screen' by focusing on app launching, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance by specifying when to omit the 'device_serial' parameter ('only when a single device is connected') and provides detailed error-handling instructions for multi-device scenarios, including a hard requirement to stop and present options to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool returns (device list with specific attributes) but doesn't disclose behavioral traits like whether this requires ADB setup, if it's a real-time snapshot, error handling, or performance characteristics. It adds basic context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and output. Every word earns its place with no redundancy or wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and what data it returns. With an output schema present, the description doesn't need to detail return values, but could benefit from more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, and it appropriately focuses on the tool's function. A baseline of 4 is applied for zero-parameter tools, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb+resource: 'list' (verb) 'Android devices' (resource). It distinguishes from siblings by specifying 'currently visible to ADB' and listing the data returned (serial numbers, connection state, model names), which is distinct from UI interaction or command execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to see all connected Android devices via ADB. It doesn't explicitly state when NOT to use it or name alternatives, but the context is clear enough for an agent to infer this is for device discovery rather than interaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior as sending a key event, implying an action on the device. The input schema adds critical behavioral context, such as error handling for multi-device scenarios and session persistence, which compensates well for the lack of 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without waste. It is front-loaded and appropriately sized, earning its place by clearly conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (device interaction), no annotations, and an output schema (which handles return values), the description combined with the detailed input schema provides complete context. The schema covers all parameters, usage rules, and error scenarios, making it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying keycode usage, but the schema provides examples and constraints. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('sent to the Android device') and resource ('key event'), specifying it uses a keycode integer. However, it doesn't differentiate from siblings like 'tap_screen' or 'type_text' beyond the general 'key event' concept, making it clear but not sibling-distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('sent to the Android device using the given keycode integer'), and the input schema provides detailed guidance on device_serial usage, including when to omit it, error handling, and session management. This offers clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains polling behavior, timeout handling, efficiency considerations (omitting XML by default), and the need for device serial management in multi-device scenarios. It doesn't cover rate limits or authentication needs, but provides substantial operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. Every sentence earns its place: first sentence states core functionality, second explains efficiency trade-off, third provides usage pattern, fourth specifies alternative use case, and fifth gives exclusion rule. No wasted words, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (polling, change detection, device management) and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage patterns, efficiency considerations, device management requirements, and distinctions from sibling tools, providing all necessary context for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds some context about parameter usage (e.g., explaining when to use baseline_token vs not, and efficiency implications of return_hierarchy), but doesn't provide significant semantic value beyond what's already documented in the comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('polls', 'returns when the screen content changes') and resources ('UI hierarchy'), distinguishing it from siblings like get_ui_hierarchy (for reading current state) and snapshot_ui (for capturing baselines). It explicitly defines what the tool does: monitoring UI changes after an action with timeout handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives. It specifies: use with baseline_token for efficient change detection after snapshot_ui, use without baseline_token only for slow transitions, and do not use for reading current screen state (use get_ui_hierarchy instead). This covers both proper usage scenarios and clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining key behavioral aspects: it returns XML format, should be used sparingly for performance reasons, and has a specific use case pattern with sibling tools. It doesn't mention error handling or performance characteristics beyond usage frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with three focused sentences: purpose statement, usage guidance, and alternative approach. Every sentence adds value with zero redundancy or fluff. The most important information (what it returns) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a read-only tool with good annotations (though none provided) and output schema. The description covers purpose, usage patterns, performance considerations, and relationships with sibling tools. With output schema handling return values, no additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Returns') and resource ('current Android screen as an XML UI hierarchy'). It distinguishes from siblings by focusing on XML hierarchy extraction rather than screenshots, change detection, or direct interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this when you need to locate element coordinates, read text, or find resource IDs to interact with.' It also specifies when NOT to use it ('Do not call this after every action') and names an alternative approach ('use snapshot_ui before the action and detect_ui_change after').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns a short token rather than full UI content, explains how the token should be used with detect_ui_change, and clarifies that this avoids loading the full XML hierarchy. It doesn't mention performance characteristics, error conditions, or authentication needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each serve a distinct purpose: stating the core function, explaining when to use it, describing the token's purpose, and providing exclusion criteria. There's no wasted text, and key information appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, 100% schema coverage, and the presence of an output schema (which handles return values), the description provides excellent contextual completeness. It explains the tool's purpose, usage guidelines, behavioral characteristics, and relationship to sibling tools without needing to repeat schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter (device_serial). The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('takes a lightweight snapshot of the current UI state') and distinguishes it from sibling tools ('not read its content', 'use get_ui_hierarchy for that'). It explicitly contrasts with get_ui_hierarchy for reading/interacting with screen elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('before performing an action... when you only need to confirm the screen changed') and when not to use it ('Do not use this when you need to read or interact with screen elements'). It names the alternative tool (get_ui_hierarchy) and explains the purpose of the returned token for detect_ui_change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies that spaces are encoded automatically (a key implementation detail) and the input schema provides extensive device_serial handling instructions. However, it doesn't mention error conditions beyond the multi-device case or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste - the first states core functionality, the second adds crucial behavioral detail about space encoding. Every word earns its place and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, 100% schema coverage, and presence of an output schema, the description provides complete context. It covers the core functionality, adds behavioral details, and the schema handles parameter documentation thoroughly. No significant gaps remain for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds context about the 'text' parameter's purpose ('into the focused input field') and the schema provides rich semantics for device_serial including multi-device error handling. This exceeds baseline but doesn't fully explain all parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Text input') and target ('currently focused Android input field'), distinguishing it from siblings like tap_screen or press_key. It precisely defines the verb+resource combination without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when an Android input field is focused) but doesn't explicitly state when to use alternatives like press_key for special keys or tap_screen for navigation. It provides clear operational context but lacks explicit comparison with sibling tools.
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:

[![agent-droid-bridge MCP server](https://glama.ai/mcp/servers/Neverlow512/agent-droid-bridge/badges/card.svg)](https://glama.ai/mcp/servers/Neverlow512/agent-droid-bridge)

Score Badge

Copy to your README.md:

[![agent-droid-bridge MCP server](https://glama.ai/mcp/servers/Neverlow512/agent-droid-bridge/badges/score.svg)](https://glama.ai/mcp/servers/Neverlow512/agent-droid-bridge)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Neverlow512/agent-droid-bridge'

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