AndroidBuildMCP

by dev-jackson

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools have clear, distinct purposes (build, device, UI, logging). A few pairs like snapshot_ui and screenshot with annotate could be confused, but descriptions clarify their complementary roles. Overall, the tool set is well-separated into functional areas.
Naming Consistency5/5
Tools overwhelmingly follow a verb_noun snake_case pattern (build_app, list_devices, start_log_capture). Minor exceptions like statusbar_demo_mode and session_set_defaults are still intuitive and consistent in style. No mixing of camelCase or arbitrary names.
Tool Count2/5
53 tools is excessive given the rule that 25+ is too many. While the scope is broad and each tool has a purpose, the sheer number creates navigation overhead and can overwhelm an agent. A more consolidated set would be better.
Completeness5/5
The tool surface thoroughly covers the Android development lifecycle: project discovery, building, testing, linting, device/emulator management, UI automation, logging, coverage, and scaffolding. There are no major dead ends or obvious missing operations for the stated purpose.
Average 3.9/5 across 53 of 53 tools scored. Lowest: 3.1/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that the tool runs lint and returns a report summary; it does not mention whether the operation is read-only, whether it triggers a build, how long it may take, or what happens on failure. This is a significant gap for a tool with no annotation safety hints.
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 with no filler. It efficiently conveys the action ('Run Android Lint') and the output ('return the textual report summary'), and the 'lint<Variant>' notation is a dense but clear way to express the task naming.
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 relatively simple tool, and the description communicates the core purpose and output well. However, with no output schema or annotations, additional context about the report summary's content and any side effects would improve completeness. It is minimally viable as-is.
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 covers 100% of the parameters with descriptions and defaults, so the baseline is 3. The description adds minimal value beyond the schema, though 'lint<Variant>' hints that the variant parameter directly maps to the Gradle task name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: running Android Lint and returning a textual report summary. It includes the Gradle task naming pattern 'lint<Variant>', which helps distinguish it from other build/test tools, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like build_app, test_app, or other analysis tools. It does not mention prerequisites, exclusions, or preferred usage contexts, leaving the agent without selection criteria.
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?
Annotation Contradiction: The description says 'Clear all session defaults' which is a mutating action, yet annotations declare readOnlyHint=true. This is a direct contradiction, and the description does not clarify the actual side effects or why the read-only hint is present.
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 is front-loaded with the action and resource, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the contradiction between the mutating description and readOnlyHint likely confuses an agent. It lacks context about persistence, idempotency, or the effect on session state, so it is incomplete for safe and correct invocation.
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% and the schema already documents 'keys' as 'Keys to clear; omit to clear everything'. The description's phrase 'or only the listed keys' adds marginal value but does not elevate beyond baseline.
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 'Clear all session defaults, or only the listed keys' with a specific verb ('Clear') and resource ('session defaults'), and it distinguishes itself from sibling tools like session_set_defaults and session_show_defaults.
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 intended use is implied by the name and sibling context, but the description does not explicitly state when to prefer this tool over related ones (e.g., session_set_defaults) or mention any exclusions. It provides basic usage but no explicit when/when-not guidance.
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 disclose behavioral traits. It only states the action without mentioning that uninstalling permanently removes the app and its data, or any other side effects, reversibility, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, earning a high score for structure.
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 destructive operation with no annotations and no output schema, the description is incomplete. It lacks essential context about data loss, what happens if the app is not installed, or any prerequisites, making it insufficient for a safe and informed invocation.
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 description coverage is 100% for both parameters (appId and serial). The description adds no additional parameter context beyond what the schema already provides, 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 uses a specific verb ('uninstall') with a clear resource ('app') and target ('device/emulator'), making it unambiguous and distinguishing it from sibling tools like install_app or launch_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?
The description offers no guidance on when to use this tool versus alternatives such as clear_app_data or stop_app. It neither states explicit context nor exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. 'Run gradle clean' implies a destructive operation (deleting build outputs) but does not explicitly state what gets removed, whether it is reversible, or any other behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and one optional parameter, the description is minimally viable but lacks critical behavioral context: there is no mention of what 'clean' removes, whether it affects dependencies, or what output/result the agent can expect. It is adequate only for an agent already familiar with Gradle clean semantics.
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 baseline is 3. The description adds no extra meaning beyond the schema; the optional projectDir parameter is adequately described in the schema itself.
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 a specific action: run Gradle Clean. It clearly distinguishes this from sibling build/run/test tools by naming the exact command and its 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?
No guidance is provided on when to use this tool versus alternatives such as build_app or stop_gradle. The description merely states what it does without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the action and explicitly mentions 'running emulator,' but does not disclose behavior such as error handling when emulator is not running, verification feedback, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence with no extraneous words. It is directly front-loaded with the primary action.
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 simplicity of the tool and the full schema coverage, the description provides only the essential action. It lacks contextual information such as when to use it (e.g., after booting an emulator) and potential edge cases, but it is minimally adequate for a straightforward mutator.
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?
Input schema covers all three parameters (serial, latitude, longitude) with clear descriptions. The tool description adds no additional parameter semantics, so baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the GPS location of a running emulator, using a specific verb and resource. It distinguishes from sibling tools like boot_emulator and kill_emulator by focusing on location control.
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, prerequisites, or alternatives. The only cue is 'running emulator' in the description, but no explicit when-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the output ('parsed summary') and a prerequisite (booted device), but it omits whether the tool builds the project, installs the app, or modifies the device state, and does not hint at runtime duration. For a test runner, these are significant behavioral details an agent would need.
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 remarkably concise: two short sentences with no padding. The parenthetical adds a useful technical reference (the Gradle task name), and every word earns its place. Excellent structure for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must supply all contextual essentials. It covers the core action, a key prerequisite, and the output nature, but the 'parsed summary' is vague and build/install behavior is omitted. For a tool with three optional parameters and moderate complexity, this is a minimal but not fully complete description.
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 provides 100% coverage of all three parameters (module, variant, projectDir), each with a description. The tool description adds no additional parameter semantics, so it simply meets the baseline without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run instrumented tests'), the target resource ('on a connected device/emulator'), and even names the underlying Gradle task ('connected<Variant>AndroidTest'). While it doesn't explicitly contrast with sibling tools like test_app, the 'instrumented' qualifier and device/emulator context effectively differentiate it.
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 communicates a prerequisite ('Requires a booted device') and implies the use case for instrumented tests on a device/emulator. However, it does not explicitly state when to use this tool instead of alternatives like test_app, nor does it mention when not to use it. The guidance is present but 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 of behavioral disclosure. It adds the key trait 'permanently', which indicates irreversibility. However, it does not disclose other relevant behaviors such as whether the AVD must be stopped first, whether associated files are removed, or error behavior if the name does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action. Every word contributes meaningful information ('Delete', 'AVD', 'permanently'), and there is no redundancy 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?
For a simple, single-parameter tool, the description adequately covers the core action and its irreversible consequence. It is complete enough for an agent to understand the tool's purpose. However, given the absence of annotations, it could have mentioned prerequisites or behavior when the AVD is currently running, but this is not critical for a tool this straightforward.
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 for the single parameter 'name' is 100%, with the schema already stating 'AVD name to delete'. The description adds no additional meaning or usage details for this parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('an AVD'), with the modifier 'permanently' adding important scope. It is unambiguous and easily understood. However, it does not explicitly differentiate from siblings like 'kill_emulator', which stops but does not delete, so it falls short of a perfect score.
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?
Provides no guidance on when to use this tool versus alternatives. It does not mention that deletion is irreversible, nor does it distinguish from 'kill_emulator' or note any prerequisites (e.g., stopping the AVD first). There is no 'when-not-to-use' or alternative references.
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?
Annotations declare readOnlyHint=true, but the description describes an interactive drag gesture that inherently changes UI state, creating a direct contradiction. No additional behavioral context is provided beyond the percentage tip.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and a useful tip. No filler or redundancy.
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?
Despite the schema covering parameters, the tool lacks an output schema and the description does not explain return values, failure modes, or side effects. The annotation contradiction further weakens trust. For a 10-parameter interaction tool, this is insufficiently 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?
All 10 parameters have schema descriptions with 100% coverage, so the baseline is 3. The description adds practical value by explaining that percentage coordinates (0-1) are safer for positions estimated from screenshots, going beyond the raw schema 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 uses a specific verb ('Drag') and resource ('an element') and states the action is from one point to another, clearly distinguishing it from sibling tools like tap or swipe by naming the input type 'draganddrop'.
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 provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools such as swipe. It only implies usage by describing the drag action itself and gives a tip about using percentages for screenshots, which is a parameter-level hint rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects such as potential loss of unsaved data, whether the shutdown is graceful or forceful, or any permission requirements. The inclusion of 'adb emu kill' hints at a forced kill but doesn't explain consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately conveys the action. It is concise and free of unnecessary wording, earning a perfect score.
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?
For a simple tool with one optional parameter and no output schema, the description plus schema fully cover the necessary information. The parenthetical command clarifies the mechanism, and the schema explains the default behavior. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the sole parameter 'serial', with a clear description of its default behavior. The tool description adds no parameter-specific information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Shut down a running emulator' with the specific command 'adb emu kill'. This is a specific verb+resource combination that distinguishes it from sibling tools like boot_emulator or delete_avd.
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 merely states what it does without specifying contexts, prerequisites, or exclusions. No mention of boot_emulator or other related tools is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the underlying command ('cmd uimode night') but does not disclose potential side effects, persistence of the setting, or any requirements such as a running emulator. The agent learns what the tool does but not what the consequences or preconditions are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource. It is concise with no filler, and the parenthetical command reference adds a technical detail without bloating the text. Every word earns its place.
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 two-parameter tool with no output schema and no annotations. The description, combined with the full schema, is sufficient for a basic understanding of the tool's function. However, it lacks context on what happens after invoking (e.g., return value, errors, or confirmation) and does not explain the serial default behavior, making it minimally complete but with room for improvement.
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%, with both parameters ('mode' and 'serial') described in the schema. The description adds no extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate. The mention of 'cmd uimode night' hints at the underlying mechanism but does not clarify the parameters 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 clearly states the action ('Switch'), the resource ('a device/emulator'), and the scope ('between dark and light mode'). It is a specific, verb-driven purpose that leaves no ambiguity about what the tool does, and it stands apart from all sibling tools which cover unrelated functionality.
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: to change the appearance mode of a device/emulator. However, it does not explicitly state when to use this tool versus alternatives (though no direct alternative exists among siblings) or provide context like prerequisites (e.g., device must be booted). It leans on the reader to infer usage from the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Set' (a write action) while annotations declare readOnlyHint: true. This is an annotation contradiction. The description also doesn't disclose that defaults overwrite existing session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words, front-loaded with the primary action.
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?
Appropriately sized for a simple setter with all optional parameters; covers purpose and usage timing. However, the annotation contradiction undermines overall clarity, but the description itself is complete for the tool's function.
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 covers 100% of parameters with descriptions. The description adds group context (defaults for omitted args) but doesn't detail individual parameter semantics beyond 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 explicitly states the tool's function: 'Set default projectDir/module/variant/serial/appId' used by other tools when arguments are omitted. It clearly distinguishes from sibling session_show_defaults and session_clear_defaults by being the setter.
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?
Provides temporal guidance: 'Set these once after discovering the project.' This implies using it after project discovery and before other operations that rely on defaults. It doesn't explicitly name alternatives but the sibling set makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates the read-only nature, and the description adds no behavioral context beyond that. It does not mention what is shown, how to interpret the output, or any potential effects, offering no value over the annotation.
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 precisely conveys the tool's function. No filler or redundant information is present, making it optimally concise.
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 parameters, no output schema), the description is sufficient for an agent to understand what it does. However, it could slightly improve by mentioning the return value, but the name and title already imply it shows the current defaults.
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 parameters, the schema is empty and there is nothing to document. According to the rubric, 0 params warrant a baseline of 4, and the description does not need to compensate for missing parameter information.
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 'Show the current session defaults' uses a specific verb ('show') and resource ('session defaults'), clearly distinguishing it from sibling tools like session_set_defaults and session_clear_defaults. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention related tools or provide any context about when viewing defaults would be appropriate, leaving the agent without direction.
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 for behavioral disclosure. It does state 'force-stop' which indicates a destructive/kill operation, and it names the exact command, giving some transparency. However, it does not mention side effects (e.g., app state loss, background services killed), permissions, or behavior if the app is not running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and includes the underlying command for clarity. Every word is necessary, and there is no wasted space.
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 two optional parameters and no output schema, the description is largely sufficient. It clearly states the action and mechanism. Minor gap: it does not mention what happens if the app is not running, but this is not critical for the tool's primary use case.
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 descriptions cover 100% of parameters (appId: 'Application id (defaults to session)', serial: 'Device serial (defaults to session or the only device)'). The tool description adds no extra parameter semantics beyond the schema, so the baseline score 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 uses the specific verb 'force-stop' and names the resource ('a running app') as well as the underlying adb command ('am force-stop'). This clearly distinguishes it from sibling tools like launch_app, uninstall_app, or clear_app_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or situations where another tool (e.g., clear_app_data or launch_app) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true contradicts the described action of tapping, which can mutate app state. The description adds useful detail about scaling and stale mappings, but the contradiction with the annotation is a serious inconsistency, forcing a low score.
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 sentences with no redundancy. Each sentence adds value: purpose, scaling correctness, and staleness warning. It is appropriately sized and front-loaded.
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 explains the essential behavior, mapping exactness, and the need to re-capture. It doesn't cover error cases or return values, but no output schema exists, so this is adequate. The annotation contradiction is not accounted for here but is penalized under transparency.
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 descriptions cover both parameters, so the baseline is 3. The description adds context about element numbers coming from a recent screenshot and going stale, but this is marginal beyond what the schema already states ('Element number from the annotated screenshot').
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 'Tap element #N from the most recent screenshot', combining a specific verb (tap) with a specific resource (annotated element). It distinguishes from sibling 'tap' by noting 'no coordinate math needed', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an annotated screenshot exists and coordinates are undesirable, and explicitly warns to re-capture after UI changes because element numbers go stale. It doesn't name alternative tools explicitly, but the context is clear and provides actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the readOnlyHint annotation. Typing text into a field is a mutating action, not a read-only operation. This is a clear annotation contradiction, warranting the lowest score per the rules.
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 compact, consisting of two sentences. The first sentence presents the core action and target, while the second adds operational detail and a limitation. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 4 parameters and no output schema, the description covers the essential aspects: the target, the keyboard-wait behavior, optional flags, and the ASCII limitation. It does not address edge cases like missing focus, but given the tool's simplicity and schema coverage, it is reasonably 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 description coverage is 100%, with each parameter (text, clear, serial, submit) already described. The description only reiterates 'clear' and 'submit' in prose and restates the ASCII limitation already present in the schema. It adds no new semantic information beyond the structured data.
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 ('Type'), the target ('the focused field'), and the input type ('ASCII text'). It distinguishes itself from siblings like tap and key_press by specifying it types a full text string into the currently focused UI element. The additional detail about waiting for the soft keyboard further clarifies its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'safe to call right after tapping a field' due to waiting for the soft keyboard. It does not explicitly name alternatives or exclusions, but this contextual guidance is sufficient for a basic understanding of its 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?
With no annotations provided, the description carries the full burden. It discloses the core mutating behavior (install) and the -r flag, but does not explain that -r replaces an existing installation or mention prerequisites like device connectivity or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loading the core action and including the exact adb command. 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 simple tool with two well-documented params and no output schema, the description covers the primary action but omits preconditions (e.g., device availability) and return behavior. It is adequate but leaves some context gaps.
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 descriptive parameter texts for both serial and apkPath. The description itself adds no parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (Install), the resource (an APK), and the target (a device/emulator). It also references the underlying adb command, clearly distinguishing it from sibling tools like build_app, launch_app, or uninstall_app.
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 stating what the tool does, but it does not explicitly mention when to use it versus alternatives or any exclusions. The schema's apkPath description hints at a workflow after build_app/get_apk_path, but that is not in the description itself.
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 discloses one important behavior: the launcher activity is resolved automatically. However, it does not mention what happens if the app is not installed, whether the call blocks until the app starts, or what the tool returns. This is a partial disclosure but insufficient for fully understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, with no redundant information. It is front-loaded with the main verb and object, making it easy to scan.
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 launch operation, the description captures the core behavior, but it lacks context on prerequisites (app installation), error handling, and return values. The absence of annotations and an output schema means the description should provide more detail to fully inform the agent. It is adequate but not comprehensive.
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 already provides descriptions for both appId and serial (100% coverage). The description adds semantic value by clarifying that appId is sufficient to launch the app and that the launcher activity is auto-resolved, so the agent doesn't need to provide an activity parameter. It does not, however, explain the serial parameter beyond what the schema says.
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 verb 'launch' and clearly identifies the resource ('app') and the key parameter ('application id'). It also differentiates from sibling tools like install_app and stop_app by specifying that launcher activity is resolved automatically. This is a clear, specific purpose statement.
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 implies this tool is used to start an app on a device, but it does not specify when to use it versus alternative tools such as build_run or test_app. No prerequisites (e.g., app must be installed) or exclusions are mentioned. The only usage hint is 'resolves the launcher activity automatically,' which tells the agent it doesn't need to provide an activity name.
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 declare readOnlyHint=true, so the read-only nature is already known. The description adds useful context about the type of events included (Java exceptions, native crashes, ANRs) but does not disclose whether the buffer is cleared after dump or if there are rate/format considerations. With annotations covering safety, this is adequate but not enriched.
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, focused sentence with no filler. It is front-loaded with the core verb and resource, and the parenthetical adds specific 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?
Given the tool's simplicity (two optional params, read-only annotation, no output schema), the description is reasonably complete. It explains what is dumped and what types of logs are included. A minor gap is that it does not specify the return format or structure, but this is not critical for a dump-like tool.
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 is fully covered (100%), so the schema itself documents the 'lines' and 'serial' parameters. The description adds no extra parameter semantics, so the baseline score 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's function with a specific verb ('Dump'), the resource ('crash log buffer'), and the content scope ('Java exceptions, native crashes, ANRs'). This distinguishes it from sibling tools like get_logs and start_log_capture.
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 crash logs are needed, but it does not explicitly contrast with sibling tools like get_logs (general logs) or start/stop_log_capture (logging capture). No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation, lowering the bar. The description adds the specific source file (settings.gradle(.kts)), which is useful context. It does not elaborate on return format or edge cases, but for a simple listing tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence: 'List modules declared in settings.gradle(.kts) of the project.' Every word carries meaning, with no filler 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 tool with one optional parameter and no output schema, the description covers the action and source. It could be slightly more explicit about return content (e.g., module names), but overall is sufficiently complete for straightforward invocation.
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% since the only parameter (projectDir) has a description. The tool description adds no additional parameter-level detail beyond what the schema already provides, 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?
Description uses the specific verb 'List' and clearly identifies the resource: 'modules declared in settings.gradle(.kts) of the project.' This distinguishes it from sibling tools like list_variants or discover_projects by specifying the exact Gradle settings file as the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need to know the Gradle modules of a project. However, there is no explicit guidance about when not to use it or which sibling tools might be alternatives (e.g., list_variants for variants). The description is minimally sufficient but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true directly contradicts the description's 'Tap the screen,' which is a physical mutation/injection action, not a read-only operation. This is a serious annotation contradiction and violates transparency expectations. No other behavioral details are disclosed beyond what annotations already state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and every sentence adds practical guidance. No filler 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 tap tool with 5 parameters, the description covers the essential coordination strategy and parameter selection. It does not explain return values (no output schema exists) or the device serial default, but these are adequately left to the schema. The annotation contradiction is noted but does not impact the completeness of the textual description.
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%, providing baseline parameter descriptions. The description adds valuable guidance on the relationship between pixel and percentage parameters, explaining when to prefer snapshot_ui coordinates versus estimating percentages from screenshots, which goes 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?
The description clearly states the tool taps the screen, using a specific action (tap) on a specific resource (screen). It also distinguishes itself from siblings like tap_element by mentioning coordinate-based input from snapshot_ui and pixel/percentage alternatives, making it 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?
Provides clear context on how to obtain coordinates (prefer snapshot_ui pixels) and when to use percentages (safer when estimating from screenshots). It does not explicitly contrast with alternatives like tap_element, but the guidance is directly useful for selecting the right parameter approach.
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 readOnlyHint=true already marking this as a safe read, the description adds useful context by enumerating the fields returned (version, SDK, path, PID). This goes beyond the annotation, though it does not cover edge cases like behavior when the app is not installed or not running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and lists key output fields. Every word adds value, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with no output schema, the description is complete: it identifies the resource (installed-app info), the scope (device), and the specific data returned. Combined with the annotation and schema coverage, no further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (appId and serial) with 100% coverage. The description does not add any additional parameter meaning or syntax details, so it meets the baseline for well-documented schemas.
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 gets installed-app info and lists the specific fields (version, target/min SDK, install path, running PID). This distinguishes it from sibling tools like get_app_id or install_app by focusing on comprehensive info retrieval rather than just the ID or installation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. It does not mention that get_app_id is a more targeted sibling or explain when this broader info is needed. The usage context is only implied by the description's content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It covers key behaviors: booting in the background, waiting for Android to finish booting, returning the adb serial, and the wipeData factory-reset side effect. It does not mention edge cases like behavior if the AVD is already booted or error handling, but the core operational details are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, with the primary action and outcome front-loaded in the first sentence. Every sentence earns its place: the second sentence clarifies an optional parameter. There is no fluff or repetition of the title/name, making it highly 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 moderate complexity of the tool (booting, waiting, returning a serial, optional wipe), the description covers the main behavior and return value adequately. The schema covers all parameters, and the lack of an output schema is acceptable because the return value (adb serial) is explicitly stated. It could have mentioned failure behavior or timeouts, but for a boot tool, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, with descriptions for all three parameters. The description adds value only for wipeData ('factory-reset the AVD on boot'), which partially mirrors the schema's 'erases all data'. It does not enrich avdName or timeoutSeconds beyond what the schema already states, so the description adds minimal extra 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?
The description clearly states the tool's action with a specific verb ('Boot') and resource ('an AVD'), and adds the key outcome ('wait until Android finishes booting' and 'Returns the adb serial'). This distinguishes it from sibling tools like kill_emulator, create_avd, and list_avds, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (before interacting with an AVD, as it boots in the background and waits for completion), but it does not explicitly state alternatives or when not to use it. No mention of other tools like kill_emulator or create_avd for comparison, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: on failure, it returns compact compiler errors with file:line format, and on success, it returns the APK path. This goes beyond a simple tautology by explaining the output format. However, it does not mention side effects like modifying the build directory or the length of the 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 concise at just two sentences. The first sentence front-loads the core purpose, and the second sentence succinctly covers both success and failure outcomes. No unnecessary words or repetition.
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 is fairly complete for a build tool. It states the build mechanism, success/failure return values, and the tool's scope. The schema handles parameter details. It does not mention potential prerequisites (e.g., project setup) or performance characteristics, but these are not critical for a standard build operation. The presence of sibling tools like clean and get_apk_path does not reduce the completeness of this tool's description.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description does not add any parameter-specific details beyond the schema. It mentions 'assemble<Variant>' but does not elaborate on the module, variant, or projectDir parameters, leaving the schema to carry the explanatory weight.
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 action: 'Build an APK with Gradle (assemble<Variant>)'. It specifies the exact Gradle task pattern and differentiates from sibling tools like build_run (which implies building and running) and get_apk_path (which retrieves the path). The verb 'build' and resource 'APK' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to build an APK, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided. Since the purpose is clear, the usage is implied rather than explicitly guided.
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 the installation mechanism (adb install -r), which implies data preservation, and states the need for appId. However, it does not mention potential wait times, required device/emulator connectivity, or the fact that this is a potentially long-running Gradle operation. Some behavioral light is shed, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action verb 'Build' leading. It packs essential details (adb install -r, appId requirement) without fluff. Every word contributes. Front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite tool with five optional parameters, the description covers the main workflow and a key prerequisite (appId). No output schema exists, so the description does not need to explain return values ambiguously. It could mention that it's a potentially long-running Gradle build and requires a connected device, but the core flow is clear. Slight room for more context, but largely 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%, so parameter semantics are already fully documented. The description adds a note that appId defaults to session, which is already in the schema ('defaults to session'). No additional parameter meaning is provided beyond schema hints. Baseline 3 is appropriate when the schema covers everything.
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 compound action: 'Build the APK, install it on a device/emulator (adb install -r), and launch the app.' This distinguishes it from siblings like build_app, install_app, and launch_app by covering all three steps. The specific verb+resource combination makes 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need the full build-install-launch pipeline. It also notes the appId requirement, which is a prerequisite. However, it does not explicitly mention alternatives or exclusions, such as using build_app alone if you only want to compile. Clear context but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It clearly discloses the destructive nature ('Clear all data') and the resulting state ('fresh-install state'), indicating irreversibility. It could mention additional effects like clearing permissions or requiring the app to be stopped, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essence without waste. The parenthetical 'pm clear' adds useful technical context, and the dash clause clarifies the outcome. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is largely complete. It explains what happens and the end state. It could add more about when to use it (e.g., for resetting an app's state before testing), but the core semantics are sufficiently clear for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (appId and serial), so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, but that is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Clear all data of an app' with the specific resource 'app' and the effect 'resets it to a fresh-install state.' The mention of 'pm clear' further anchors the operation, distinguishing it from sibling tools like uninstall_app or stop_app.
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 stating it resets to fresh-install, but it does not explicitly say when to use this tool vs alternatives such as uninstall_app or clear only specific data. No exclusions or alternative references are provided, making it an implied but not fully guided 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?
The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds a small behavioral detail (parsing from build.gradle) but does not disclose potential failure modes, return value structure, or other traits beyond what the annotation implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes a brief usage note. Every word contributes value with no redundancy or extraneous 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 simple with no output schema and safe read-only annotations. The description covers purpose, method, and usage context, while the schema handles parameters. It is adequately complete for the tool's complexity, missing only explicit return-value details which are implied.
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% (all three parameters have descriptions), so the schema already provides full parameter semantics. The description does not add any additional detail about parameters, earning the baseline score of 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 the tool's function with a specific verb ('Get') and resource ('the applicationId (package name) of a module'). It also explains the method ('parsed from its build.gradle(.kts)') and distinguishes it from siblings like get_app_info by focusing on the package name specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting it is 'Needed by install/launch/log tools,' implying when to use it as a prerequisite. However, it does not explicitly list alternatives or when-not scenarios, so it stops short of the highest rating.
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 include readOnlyHint=true, and the description adds no behavioral context beyond listing accepted key names. It does not disclose side effects, device requirements, or whether the key press is synchronous, but the action is straightforward and the readOnly annotation suggests safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and then lists valid key names. There is no redundancy 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?
For a simple two-parameter tool with full schema coverage and a readOnly annotation, this description is mostly sufficient. It supplies the key enumeration that the schema lacks, though it omits explicit usage guidance, which is not critical for this straightforward operation.
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% parameter descriptions, so a baseline of 3 applies. The description adds meaningful value by enumerating the valid values for 'key' (BACK, HOME, ENTER, etc.), which is more specific than the schema's generic 'Key name'.
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 'Press' with the resource 'hardware/navigation key' and enumerates valid key names, making its function completely clear. It implicitly distinguishes from sibling key_sequence by focusing on a single key press.
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 states what the tool does but does not specify when to use it over alternatives like key_sequence or tap, nor does it mention any prerequisites or exclusions. Usage context is only implied by the singular 'a key'.
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 a key side effect ('pull the MP4 to the local machine'), which goes beyond the tool name alone. However, it does not clarify whether the recording is deleted, what the return value is, or error handling behavior, leaving some gaps.
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 efficient and front-loaded, stating exactly what the tool does and its outcome. No redundant words or 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?
For a simple tool with one parameter and no output schema, the description adequately covers the core action and immediate result. It could mention potential failure modes or return values, but given the low complexity and full schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the parameter description 'Id from record_video_start' is sufficient. The tool description itself adds no additional parameter context beyond what the schema already provides, 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 the tool's purpose: to stop a screen recording and pull the MP4 file to the local machine. This is a specific verb+resource pattern that distinguishes it from sibling tools like record_video_start or screenshot.
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 in conjunction with record_video_start, and the parameter description reinforces this by noting the recordingId comes from that sibling tool. It provides clear context without explicitly stating alternatives, which are not needed for a stop operation.
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 communicates the main action (creating a project) and the outcome (ready for build_app), but omits side-effect details such as what happens if the directory exists, error conditions, or whether any files are overwritten. The schema's constraint on directory (must not exist or be empty) is not repeated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that packs essential details without waste. It clearly states what is created and its key properties, earning every word.
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 scaffolding tool with no output schema, the description covers the project type, key features, and readiness for build_app. It could be more complete by mentioning prerequisites or return behavior, but it is sufficient for a straightforward creation action.
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%—all parameters have descriptions in the schema itself. The tool description adds no extra parameter-level meaning; it only mentions high-level project characteristics, not how appName/packageName/directory are used.
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 starts with 'Create a new minimal Jetpack Compose app project', providing a specific verb and resource. It distinguishes itself from siblings by detailing project characteristics (single module, version catalog, Gradle wrapper) and explicitly ties to build_app, 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?
The description clearly implies use when creating a new Android project, and the mention 'ready to build with build_app' gives context on the intended workflow. However, it does not explicitly state when not to use it or name alternatives like discover_projects for existing projects.
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 readOnlyHint annotation already covering safety, the description adds valuable behavioral context: output is a 'compact list' rather than a full hierarchy, text-heavy screens are capped, and filter can search within them. These traits go beyond the annotation and help the agent anticipate behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a concise statement of purpose and output, followed by a practical tip. Every word earns its place with no repetition of schema or annotation info. Highly efficient and readable.
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?
With no output schema, the description compensates by naming the output fields and the coordinate format, which is essential for using the tool. It also covers the capping behavior and filter usage. Minor details like behavior when no elements match or exactly how 'capped' is handled are absent, but the tool is simple enough that the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters (filter and serial) with clear descriptions. The description reinforces the filter's purpose in the context of capped text-heavy screens but does not add significant additional semantics. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Dump') and resource ('current UI as a compact list of actionable elements'). It lists the exact output fields (text, id, content-desc, tap coordinates), distinguishing it from screenshot or UI interaction tools. This is unambiguous and fully differentiates it from siblings.
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 instructing to use the @(x,y) centers with tap/long_press and mentions the filter for capped text-heavy screens. However, it does not explicitly state when to choose this tool over alternatives like screenshot or wait_for_ui, nor does it provide exclusions or alternative recommendations. The guidance is contextually useful but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses background behavior, the returned sessionId, and the app-running prerequisite. However, it does not describe the file handling, how to retrieve the captured logs, or implications of the clear parameter (though schema covers that). More behavioral context, such as what happens when stop is not called, would improve 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?
Three concise sentences convey purpose, return value, and a prerequisite without redundancy. Every sentence earns its place; no filler or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers core purpose, mechanics, and a key prerequisite. It does not explain how to obtain the captured file or when to prefer this over get_logs, but given the strong schema parameter descriptions, the tool is mostly self-explanatory. A brief mention of the sessionId's role could enhance orientation, but the current level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds a small clarification ('via its pid') and the 'and/or' relationship between appId and tag, but otherwise the parameter details are already well documented 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 the tool starts capturing logcat to a file in the background, distinguishing it from siblings like stop_log_capture and get_logs. It specifies a concrete verb ('start capturing') and the resource (logcat to a file).
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 usage context by mentioning the returned sessionId for stop_log_capture and the prerequisite that the app must be running for appId filtering. It lacks an explicit comparison with get_logs or get_crash_logs, but the background-capture purpose guides selection appropriately.
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 full behavioral burden. It states the core behavior (stopping daemons) but does not disclose potential side effects like interrupting running builds or whether daemons restart automatically. It adds the usage hint but lacks safety/caveat details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. The action is front-loaded, and the usage guidance is provided as a concise parenthetical. No unnecessary words.
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 with one optional parameter and no output schema, this description sufficiently covers what the tool does and when to use it. It does not explain return values, but that is not required given no output schema. The description is complete enough for an 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 input schema already describes the lone parameter 'projectDir' with 'Project root (defaults to session)' and coverage is 100%. The description does not add further meaning about parameters, though it refers to 'the project's' which implies project scope. This meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stop the project's Gradle daemons'. This is a specific verb+resource that distinguishes it from sibling tools like build or clean. The parenthetical 'use when a build hangs or to free memory' further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly gives usage context: 'use when a build hangs or to free memory'. This tells the agent when to invoke it, though it does not mention alternatives or exclusions. Still, the guidance is clear and actionable.
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 discloses the return value (file path and last lines), but does not mention side effects on the session, file persistence, or error behavior on invalid session IDs. This is a moderate 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 one concise sentence that front-loads the key action and output with no wasted words.
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 session-stopping tool, the description covers the main behavior and return value. It doesn't provide error handling details or output structure, but these are less critical given the simple nature and clear parameter schema.
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%, with clear descriptions for sessionId and tailLines. The description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Stop a log capture session' and the output: 'return the file path plus the last lines.' It distinguishes from siblings by focusing on session termination, unlike get_logs or get_crash_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for terminating a session started by start_log_capture, as indicated by the sessionId parameter referencing that tool. It doesn't explicitly exclude alternatives, but the 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?
No annotations are provided, so the description carries the full burden. It discloses the return format (parsed pass/fail summary with failure messages) but does not mention potential side effects like Gradle build artifacts, network access, or whether it modifies project state. The description adds some value but leaves the safety profile implied.
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 sentence, front-loads the action, and includes the key return detail. No wasted words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with fully documented parameters, the description is sufficient. It explains the primary behavior and return value. It lacks explicit reference to Gradle session defaults or relationship to sibling tools, but those are not critical for basic usage.
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 all four parameters are already clearly explained in the schema. The description does not add any parameter-specific details 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 tool runs local JVM unit tests, specifies the Gradle task pattern (test<Variant>UnitTest), and notes the parsed pass/fail summary with failure messages. This is a specific verb+resource+scope, and it implicitly distinguishes from sibling test_instrumented by emphasizing 'local JVM'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for local JVM unit tests, implying it is not for instrumented tests. However, it does not explicitly mention alternatives or exclusions, such as 'use test_instrumented for device tests'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds valuable behavior: it polls until the element appears and explicitly states it returns coordinates (rather than performing a tap). It does not contradict the annotation, though it could detail failure behavior on timeout, but the schema's timeoutSeconds description already hints at giving up.
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 extremely concise—one sentence that front-loads the key action ('Poll the UI') and follows with the matching criteria and return value. Every word earns its place, with no wasted repetition of the tool's name.
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 tool with 3 parameters, no output schema, and a read-only annotation, the description adequately covers the core purpose and return value. It does not explicitly describe what happens if the element never appears (timeout behavior), but the schema's timeoutSeconds description covers the 'give up' aspect, making this a minor gap rather than a major omission.
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 each parameter is documented. The main description repeats the match semantics found in the schema ('text / content-desc / resource-id') but does not add meaning beyond the schema for serial or timeoutSeconds. This aligns with the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls the UI until a matching element appears, specifying the match criteria (text/content-desc/resource-id) and the return value (tap coordinates). This distinguishes it from sibling tools like tap_element or snapshot_ui, which perform immediate actions or capture state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—use when you need to wait for an element to appear—but it does not explicitly state when to use this tool over alternatives or mention any exclusions. For example, it does not say 'use this before tapping an element that may not be ready' nor reference related tools like tap or tap_element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description doesn't need to repeat safety. It adds the behavioral detail that the tool reports running status in addition to listing AVDs, which is useful context beyond the annotation. However, it doesn't disclose output format or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the purpose with a clear verb and object. No unnecessary words or repetition.
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?
For a no-parameter, read-only listing tool, the description fully captures the core functionality and adds the running-status distinction. There is no output schema, but the output is predictable from the description, making it 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?
With zero parameters, the baseline is 4 per the rubric. The description adds meaning by specifying what is listed (available AVDs and running status), which is the relevant context for the tool's behavior with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available Android Virtual Devices and indicates which are running. It uses a specific verb ('List') and resource ('AVDs'), effectively distinguishing it from sibling tools like create_avd or delete_avd.
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 gives clear context on what the tool does (lists AVDs and running state), implying when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety; the description adds no additional behavioral traits beyond coordinate guidance. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and the second sentence adds a useful tip without redundancy.
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?
All six parameters are documented in the schema, the description covers coordinate alternatives, and no output schema is needed for a simple gesture. The tool is fully specified for its complexity.
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 documents all parameters with full descriptions, and the description adds practical context for when to use percentage coordinates over pixel coordinates. This elevates the baseline.
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 'Long-press' plus resource 'screen' and coordinates, clearly distinguishing it from siblings like tap, swipe, and drag. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear advice on coordinate format (percentages vs pixels) with a rationale, but does not explicitly state when to choose this over alternative gestures. The usage is implied rather than contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently explains the effect (clean status bar) and that it can be disabled, which is good. However, it does not mention persistence, side effects, or any requirements, which would add more depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the main action and includes explanatory details. Every word is meaningful, and there is no redundancy.
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?
For a simple toggle tool with a fully described schema and no output schema, the description is complete. It explains the purpose, the effect, and the reverse action, making it sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all three parameters, including defaults and examples (100% coverage). The description adds no new parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables or disables a clean status bar for screenshots, with specific details (fixed clock, full battery, full signal). This is a clear verb+resource statement, but it does not explicitly distinguish from siblings like 'set_appearance', so it misses the top score.
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 phrase 'for screenshots' provides clear context on when to use this tool. However, it does not mention when not to use it or alternatives, so it falls short of explicit exclusion/alternative guidance.
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 burden. It discloses the primary mutation (creating an AVD) and the fallback behavior of listing installed images when systemImage is omitted. It does not note prerequisites, error conditions, or side effects, leaving some behavioral gaps typical of a create 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 two sentences long, front-loaded with the core action, and every word adds value. The example and fallback note are placed efficiently without any 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 the moderate complexity (3 parameters, no output schema, no annotations), the description covers the main purpose, an example, and a key fallback path. It does not explain return values or the full interaction flow when systemImage is omitted, but this is not critical for a create operation.
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%, but the description adds value beyond the schema: it provides a concrete example for systemImage ('system-images;android-35;google_apis;arm64-v8a') and explains the special behavior when systemImage is omitted, enhancing the schema's basic property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb+resource ('Create an AVD') and provides a concrete example of the system image format. This distinguishes it from sibling tools like list_avds, boot_emulator, and delete_avd.
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 clearly explains that systemImage can be omitted to list available images, giving practical usage guidance. However, it does not explicitly mention when to use this tool versus related tools like list_avds or boot_emulator, so it lacks explicit 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?
The readOnlyHint annotation declares this as a safe read operation, and the description adds the exact behavior of looking for directories with settings.gradle[.kts]. It doesn't contradict the annotation and provides useful context about the search criterion and downstream usage.
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 exactly two sentences: the first defines the tool's purpose precisely, and the second gives actionable guidance. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only discovery tool with two parameters and no output schema, the description conveys the search mechanism, the criterion, and a practical use case. It doesn't describe the return format, but the guidance is sufficient for an agent to invoke 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 input schema has 100% description coverage for both searchPath and maxDepth, so the baseline is 3. The description adds little parameter-specific detail beyond what the schema already provides, though it reinforces the path-based nature of the search.
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 'Find' and the resource 'Android/Gradle projects' with a precise identifying criterion: directories containing settings.gradle[.kts]. It distinguishes itself from sibling tools like build_app or list_modules by focusing on project discovery.
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 explicitly tells the agent to use the result with session_set_defaults projectDir, providing a concrete use case. It doesn't mention when not to use it or alternatives, but among the siblings there is no other discovery tool, so the guidance is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns by noting 'without building', adding the context that this is a non-mutating lookup. It also specifies 'most recent', providing useful behavioral detail beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys everything needed with no redundancy. Every word 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 read-only path lookup, the description covers the key intent. It does not explicitly state the return format, but the tool name and schema make that implicit. No output schema exists, so the description is sufficient for the tool's simplicity.
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 parameters are already well-documented. The description mentions module/variant generically but does not add new meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Locate'), a specific resource ('most recent built APK'), and the scope ('for a module/variant'). It also distinguishes itself from build_app by explicitly noting 'without building', so an agent can tell this is not a build trigger.
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 phrase 'without building' implies usage when an APK already exists and you need its path. However, it does not explicitly name alternatives like 'build_app' or state when NOT to use it, leaving some room for interpretation.
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 transparency burden. It discloses that it runs a Gradle task and requires a plugin, but does not mention potential side effects like running tests or heavy build time. The 'skipRun' parameter is in the schema, not the description, and the description does not explain what the summary looks like or failure modes.
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?
Three concise sentences that front-load the main purpose, then add customization and prerequisites. Every sentence earns its place with no redundant phrasing. Ideal size for the information conveyed.
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 tool with no annotations and no output schema, the description covers the core workflow (run, summarize), default behavior, customizability, and prerequisites. It does not detail return format or error handling, but the core use case is adequately complete. Sibling differentiation is partially handled, so not a 5.
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% with individual parameter descriptions, so the baseline is 3. The description adds value by explaining the default task behavior, giving a concrete example (jacocoTestReport), and stating the plugin prerequisite—context not present in the schema. This elevates it above baseline.
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 action ('Run a coverage Gradle task') and resource ('summarize line coverage per package'), distinguishing it from sibling 'get_file_coverage' which is file-level. The verb-resource pair is unambiguous and not tautological.
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?
Provides clear context on default behavior (koverXmlReport<Variant>) and how to customize via 'task', plus a prerequisite (coverage plugin). Does not explicitly name alternatives or exclusions, but the context strongly implies when to use this tool vs file-level coverage. Lacks explicit 'when not to use' guidance, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds a behavioral dependency: the tool relies on a prior get_coverage_report run to have data. This is meaningful context beyond the annotation, though error behavior for missing reports is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and resource, with no redundant wording. It is concise and structured effectively.
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 (one required parameter, three optional) and the description covers purpose, prerequisite, and output. No output schema is present, but the description states what is shown. Minor gap: it does not mention what happens if the coverage report is absent, but for a read-only tool this is acceptable.
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 baseline is 3. The description adds no parameter-specific detail, but the schema already fully documents 'file', 'module', and 'projectDir' with examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and resource ('covered/uncovered line numbers of one source file'), clearly stating what the tool does. It also distinguishes from the sibling get_coverage_report by referencing the 'latest coverage report' as the data source.
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 explicitly states a prerequisite: 'run get_coverage_report first', which conveys when to use the tool. It does not explicitly name alternatives or exclusion criteria, but the prerequisite provides sufficient contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description adds that this is a one-shot (not continuous) operation and that app filtering requires the app to be running. This is useful context beyond the safety hint, though it doesn't detail output limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, with no wasted words.
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 read-only log dump with four optional, well-documented parameters and no output schema, the description conveys the essential behavior and constraints. It doesn't mention return format or default line count, but the schema covers defaults.
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?
Input schema has 100% coverage for all four parameters, so the description doesn't need to explain each. It adds only generic filtering context and the 'must be running' constraint, which is largely already in the appId schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'dump' with resource 'recent logcat lines' and optional filters. It clearly distinguishes from sibling tools like start_log_capture (continuous capture) and get_crash_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States one-shot nature and filtering by app (must be running) and/or tag, giving clear context for use. It does not explicitly name alternatives or when-not-to-use, so not a 5.
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 provide readOnlyHint, so the safety profile is partially covered. The description adds that keys are pressed in order, but doesn't disclose any details about failure, timing, or side effects on the device, which would be useful for a tool that sends input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and scope. Every word contributes, 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?
For a simple tool with 2 parameters, no output schema, and a complete schema, the description is adequate. The reference to key_press provides essential context for key naming, so the agent can use it correctly. No major gaps for the expected usage.
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 already documents both parameters at 100% coverage, so the baseline is 3. The description adds value by pointing to key_press for key names, which helps the agent understand the expected string values.
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 states exactly what the tool does: 'Press several keys in order'. This clearly distinguishes it from sibling tool key_press which likely presses a single key, and references 'same names as key_press' to clarify key naming.
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 the name and action, and the reference to key_press gives a convention for key names. However, it doesn't explicitly mention when to use this over alternatives, though the 'several keys in order' clearly indicates its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the underlying mechanism (adb screenrecord), the 3-minute limit, and that it returns a recordingId for the stop tool. It omits failure conditions or file handling, but for a simple start operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear verb and resource, immediately stating what it does and the key constraint. It also includes the critical return value and pairing information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paired start/stop recording tool, the description provides the essential context: what is recorded, the method, the time cap, and the returned ID. Since there is no output schema, the description appropriately covers the return value. Minor gaps like error behavior are acceptable at this complexity level.
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 are already fully documented in the input schema (100% coverage), including serial semantics and timeLimitSeconds maximum/default. The description only reinforces the time limit via 'max 3 minutes,' adding no new parameter-level detail.
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 'Start recording the device screen' with the specific method 'adb screenrecord' and a time cap. It clearly identifies the resource (device screen) and action, and the pairing with record_video_stop distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the companion tool record_video_stop, indicating this is the start of a paired workflow. It does not list exclusions or alternatives, but the context is clear since no other sibling tool initiates screen recording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds behavior context by specifying that it reads from wrapper properties and the version catalog, implying a non-invasive file read rather than a Gradle execution. This is useful beyond the annotation.
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 conveys all essential information without fluff. Every word contributes to the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the core functionality. It could mention the output format, but that is a minor omission given the tool's low 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 for the single parameter 'projectDir' is 100%, and the schema description already explains its default behavior. The tool description adds no additional parameter-level meaning, 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 uses a specific verb ('Show') and clearly identifies the resource ('toolchain versions') with further detail on sources (Gradle from wrapper properties, version catalog). This distinguishes it from sibling tools like 'get_app_info' or 'list_modules', which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when you need toolchain versions), but it does not explicitly mention alternatives or exclusion scenarios. Given the tool's unique role among siblings, this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it computes a safe swipe in the middle of the screen, avoiding status bar and navigation areas. This goes beyond the annotation without contradicting it. Slight credit for the safety detail, though no additional side effects are disclosed beyond what the read-only hint implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and key behavior, second gives usage preference. No filler words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is complete: it covers what the tool does, the safe-swipe behavior, and when to use it. No output schema exists, but for a screen-action tool, return values are not critical. A small gap is that it doesn't explicitly mention the default amount or that direction is required, but these are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (direction enum semantics, amount range, serial default). The description does not add parameter-specific meaning beyond the schema, so baseline 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 states a specific verb and resource: 'Scroll the screen in a direction.' It also distinguishes from the sibling tool 'swipe' by explicitly recommending this tool over raw swipe for scrolling. This clearly differentiates its purpose.
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 provides usage guidance: 'Prefer this over raw swipe for scrolling.' This names an alternative tool and specifies when to choose this tool, satisfying the highest bar for this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds behavioral context by clarifying the gesture's typical uses (scrolling, dismissing) and the percentage-based coordinate option, which implies a practical workaround for screenshots. This is meaningful value beyond the annotation, though it doesn't go into deeper side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by a sibling exclusion and a concise tips. Every sentence earns its place with no redundancy. This is exemplary brevity and structure.
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 10 parameters and no output schema, the description is quite compact but covers the essential context: purpose, key alternative, and a practical note on coordinates. The schema fully documents parameters, and annotations handle safety. The description does not mention duration or serial, but these are self-explanatory in the schema. It is slightly less complete than a tool with more behavioral caveats, but adequate for a gesture 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the rationale for using percentage parameters ('safer when estimating positions from a screenshot image'), which is not present in the schema's parameter descriptions. This enriches the parameter's purpose beyond the literal field 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 function: 'Swipe from one point to another (scrolling, dismissing).' It uses a specific verb and resource, and explicitly distinguishes from the sibling tool 'drag' via 'For drag-and-drop use drag instead.' This makes the purpose unambiguous and differentiates it from at least one closely related sibling.
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 an explicit alternative ('For drag-and-drop use drag instead') and adds practical usage guidance for screen percentages ('safer when estimating positions from a screenshot image'). However, it does not mention how swipe relates to the 'scroll' sibling, which might be a closer alternative for scrolling actions. This is a minor gap, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds value by specifying the returned fields (serial, state, model, etc.), which is useful behavioral context. No contradictions or hidden side effects are implied.
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 the action and resource, and every word contributes valuable information. No fluff or redundancy.
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?
For a simple list tool with no parameters and no output schema, the description is complete: it states what is listed and which attributes are included. It doesn't need to explain return values or side effects given the readOnlyHint annotation.
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 coverage is 100%, so the schema fully documents the input. The description adds no parameter information, but none is needed; the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'connected devices and emulators' and enumerates the output fields (serial, state, model, Android version, API level). This clearly distinguishes it from sibling tools like list_avds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when you need to see connected devices/emulators). It does not explicitly mention alternatives or exclusions, but the context is unambiguous for this simple listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by disclosing that the tool executes './gradlew <module>:tasks' to inspect assemble tasks. This is a meaningful behavioral detail—it indicates a background Gradle invocation—while remaining consistent with read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It clearly states the primary action and the mechanism, with no wasted words or redundancy. Every element earns its place.
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?
For a simple listing tool with complete parameter schema, readOnlyHint annotation, and no output schema, the description sufficiently explains the tool's function and method. The return value (a list of variants) is implied by the verb 'List', and no additional behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides (module name and project root). It references 'module' but does not expand on its meaning or defaults.
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 lists build variants of a module, using a specific verb ('List') and resource ('build variants of a module'). It also explains the method (inspecting Gradle assemble tasks), which distinguishes it from sibling tools like 'list_modules' that list modules, not variants.
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 context: use this tool to list build variants of a Gradle module. It does not explicitly name alternatives or exclusion criteria, but the context is unambiguous given the tool's purpose and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint:true, so the safety profile is covered. The description adds the dependency on the Google android CLI for annotate mode and clarifies that the result is returned as an image. It also adds context about the annotate feature's coverage (text in images/WebViews), which is beyond the schema description. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place. The first sentence states the core function; the second explains the optional annotate behavior and notes the sibling comparison. No redundant wording or fluff.
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?
For a simple screenshot tool with readOnlyHint and no output schema, the description covers the primary action, return format, optional parameter behavior, a prerequisite, and a sibling differentiation. Given the tool's simplicity and the sibling context, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both serial and annotate. The description adds meaning to annotate by explaining the numbered bounding boxes and the limitation that the Google android CLI is required. It also highlights the advantage over snapshot_ui, which enriches parameter understanding 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?
The description uses a specific verb ('Take') and resource ('device/emulator screen'), and states the output ('return it as an image'). It clearly differentiates from siblings by mentioning the annotate feature's ability to see text inside images/WebViews that snapshot_ui cannot.
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 comparative guidance by noting that annotate:true can see text inside images/WebViews that snapshot_ui cannot, implying when this tool is preferable. It also mentions the prerequisite of the Google android CLI for annotate. However, it does not explicitly state when to avoid this tool or how it compares to other alternatives like snapshot_ui beyond this one capability.
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 readOnlyHint=true annotation, the safety profile is already known. The description adds context by enumerating the environment components being inspected, giving the agent a clear expectation of what the tool examines beyond just 'check'. No contradictory behavior is described.
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 concise sentences. The first sentence front-loads the verb and resource list, and the second provides a critical usage tip. Every word earns its place; no redundancy.
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?
For a simple no-parameter diagnostic tool, the description fully covers what it checks and when to invoke it. No output schema exists, but the description doesn't need to explain return values since the purpose is clear and the tool is self-contained.
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 (schema coverage 100% and property count 0), so per the rubric the baseline is 4. The description appropriately stays silent on parameters since 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 checks the Android development environment, listing specific components (SDK location, adb, emulator, avdmanager, Java, connected devices). The verb 'Check' and resource list make the purpose unambiguous and distinguish it from sibling tools that perform build, test, or device interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Run this first if any other tool fails with a missing-binary error.' This tells the agent the exact scenario for using the tool and establishes it as a diagnostic first step, effectively differentiating it from alternatives.
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:

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

Score Badge

Copy to your README.md:

[![androidbuild-mcp MCP server](https://glama.ai/mcp/servers/dev-jackson/androidbuild-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dev-jackson/androidbuild-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/dev-jackson/androidbuild-mcp'

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