android-dev-mcp

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation4/5
Most tools are clearly distinct by domain or action, such as the get_* knowledge tools for architecture, UI, API, player, etc. However, some overlap exists between check_ui_fluidity and fluidity_debug_workflow, which both address UI fluidity, and between get_full_context and the individual get_* tools, though descriptions clarify their intended usage.
Naming Consistency3/5
The tool names use consistent prefixes within categories: get_ for knowledge, run_ for command execution. However, the set mixes multiple verb styles (check_, generate_, scaffold_, verify_, fluidity_debug_workflow) which reduces overall consistency, though the names remain readable and descriptive.
Tool Count3/5
With 24 tools, the server is on the heavier side, approaching the threshold where the count becomes burdensome. While each tool has a specific purpose, many knowledge tools could potentially be consolidated, making the set feel slightly over-sized for a coherent assistant.
Completeness4/5
The tool surface covers the core Android development lifecycle: knowledge retrieval, command execution, and higher-level workflows for scaffolding, UI verification, and debugging. Minor gaps exist, such as no direct tool for editing project configuration, but these can be worked around via run_bash or run_gradle.
Average 3.7/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on June 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool 'returns' templates, implying a read operation, but does not explain what happens when the 'topic' parameter is omitted, how the response is structured, or any other behavioral traits. This is a significant gap for a tool without annotations or output schema.
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 effective and front-loaded, stating the core purpose in the first sentence and listing the topics in a compact second sentence. However, the second sentence largely duplicates the schema's enum values, which is slightly redundant, though it still adds convenience by keeping key info visible without opening the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter, no annotations, and no output schema, the description is underspecified. It does not clarify the return format, default behavior when 'topic' is omitted, or how the templates are categorized. The context is too sparse to fully understand the tool's behavior without further investigation, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for explaining the parameter. It repeats the enum values ('ask-cio|few-shot|compact-tasks|anti-patterns|all') from the schema without adding deeper meaning (e.g., what 'ask-cio' actually represents or what 'few-shot CoT' entails). The first sentence adds slight context ('few-shot CoT' expands 'few-shot'), but overall the parameter semantics are barely enriched beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns token-efficient prompt templates' and names the specific topics (Ask CIO, few-shot CoT, compact tasks, anti-patterns), clearly defining the tool's action and resource. This distinguishes it from sibling tools like get_architecture_patterns or get_git_workflow, which focus on other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any preconditions, recommended scenarios, or exclude cases, and with many sibling 'get' tools present, the lack of contextual direction leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The phrase 'Returns' implies a read-only, non-destructive operation, which is useful. However, it does not disclose whether the tool executes ADB commands or merely returns them as text, nor does it mention any potential side effects, permissions, or environment requirements. This is a moderate level of transparency.
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, consisting of a single sentence plus a brief parameter hint. It avoids unnecessary fluff and front-loads the key information about what is returned. The parameter hint is slightly redundant with the schema but serves as a quick reference. Overall, it is appropriately sized and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema and no annotations, the description is responsible for providing complete context. It lists four categories of returned information but does not elaborate on what 'frame rate thresholds' or 'ACR crash analysis' entail, nor how to interpret the results. The presence of sibling tools like fluidity_debug_workflow suggests there may be related workflow logic that this description does not address. Thus, while it covers the basics, it leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'screen' with an enum of allowed values, and schema_description_coverage is 0%. The description repeats the enum values ('screen: home|player|search|all') but adds no new meaning beyond what the schema already provides. It does not explain the purpose of the parameter, its optionality, or how it affects the output. Thus, the description adds little value for understanding the parameter.
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 that the tool returns frame rate thresholds, ADB commands, Macrobenchmark templates, ACR crash analysis, and screen-specific guidance. This is a specific verb-resource pairing that conveys the tool's purpose. However, it does not explicitly distinguish itself from sibling tools like verify_ui or fluidity_debug_workflow, which may have overlapping functionality.
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 only lists what the tool returns without any context on selection criteria, prerequisites, or exclusions. Since sibling tools like get_ui_compose_standards and fluidity_debug_workflow exist, this lack of guidance makes it hard for an agent to know when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it is ambiguous whether the tool actually executes commands or merely generates them. The phrase 'runs the full fluidity debug protocol' conflicts slightly with 'generates Android CLI commands,' and there is no explanation of side effects, permissions, or what 'ACR analysis' involves. This ambiguity could lead to incorrect usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence with awkward punctuation (em dash, plus signs) and a trailing 'screen: home|player|search' that repeats schema info. It is not well-structured or concise, though it does avoid unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a workflow that generates commands, but the description does not clarify what the output should be used for or how the agent should proceed after generation. The lack of an output schema means the description should explain expected return values, but it only vaguely mentions 'ACR analysis.' It is incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no new semantic detail beyond repeating the screen enum; project_dir is only mentioned in the schema. Baseline 3 is appropriate because the schema carries the semantic load.
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 function: it runs the full fluidity debug protocol, loads standards, and generates Android CLI commands for inspection, screenshots, and ACR analysis. It distinguishes itself from sibling tools like run_android_cli by framing this as a higher-level workflow, though it could be more specific about what 'full protocol' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a complete debug workflow is needed, but it does not explicitly state when to use it instead of alternatives like run_android_cli or check_ui_fluidity. There is no mention of exclusions or fallback scenarios, leaving the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Returns test templates' indicates a read operation, but it does not disclose output details, potential side effects (e.g., file creation), or error behavior. Minimal transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a compact target pattern. It is front-loaded and every word is informative; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the essential purpose and parameter syntax. However, it does not describe the return format or provide any example output, and with no annotation or output schema, the agent must infer what a 'test template' actually looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a single parameter with an example, and the description adds a full enumeration of acceptable target values (viewmodel, repository, ui, api, all). This goes beyond the schema's brief example, adding meaningful format context.
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 returns test templates and enumerates the target taxonomy (viewmodel, repository, ui, api, all). While 'test templates' is a bit generic, it is specific enough to distinguish it from sibling tools like get_prompt_templates or get_project_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The target syntax implies usage (e.g., specifying a viewmodel), but there is no mention of when to prefer generate_tests over other test-related tools (e.g., verify_ui or scaffold_feature).
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 present, so the description must carry full behavioral disclosure. It only says 'Returns' without covering data source, response format, or any side effects. For an apparently read-only info tool, this is minimal and does not add meaningful behavioral context beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the returned content. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (no params, no output schema) the description is adequate, but it leaves ambiguity about how 'module layout' relates to sibling tools like get_architecture_patterns. More detail on scope or intended use would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. Baseline is 4 given no parameters, and 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns module layout, package naming, and file naming conventions, which is specific and action-oriented. However, it does not explicitly differentiate from sibling tools like get_architecture_patterns, which could also cover structural conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_architecture_patterns or get_ui_compose_standards. The description only states what it returns, not when it should be chosen.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists the patterns returned and does not mention whether the tool is read-only, static, or has any side effects or rate limits. This is a significant transparency gap for a get-type tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It directly states the tool's function and the list of patterns, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), but the description lacks clarity on what 'patterns' means—whether it returns code snippets, textual explanations, or links. It is minimally adequate but could be more complete by specifying the return format or content type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with no parameters, so schema description coverage is effectively 100%. Per guidelines, a baseline of 4 is appropriate for zero-parameter tools; the description adds no parameter information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns MVVM, Hilt DI, ViewModel, StateFlow, and Coroutine patterns.' This specifies both the action (returns) and the resource (specific architecture patterns), distinguishing it from sibling tools like get_api_backend_patterns and get_player_patterns.
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 given on when to use this tool versus alternatives. The description simply states what it returns, with no mention of appropriate contexts, exclusions, or relationships to sibling tools like get_full_context or get_project_structure.
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?
This description carries full burden since no annotations are provided. It says 'Returns', which hints at a read-only operation, but does not explicitly state that it has no side effects, does not modify anything, or what the output format looks like. There is no mention of errors, prerequisites (e.g., needing a git repo), or whether the data is static or dynamic. The lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a concise topic hint. It is front-loaded with the core purpose and contains no filler. Every word contributes to understanding the tool's function and parameter scope.
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?
This is a simple informational tool with one parameter and no output schema. The description is adequate to understand the high-level purpose, but it lacks details about return format or specific content for each topic. Given the simplicity, the bare minimum is met, but it is not richly contextual.
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 0%, and the description only repeats the enum values ('topic: branches|commits|commands|hooks|all') without explaining what each topic returns or how they differ. It adds minimal meaning beyond the schema, which already lists the same enum. The parameter's purpose is vaguely implied but not adequately detailed.
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 returns branch strategy, Conventional Commits, Git hooks, and alias setup. It uses a specific verb ('Returns') and identifies the resource (Git workflow configuration). It is distinct from siblings like run_git and get_cicd_commands by focusing on workflow documentation rather than execution or CI/CD.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need branch strategy, commit conventions, hooks, or aliases, use this tool. However, it does not explicitly state when not to use it or mention alternatives like run_git or get_tooling_setup. There is no exclusionary guidance, so it earns a middle score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Returns' implies a read-only operation, but no additional behavioral context is given (e.g., whether it reads from a config, runs calculations, or connects to a service). This is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, well-structured sentence, front-loading the action ('Returns') and then enumerating the specific content categories. Every word earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description enumerates all the major content areas the tool returns, which is likely complete for the intended purpose. It slightly lacks clarity on the output format, but that is not critical given the systematic listing of information types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter meanings. The schema is empty, and the description adds no parameter details, which is acceptable at the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns session hygiene related information, listing specific items: /clear vs /compact rules, context window facts, autocompact buffer thresholds, and CLAUDE.md hygiene. This specific verb and resource list distinguishes it from sibling tools like get_full_context or get_project_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the large sibling set with similar get_* naming, the description should indicate situations where session hygiene details are needed, but it does not.
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 uses 'Returns' to convey a read-only retrieval action and lists the content areas, providing a basic understanding of behavior. However, with no annotations provided, the description carries the full burden, and it does not disclose the output format or any caveats, which would be useful for a tool with no output 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 sentence that is front-loaded with 'Returns' and lists the key domains. It is concise, free of unnecessary words, and well-structured, earning top marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description is the only source of information about the return value. It names the content domains but does not describe the format or granularity of the returned standards, leaving some gaps. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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 does not need to clarify parameter semantics, and the empty schema aligns with the tool's straightforward action.
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 returns Compose screen structure, Material 3, Navigation, and Player UI standards. It uses a specific verb and identifies distinct resource areas, distinguishing it from siblings like get_project_structure and get_player_patterns, though there is some overlap with the latter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when Compose UI standards are needed, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is implicit rather than explicit, earning a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the rendering and checking process and the return value, but does not mention side effects, prerequisites, or failure modes. The workflow nature is mentioned but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs a lot of relevant information: the rendering, the cross-check, and the return value. It is concise, though somewhat dense and could be slightly clearer with structure.
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 complex workflow tool, the description provides a high-level overview but lacks details on prerequisites, interpretation of results, and integration with sibling tools. Since there is no output schema, the return value is mentioned but not elaborated. The complexity is moderate, and the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (file_path and composable_name), each with clear descriptions. The tool description does not add additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb + resource: renders a @Preview composable via Android CLI and cross-checks its semantics tree against ITGD Compose standards. It also mentions the return value, distinguishing it from siblings like run_android_cli and get_ui_compose_standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as part of an agentic workflow for UI verification, but there is no explicit when-to-use or when-not-to-use guidance, nor alternatives named. It could be clearer about when to choose this over simply getting standards or running CLI commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clarifies the content scope (setup, HLS, DRM, lifecycle) but does not explain the format or nature of the returned data (e.g., code snippets, config examples) or mention any limitations. Since this is a read-only getter, the lack of side-effect information is acceptable, but the description adds only moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all key topics without unnecessary words. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the core content areas sufficiently. It does not explain the return format, but that is not strictly required for a pattern-reference tool. The description is complete enough for basic selection and invocation, though it could add a bit more detail on what 'patterns' include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage is trivial). Per the rubric, a 0-parameter tool receives a baseline of 4, and the description does not need to clarify parameters since there are none.
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 returns ('ExoPlayer/Media3 setup, HLS, Widevine DRM, and lifecycle management in Compose'), making the purpose specific and distinct from sibling tools about architecture, UI, or API patterns. The verb 'Returns' is a bit generic, but the resource details are concrete.
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 listing specific player-related topics, so an agent can infer to use this tool when seeking Media3/HLS/DRM patterns. However, there is no explicit guidance on when to use it versus alternative pattern-getters, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Returns' implies a read-only operation, but the description does not disclose side effects, prerequisites, data source, or output format. The sparse detail leaves behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently lists the tool's output categories. Every word carries meaning, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the essential purpose and content. However, it does not specify the return format (e.g., JSON vs plaintext) or whether the information is project-specific or generic, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema. With no parameters to document, the baseline score of 4 applies. The description adds no parameter info, but none is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Returns' and clearly lists the content: Gradle build commands, flavors, signing config, and CI pipeline steps. This distinguishes it from siblings like run_gradle (execution) and get_git_workflow (version control focus).
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?
No explicit guidance on when to use this tool vs alternatives. The name and description imply it is for retrieving CI/CD command information, but no exclusions or alternative references are provided, relying on the user's inference.
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 burden of disclosing behavior. It says 'Returns,' implying a non-mutating read operation, but it does not explicitly state that the tool makes no changes, has no side effects, or clarify any limitations. For a simple reference getter this 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 a single sentence that efficiently conveys the tool's purpose and scope. It is not padded with filler, though the parenthetical list of workflows is slightly dense. Overall, it earns its place without unnecessary verbosity.
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 simplicity (one optional parameter, no output schema), the description is complete: it states exactly what will be returned and the main sections. The schema covers the parameter's default behavior. No critical information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage by describing the 'section' parameter with an enum and a description. The tool description adds meaning by mapping the enum values to actual content: commands → CLI command reference, skills → Google Skills, workflows → ITGD protocols. This goes beyond the schema's generic 'Which section to return' and helps the agent select appropriate sections.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and clearly identifies the resource: 'full Android CLI command reference, available Google Skills, and ITGD agentic workflow protocols.' This distinguishes it from sibling tools like get_architecture_patterns or run_android_cli, making the purpose unmistakable.
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 this tool is used to retrieve Android CLI references and workflow protocols, but it does not explicitly state when to use it over alternatives or when not to use it. Sibling tools like run_android_cli or get_git_workflow are not mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does disclose that the tool 'Returns' information, indicating a read-only retrieval behavior. However, it omits any details about response format, limitations, or prerequisites. Since the tool is a simple knowledge query, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that lists the key topics without any redundant information. Every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient context by naming the specific patterns and conventions it returns. It could be slightly more explicit about the return format, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (trivially). With no parameters to describe, the baseline score is 4 according to the rubric. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action ('Returns') and its resource (Retrofit, AuthInterceptor, repository patterns, error handling, streaming API conventions). This distinguishes it from sibling tools like get_architecture_patterns or get_ui_compose_standards, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when API backend patterns are needed, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or comparisons to sibling tools, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It adds context about the data source (Google Maven), the mechanism (Android CLI), and the requirement (Android Studio + CLI). However, it does not disclose whether the operation is purely read-only, potential network dependencies, or failure modes. This is a moderate level of behavioral transparency for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: first states the core function, second states the return value, third states the prerequisite. Every sentence provides necessary information without redundancy, making it well-structured and 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?
For a simple tool with one optional parameter and no output schema, the description covers the purpose, the data source, the packages, the return content, and a prerequisite. It could be slightly more complete by explaining the format of the returned versions (e.g., key-value pairs), but overall it provides enough context for an AI agent to select and invoke the 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?
The schema already provides 100% coverage with a clear description: 'Space-separated package identifiers' and the default value. The tool description adds no new parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetches' and resource 'live recommended dependency versions from Google Maven', then specifies the exact packages (agp, kotlin, compose, media3, hilt) and the output ('Returns current versions to use in build.gradle.kts'). This distinguishes it from sibling tools focused on architecture, UI standards, or CLI guides.
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?
It implies when to use this tool—whenever a developer needs current recommended dependency versions for a Gradle build—and states a prerequisite (Android Studio + Android CLI). However, it does not explicitly mention when not to use it or suggest alternative tools, such as run_android_cli for executing commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it returns stdout and requires adb on PATH, but does not disclose that adb commands can have side effects (e.g., install, push) or that some commands like logcat may run indefinitely. It also doesn't mention how stderr or exit codes are handled.
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 three short sentences that lead with the core action, then enumerate use cases, and finally state a prerequisite. Every sentence is purposeful and there is no redundant 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?
The tool is a simple pass-through to adb, and the description covers its purpose, provides examples, and notes a prerequisite. It also states the return value (stdout). However, it omits potential pitfalls like long-running commands and error handling, but these are not critical for a basic executor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (100% coverage), so the description does not need to add much. The description includes examples in the schema's command parameter, but the tool description itself adds no further parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes adb commands and returns stdout, distinguishing it from sibling tools such as run_git, run_gradle, and run_bash. It provides concrete examples of adb subcommands, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists common use cases ('Use for: adb shell, adb logcat, ...'), giving clear guidance on when to invoke this tool. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tool names imply this.
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 burden. It discloses that it returns stdout and requires git on PATH, but it does not mention side effects of mutating commands (e.g., commit, push), stderr handling, or exit codes. For a tool that can execute arbitrary git commands, this is a notable gap, but the basic behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and the example list is useful without being verbose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is mostly sufficient: it explains what it does, gives examples, and notes the path requirement. However, it lacks warnings about side effects and error behavior, which would be expected given no annotations. Still, the schema covers parameter details, and the tool's scope is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for command and cwd. The tool description lists example command values (status, diff, etc.) which adds slight context, but mostly repeats what the schema already conveys. Hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Executes a git command and returns stdout' with a specific verb and resource. The list of example subcommands (status, diff, log, add, commit, branch, push) makes the scope unambiguous and distinguishes it from siblings like run_bash and run_adb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases (git status, diff, log, add, commit, branch, push, etc.) and states a prerequisite (requires git on PATH). However, it does not explicitly say when not to use it (e.g., for non-git commands) or mention alternatives like run_bash for non-git shell operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the gradlew-vs-global-gradle fallback and the stdout return, which is useful. However, it omits details like stderr handling, exit code behavior, or potential side effects (e.g., file modifications from builds). This is a partial but not complete picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, then concisely covering fallback behavior and usage examples. Every sentence earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple command executor with two parameters and no output schema, the description is quite complete. It covers what the tool does, how the executable is selected, and typical use cases. It doesn't address error handling or environment prerequisites, but these are not critical for an agent to begin using it effectively. Given the tool's moderate complexity, the description meets the bar.
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 input schema already fully documents both parameters (cwd and command). The description's examples ('build', 'assembleDebug') align exactly with schema examples, adding no additional semantic value. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Executes a Gradle command and returns stdout', which is a specific verb and resource. It distinguishes itself from sibling tools like run_bash or run_android_cli by focusing solely on Gradle commands, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use-case examples ('build, assembleDebug, test, lint, dependencies') and explains when to use the tool. While it doesn't explicitly mention when not to use it (e.g., for non-Gradle commands), the clear scope and sibling context imply the boundary. This is strong guidance, though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds the behavioral note 'Call once at session start' but doesn't disclose potential large payload size, idempotency, or any performance costs. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that front-loads the action and scope. Every word contributes meaning; no redundancy.
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 zero parameters and no output schema, the description provides adequate context for selection and invocation. It states what is returned (complete context across all knowledge domains) and when to call it. Could enumerate domains, but sibling tool names provide that 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 zero parameters, so schema coverage is 100%. Baseline for no params is 4; description doesn't need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' + resource 'complete ITGD Android project context' and scope 'all knowledge domains'. It clearly differentiates itself from sibling tools that target individual domains (e.g., get_project_structure, get_architecture_patterns).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call once at session start', providing a clear when-to-use. However, it doesn't mention when not to use it or name alternatives, though sibling tools imply specialization for focused lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that behavior changes based on the optional task parameter (general guide vs. specific recommendation). However, it does not describe the guide's content, return format, or any potential side effects. For a read-only lookup, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and a concise explanation of the optional parameter. Every word earns its place; no redundancy or fluff. It is a model of efficient, clear writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema, no annotations), the description covers core use: what it returns and how to get a recommendation. It could improve by specifying what the 'routing guide' includes (e.g., criteria, model use cases) or the output format. Still, it's enough for basic invocation without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'task' parameter with 100% coverage, so the baseline is 3. The description adds behavioral meaning: passing a task yields a specific recommendation, while omitting it returns a general guide. This goes beyond the schema's simple 'Describe the task' and clarifies the parameter's effect on the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Returns Haiku/Sonnet/Opus routing guide.' The verb 'Returns' and specific resource (routing guide for model families) make purpose unmistakable. The optional task parameter adds nuance, clarifying it can also provide a tailored recommendation. This clearly distinguishes it from sibling get_* tools that focus on context, structure, or patterns.
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 gives clear usage guidance: 'Optionally pass task description for a specific recommendation.' This implies that omitting the task returns a general guide, and passing it yields a tailored one. While it doesn't explicitly mention alternative tools, sibling names make it obvious that only this tool handles model routing, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It states that stdout is returned and that the Android CLI must be installed, which is useful. Yet it omits behavior on stderr, exit codes, or error handling, leaving potential ambiguity for a command executor.
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 concise and front-loaded, with the action in the first sentence. The subsequent list of subcommands is dense but directly relevant, and the prerequisite is stated in one short clause. No waste.
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 and rich schema (cwd and command with examples), the description covers the main aspects: what it does, when to use it, and a requirement. It could also mention handling of non-zero exits or stderr, but this is likely not critical for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema includes descriptive examples. The description adds value by listing the exact Android CLI subcommands to use, giving the agent a better sense of what goes in the 'command' parameter beyond the schema's single example.
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 'Executes an Android CLI command and returns stdout', which is a specific verb and resource. It further lists concrete subcommands (e.g., 'android create', 'android run', 'studio analyze-file'), distinguishing it from sibling tools like run_adb or run_bash.
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 'Use for:' line enumerates exact use cases, giving clear context for when to choose this tool. It also mentions the prerequisite of having the Android CLI installed. However, it does not explicitly state when not to use it or name alternatives, though the sibling list implies differentiation.
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 of behavioral disclosure. It mentions that it returns stdout/stderr, but does not disclose potential side effects of arbitrary command execution, permissions, or environmental constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly states the purpose and usage, with no redundancy. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's core function, return values, and usage context. Given its simple two-parameter schema and lack of output schema, the description is complete enough for most scenarios, though it could mention potential side effects or execution environment.
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% and both parameters are described in the schema. The description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary shell commands and returns stdout/stderr. It explicitly differentiates itself from sibling tools by directing use to anything not covered by run_adb, run_git, run_gradle, and run_android_cli.
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 says to use this tool for anything not covered by specific sibling tools, providing clear when-to-use guidance and implicit 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, the description discloses a key behavioral trait: the tool returns a scaffold command for Claude to execute rather than executing it directly. It also lists the workflow steps. It does not detail side effects, permissions, or failure modes, but the core non-execution behavior is clearly stated.
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 concise and front-loaded, using two sentences to convey the workflow, return value, and step sequence. Every phrase adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, return value (context, version data, command), and workflow steps. Without an output schema, it lacks detailed structure of the returned data, but it provides sufficient guidance for an agent to know what to expect and that the command should be executed later.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (feature_name and template) are fully described in the schema with clear explanations and a default for template. The description adds no additional parameter context, but schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as an agentic workflow that loads ITGD conventions, fetches live versions, and scaffolds a new feature by returning a CLI command. It distinguishes itself from sibling tools like get_full_context and get_live_versions by being a composite orchestration step.
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 by showing the workflow steps (get_full_context → get_live_versions → android create guidance), indicating this is for end-to-end scaffolding. However, it does not explicitly state when to use this instead of running the steps individually or provide alternative tool comparisons.
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 burden of behavioral disclosure. By saying 'Returns install guides', it makes clear this is an informational retrieval operation with no side effects, which is important for safety. It does not overpromise installation or execution, so the agent understands it is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a compact parameter specification. Every word adds value, and it is front-loaded with the primary action. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one param, no output schema), the description is adequately complete. It explains what is returned (install guides) and what the parameter does. A slight gap exists in not clarifying the output format or the effect of omitting the parameter, but these are minor for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one enum parameter with zero description coverage, but the description compensates by listing the allowed values ('tool: graphify|rtk|caveman|superpowers|all'). However, it does not specify the default behavior when the optional parameter is omitted, which would have made the semantics clearer.
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 'Returns install guides' for four specific tools, which distinguishes it from sibling tools that retrieve other types of context. The verb 'returns' plus the resource list makes 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage: when you need install guides for the listed tools. It does not explicitly mention alternatives or when not to use it, but the niche purpose is clear enough that an agent can infer appropriate use. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![android-dev-mcp MCP server](https://glama.ai/mcp/servers/maheshmishra271090-design/android-dev-mcp/badges/card.svg)](https://glama.ai/mcp/servers/maheshmishra271090-design/android-dev-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maheshmishra271090-design/android-dev-mcp'

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