DroidMind

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The top-level tools are clearly categorized, but the internal actions within each mega-tool can overlap (e.g., start_intent appears in both android-app and android-ui), causing potential ambiguity for an agent. Additionally, the bundling of many operations under one tool name makes it less obvious which tool handles a specific action.
Naming Consistency5/5
All tool names follow a consistent 'android-<category>' pattern, and internal actions use a uniform snake_case style. The naming is predictable and readable across the entire server.
Tool Count4/5
With 8 tools, the count is reasonable for an Android device management server. However, the bundling of many actions into each tool makes the surface feel slightly under-tooled, though still within the effective range.
Completeness4/5
The tool set covers major areas: app management, device control, diagnostics, file operations, logs, screenshots, shell, and UI. Some gaps exist (e.g., network or settings management), but the core workflows for common Android tasks are well addressed.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only lists parameters and actions but does not describe side effects (e.g., app changes), prerequisites (e.g., unlocked device), or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with Args and Returns sections, but it is somewhat lengthy and could be more concise by grouping related parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no schema descriptions, and no annotations, the description provides basic parameter explanations but lacks usage context, error handling, or return value details beyond 'a string message'.
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 description adds meaning to each parameter (e.g., 'x: X coordinate (for tap)'), compensating for the 0% schema description coverage. However, it could provide more detail on ranges or formats.
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 it performs various UI interaction operations on an Android device and lists the supported actions (tap, swipe, etc.). This distinguishes it from sibling tools like android-device or android-app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or what other tools exist for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states it gets a screenshot but does not disclose behavioral traits such as whether the device needs to be unlocked, any side effects, or latency considerations. For a read operation, this minimal disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a structured Args/Returns format, front-loading the purpose. It is slightly verbose due to docstring conventions but remains efficient. The inclusion of 'ctx' parameter not in schema is a minor inconsistency.
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 (screenshot) and lack of output schema, the description adequately covers functionality, parameters, and return type. It could mention prerequisites like device connection, but overall completeness is satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining 'serial: Device serial number' and 'quality: JPEG quality (1-100, lower means smaller file size)'. It partially compensates for missing schema descriptions, though the 'ctx' parameter in the docstring is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a screenshot from a device,' specifying the action and resource. It distinctly separates from sibling tools like android-app, android-device, etc., which focus on other device aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention contexts where a screenshot is appropriate or when to use other tools like android-shell or android-file.
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 are absent, so the description carries full burden. It adds behavioral context about output limits (max_lines with sign logic, max_size, defaults) but does not disclose potential destructive effects, security implications, or error conditions of running shell commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, making it easy to parse. Slightly verbose but each sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that runs arbitrary commands, the description adequately covers input parameters but lacks details on output format (despite having output schema) and potential risks or prerequisites, such as device connectivity or authentication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains all four parameters: serial, command, max_lines (with positive/negative line logic and default), and max_size (default and limit). This adds significant meaning beyond the schema's type-only definitions.
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: 'Run a shell command on the device.' It uses a specific verb (Run) and resource (shell command) with context (on the device), and distinguishes from sibling tools that manage apps, devices, diagnostics, files, logs, screenshots, and UI.
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, nor any conditions for appropriate use or exclusions. It only lists parameters without contextual usage advice.
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 explains that output_path defaults to a temp file and is summarized, and mentions timeout defaults. However, it does not disclose potential side effects like performance impact or device lock requirements. It is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate Args and Returns sections, and front-loads the purpose. It is detailed but not excessively verbose; every sentence adds value. Minor redundancy in separately explaining actions, but overall efficient.
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 (7 params, no annotations, output schema exists), the description covers all parameters, default behaviors, and return value. It omits prerequisites like device connectivity and error handling, but is reasonably complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning to all parameters: serial, action, output_path, include_screenshots, package_or_pid, native, and timeout_seconds. It explains defaults and behavior for optional paths. This compensates well for the schema's lack of 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 'Perform diagnostic operations like capturing bug reports or heap dumps.' It uses a specific verb and resource, and distinguishes from sibling tools that focus on other aspects like app, device, file, log, screenshot, shell, and UI. This leaves no ambiguity about the tool's purpose.
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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention context such as troubleshooting device issues or any exclusions. The intended usage is only implied by the parameter descriptions, but no explicit when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It details each action's required and optional parameters and notes return type. However, it lacks disclosure of side effects (e.g., reboot disconnects device) and error cases. Still, it is fairly transparent, earning a 4.
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 well-structured with a brief intro, standard arg list, and a clear enumeration of actions with their specific arguments. Every sentence adds value; no fluff. Score 5 for efficient organization.
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 5 parameters, 5 actions, and no annotations, the description covers action-parameter dependencies and return type. It lacks error handling or examples, but is otherwise complete for a moderately complex tool. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively maps parameters to actions, clarifying which parameters are needed for which operation. This adds significant meaning beyond the schema, though detailed constraints (e.g., valid formats) are omitted. Score 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs device management operations and lists actions via an enum. While it does not explicitly differentiate from sibling tools like android-shell or android-diag, the action list provides clarity on scope. A score of 4 reflects clear purpose with minor sibling differentiation gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by enumerating actions but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings. No alternatives or exclusions are mentioned. Score 3 for implied but unguided usage.
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 provided, so the description carries full burden. It details required vs optional parameters per action but does not disclose preconditions (e.g., device connection), side effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, parameter list, action list, and per-action details. Though lengthy, it is justified given the complexity of 11 actions; however, the inclusion of 'ctx' parameter not in schema is a minor inconsistency.
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 lack of annotations and low schema coverage, the description covers required/optional params per action and notes the return type. However, it omits device prerequisites, error scenarios, and includes an undocumented 'ctx' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining each parameter's purpose and mapping them to specific actions (e.g., 'apk_path' for install, 'package' for uninstall).
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 performs 'various application management operations on an Android device' and lists 11 specific actions, making it distinct from sibling tools like android-shell or android-ui.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool consolidates app-related actions and lists each action with required parameters, but does not explicitly guide when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 each action and its parameters, but lacks details on performance implications, error conditions, or prerequisites (e.g., USB debugging enabled). For a read-heavy tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with bullet points for each action, front-loading the purpose. Every sentence adds value, though a slightly more succinct summary of all actions could improve conciseness.
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 (8 parameters, 5 actions), the description covers all necessary usage details. The output schema is not described, but the return type ('string message') is mentioned. This is largely sufficient for an agent to decide and execute.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds significant meaning: it maps each parameter to specific actions, explains optional vs required, and provides defaults. This fully compensates for the schema's lack of 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 it performs 'various log retrieval operations on an Android device' and lists five specific actions via the 'action' parameter. This distinguishes it from siblings like android-app, android-device, etc., which handle different domains.
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 explains that the 'action' parameter determines the operation and details which arguments are required or optional for each action. While it does not explicitly contrast with siblings, the context is sufficient for an agent to choose and invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: explains each action, parameter precedence (device_path over path), defaults (max_size=100KB), and return types. Destructive operations are implied by action names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet points, front-loaded with purpose. Slightly verbose due to repeated 'Used by' lines, but every sentence adds value for an agent.
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 7 parameters, 2 required, no annotations, and an output schema exists, the description provides complete guidance for all actions, including parameter mapping and return types, ensuring correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions; description compensates thoroughly by explaining each parameter's purpose, which actions use them, precedence rules, and defaults, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs file and directory operations on an Android device, listing 9 distinct actions, which differentiates it from sibling tools like android-app or android-shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through action descriptions, but no explicit guidance on when to use this tool versus alternatives (e.g., android-shell for commands) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

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

Score Badge

Copy to your README.md:

[![droidmind MCP server](https://glama.ai/mcp/servers/hyperb1iss/droidmind/badges/score.svg)](https://glama.ai/mcp/servers/hyperb1iss/droidmind)

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/hyperb1iss/droidmind'

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