Android Studio MCP

by MauricePutinas

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear names and descriptions, but the large number (73) introduces some potential for confusion, especially among similar ADB and logcat tools. Overall, an agent can differentiate them.
Naming Consistency5/5
All tools follow a consistent as_<category>_<verb> pattern (e.g., as_adb_devices, as_gradle_assemble). The naming is predictable and well-structured throughout the entire set.
Tool Count2/5
73 tools is excessive for most use cases. While the server covers many sub-domains, this number is far above the typical well-scoped range (3-15), making it difficult to navigate and manage.
Completeness4/5
The tool set is very comprehensive, covering IDE control, ADB, Gradle, AVD, SDK, project management, and diagnostics. Minor gaps exist (e.g., limited ADB shell commands), but overall it addresses the Android development domain thoroughly.
Average 4/5 across 73 of 73 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a write operation ('record' and 'pull'), but annotations set readOnlyHint=true, creating a contradiction. No mention of permissions or side effects beyond the contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, front-loaded, and includes an Args and Returns section. However, the Args section is redundant as the schema defines parameters. Still, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the contradiction and lack of usage guidance, the description is incomplete. It does not explain why readOnlyHint is set when recording is not read-only, nor addresses potential side effects or required device state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context. The description lists parameter names (out_path, seconds, serial) but adds no semantic detail beyond what the schema provides (e.g., that seconds is recording length). Does not compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records the device screen to an .mp4 and pulls it to this PC. This distinguishes it from siblings like as_adb_screenshot (still image) and as_adb_logcat (logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., as_adb_screenshot for images) or any prerequisites or limitations (e.g., only works on devices with recording support).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive. The description adds that backups are timestamped and stored in a server backup dir, but does not disclose potential side effects (e.g., disk space usage) or behavior on existing files.
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 with two sentences plus a structured Args/Returns section. No unnecessary 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?
The description covers the basic purpose and return type, but omits usage context, error cases, and relationships to sibling tools. Adequate for a simple tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only repeats the parameter name 'path' without adding meaning beyond the schema's description. Given schema description coverage is 0% (presumably for the top-level params), the description should provide more context but fails to do so.
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 it creates a timestamped backup of a single file in the server backup directory. However, it does not differentiate from the sibling tool `as_project_backup`, which likely backs up a project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusion criteria. The description simply states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=false, destructiveHint=false, and openWorldHint=true, indicating a non-read-only, non-destructive, externally visible operation. The description adds that the return is a JSON string with install result, but does not disclose side effects (e.g., device state changes) beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the core action, listing parameters, and stating return format. It is front-loaded and avoids unnecessary detail. Slight improvement could be achieved by removing the 'Args' repetition, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, an output schema exists, and annotations cover behavioral hints, the description is reasonably complete. It states the action, parameters, and return type. Missing error handling or side effects, but not critical for this straightforward install 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 description lists parameters (apk_path, serial, reinstall, allow_downgrade, grant_permissions) but the schema already provides detailed descriptions for each sub-property. With high schema coverage, the description adds marginal value. It does not clarify parameter syntax or relationships.
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 'Install an APK onto a device/emulator,' specifying the verb and resource. It is distinct from sibling tools like as_aab_install (which installs AAB) and as_adb_uninstall, though it does not explicitly differentiate them. The name itself clarifies the target.
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 as_aab_install or as_adb_uninstall. It lacks prerequisites, context, or scenarios for use. Users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description repeats 'clear' but adds no new behavioral traits (e.g., 'discards all buffered logs'). The return type is mentioned, but overall transparency is adequate without being exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point. It includes an args/returns section that could be considered redundant given the schema, but it remains efficient without unnecessary details.
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 destructive tool with annotations and schema, the description is mostly complete. It mentions the adb command and return type. It lacks explicit mention of irreversibility, but annotations cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add parameter semantics. However, it only restates the schema: 'params (SerialInput): serial.' No additional context or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear the device log buffer (adb logcat -c).' The verb 'clear' and resource 'device log buffer' are specific. It distinguishes from siblings like 'as_adb_logcat' (reading) and watch tools (continuous monitoring).
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 (e.g., before starting a new log capture). There is no mention of exclusions or prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'detached' mode and optional wait-boot, which are behavioral details beyond annotations. However, it does not cover side effects like starting an AVD that may already be running, or resource consumption. Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden but only partially addresses it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded. However, the second paragraph ('Args:', 'Returns:') redundantly repeats information already available in the input schema and output schema, adding unnecessary length without new value.
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 description covers the basic behavior but lacks details on error cases (e.g., AVD not found, port conflicts) and timeout behavior. It does mention the return format (JSON with pid/serial), which adds completeness. Overall, it is minimally sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely lists parameter names without adding semantics beyond what the input schema already provides (schema descriptions are detailed). Since schema coverage is 0% (description adds no new information), it falls short of compensating, though the schema itself is comprehensive.
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: 'Boot an AVD in the emulator (detached) and optionally wait for boot.' It uses a specific verb and resource, and the behavior (detached mode, optional wait) distinguishes it from sibling tools like as_avd_list or as_avd_stop.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or restrictions. It only describes what the tool does, not the context of its usage.
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?
Annotations indicate destructiveHint false and readOnlyHint false, but the description adds little beyond stating the action. It does not disclose potential side effects (e.g., interfering with app state), whether the command blocks until completion, or if it requires focus on the target app. The return value is mentioned but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sections: purpose, arguments, and returns. It uses clear formatting and avoids redundancy. Every sentence serves a purpose, though the Args section could be more structured (e.g., bullet points).
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 presence of a detailed schema and an output schema, the description covers the essential aspects: purpose, input types, and return format. It is complete enough for a tool with a single parameter object, but lacks behavioral details like error cases or serial selection logic, which are partly 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?
The description includes an Args section listing the three fields (kind, value, serial) with brief explanations, adding some meaning beyond the schema. However, schema description coverage is 0%, meaning the description should compensate more. Since the schema already provides detailed descriptions for each parameter, the description's contribution is minimal but acceptable, earning a baseline 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 sends tap/swipe/text/keyevent to the device for UI automation. The verb 'Send' and list of input types provide a specific purpose, and the tool name 'as_adb_input' differentiates it from sibling tools like 'as_adb_shell' or 'as_ui_send_keys', as it focuses on ADB input simulation.
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 'as_ui_send_keys' or 'as_adb_shell'. It does not specify prerequisites (e.g., device must be awake) or circumstances where it is inappropriate (e.g., for background UI elements). No explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=false and readOnlyHint=false. The description adds that the tool returns JSON with status and outputs, and implies it produces bundle files. However, it does not disclose potential side effects like overwriting existing files or required environment setup (e.g., gradlew). The behavioral info is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose in the first sentence. It uses a structured Args/Returns format. The placeholder 'bundle<Variant>' is slightly unclear, but overall it is efficient with 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?
Given the presence of an output schema (not shown), the description does not need to detail return fields beyond mentioning JSON with status and outputs. However, it omits to mention that project_dir must contain gradlew, which is only in the schema. For a build tool, additional context like required command (Gradle) would improve completeness.
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 full descriptions for all parameters. The description lists the parameters (project_dir, variant, module, timeout) but does not add meaning beyond what the schema already provides. With 0% description coverage in the context signal, the description is redundant, 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 explicitly states 'Build an Android App Bundle (.aab)', which is a specific verb and resource format. It distinguishes from sibling tools like as_gradle_assemble (likely builds APK) by specifying the output type. The name also aligns with building bundles.
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 like as_gradle_assemble for APK builds or as_aab_build_apks. No exclusions or prerequisites are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it returns JSON with final process info and can stop 'any managed process'. This provides some context beyond annotations, but the behavioral impact of stopping (e.g., process termination, inability to resume) is not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose, parameter usage, and return value. It is front-loaded with the primary action and contains 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 tool with one parameter and an output schema (implied), the description adequately covers the return value and parameter. However, it could mention that the watch must exist or that stopping an already stopped watch is idempotent (consistent with idempotentHint). This is a minor gap.
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 describes the proc_id parameter ('Process id from as_proc_list / a watch id.') with 100% coverage. The description redundantly restates 'proc_id (the watch_id)' but adds no new meaning. Therefore, the description adds minimal value over the schema.
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 ('Stop') and the resource ('a running logcat watch (or any managed process)'). It distinguishes from siblings like as_logcat_watch_start and as_logcat_watch_read. However, it could be more precise about which managed processes it can stop (e.g., those started by as_logcat_watch_start or as_proc_list).
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 explicit guidance on when to use this tool versus alternatives (e.g., as_proc_stop for stopping arbitrary processes). It does not mention prerequisites (e.g., the watch must be started first) or scenarios where this tool should not be used.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the process is 'stopped' and returns final info, but does not elaborate on side effects (e.g., data loss, termination behavior). With annotations covering the core behavioral traits, the description adds minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an Args line. All content is relevant and front-loaded. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema present), the description is mostly complete: it states what the tool does, the input, and the return type. However, it lacks details about error handling or behavior when the process does not exist, which could be important for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the parameter `proc_id` but provides no additional meaning beyond what is already in the input schema's `description` field. Since schema coverage is 0% (description does not cover parameters), the description should compensate, but it merely references the schema type without adding value.
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 resource ('managed background process'), and the identifier ('by id'). It distinguishes from sibling `as_proc_list` which lists processes.
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 stop a process. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or cautionary notes. The destructive hint suggests care is needed, but the description lacks 'when-not-to-use' advice.
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?
Annotations already indicate the tool is not read-only and open world. The description adds minimal behavioral context beyond the mechanism ('via monkey launcher intent') and does not disclose side effects, error cases, or state changes.
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 efficient: three lines with a clear purpose statement, args summary, and return type. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple launch tool, the description covers input and return format adequately. However, it lacks details on error handling, behavior when app is already running, or prerequisites (e.g., device availability).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining the two methods (component vs package) and the default launcher behavior, which complements the schema's property descriptions. Schema descriptions cover the fields well, so the description provides extra context on usage.
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 'Launch an app by component or by package (via monkey launcher intent)' with a specific verb and resource, clearly distinguishing it from siblings like as_adb_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-to-avoid guidance is provided. Alternatives such as as_run_app are not mentioned, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return type (JSON indicating success) and the main effect (focusing the window). Annotations add idempotentHint=true, indicating safe repeated calls. However, it does not describe edge cases (e.g., what happens if no window exists) or potential side effects beyond focusing.
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: one for purpose, one for return type. It is concise with no redundant information. Every sentence serves a clear function.
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 parameters and an existing output schema, the description is nearly complete. It covers the main purpose and return value. Minor gaps include missing prerequisites (e.g., IDE must be running) and error behavior, but these are partly addressed by the output schema.
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 no parameters, and the input schema is empty (coverage 100%). The description does not need to add parameter-level information. Baseline score of 4 applies as no additional documentation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: bring the Android Studio window to the foreground. It specifies the resource ('Android Studio window') and the verb ('bring to foreground'), making the purpose obvious. However, it does not differentiate from sibling tools like as_ui_screenshot or as_ui_invoke_action, but as_ui_focus is unique in its focus function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., IDE must be running) or scenarios (e.g., after launching IDE or when interacting with UI). Sibling tools exist for similar UI interactions, but no context is given for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's non-destructive nature is clear. The description adds 'copy' without detailing behavioral nuances beyond the return format.
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 with a single sentence describing the action, followed by a clear args/returns section. No extraneous information is included.
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?
While output schema exists, the description lacks mention of error conditions or workspace path constraints. However, for a simple file transfer tool with annotations covering safety, it is mostly 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 0%, but the input schema itself provides detailed descriptions for each parameter (serial, local, remote). The description merely lists the parameters without adding extra meaning, meeting 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 explicitly states 'Copy a file from the device to this PC (adb pull)', providing a clear action and direction. It distinguishes from siblings like as_adb_push by specifying the transfer direction.
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 does not provide any guidance on when to use this tool versus alternatives, such as as_adb_push or as_adb_shell. It also omits prerequisites like device connection or serial requirements, relying solely on the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it returns a JSON comparison table, but lacks details on permissions, error handling, or additional behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading purpose and return type. No wasted words, but could be slightly more structured with clearer separation of purpose and usage.
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 straightforward comparison tool, the description is adequate but lacks detail on the comparison table contents, performance, or edge cases. Given schema and annotations, it's minimally 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 description mentions apk_a (baseline) and apk_b, but the schema already provides similar descriptions. Schema descriptions are thorough, so the description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares file sizes of two APKs, with specific verb and resource. It distinguishes from siblings like as_apk_info (single APK info) or as_apk_filesize (single APK size).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given. The purpose implies comparison use, but no guidance on when to choose this over other APK tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, effectively describing it as a safe read operation. The description adds the return format (JSON with verified bool and cert details) but does not comment on permissions or limitations like network access or file existence.
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: two lines for purpose, one line for args, one line for return. It is front-loaded and wastes no words. Every sentence is necessary.
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 provided (but context indicates it exists), the description adequately covers the return format and purpose. It could mention that it uses apksigner or that the APK must exist locally, but overall it is sufficient.
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 description merely restates the parameter name apk_path, which is already documented in the input schema with a description. Since schema_description_coverage is 0% per context (though actual schema has a description), the description adds no extra meaning. 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 the tool verifies an APK's signature and prints signing certificates. The verb 'verify' and resource 'APK signature' are specific. It distinguishes from sibling tools like as_apk_info or as_apk_filesize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, contraindications, or scenarios where other tools would be preferred. Agents have to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) provide basic safety info. The description adds value by stating that the tool produces .apk paths under build/outputs and returns JSON with gradle status, command, and outputs. However, it does not disclose potential side effects like modifying build directories or requiring specific SDK/Android versions.
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 approximately 6 sentences, front-loads the core purpose, and includes structured Args/Returns sections. Every sentence contributes meaningfully without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, what it produces, and the return format, which is adequate for a build tool with an output schema. It lacks explicit mention of prerequisites (e.g., gradlew.bat existence) or error handling, but overall it provides sufficient context for correct 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?
The input schema already provides descriptions for each parameter. The tool description reiterates these, adding concrete examples like 'Debug'/'Release' for variant and ':app' for module. This adds minimal value beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build APK(s) with assemble<Variant>' and equates to Android Studio's 'Build > Build APK(s)', making the tool's purpose unambiguous. However, it does not explicitly differentiate from siblings like as_gradle_bundle or as_gradle_test, so it falls short of a 5.
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 for building APKs by referencing the Android Studio action, but provides no explicit guidance on when to use this tool versus alternatives (e.g., as_gradle_bundle for AABs). No exclusions or context for choosing this specific gradle tool are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes HTML/XML test reports under build directories and returns JSON with gradle status and parsed failures. Annotations already indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description adds meaningful side-effect and output context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sections: one for purpose and one for parameters/returns. Every sentence adds value with no redundant or filler content.
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 complexity (nested parameters with four fields) and the presence of an output schema (not shown but declared), the description adequately covers purpose, parameters, and return format. It mentions report file paths and return structure, though it could note device requirements for instrumented tests more directly.
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 four sub-properties (project_dir, timeout, instrumented, module). The tool description reiterates these but does not add significant new meaning, so it meets the baseline for high schema coverage.
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 runs unit tests (default) or instrumented connected tests. The verb 'run' and resource 'Gradle tests' are specific, but it does not explicitly differentiate from sibling tools like as_gradle_assemble or as_gradle_run_task, though the context implies a testing focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when-not to use it or suggest other tools for different Gradle tasks, leaving the agent without context for choosing this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false; description adds only minimal return format info but no extra behavioral traits, not contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded action, efficient; minor redundancy from function signature format but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and return format; annotations present; adequate for a simple screenshot tool despite low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (low), but description only lists parameter names and types, failing to add meaningful context beyond schema properties which already have 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?
Clearly states 'Capture a screenshot of the Android Studio window (or full screen)' with specific verb and resource, distinguishing it from sibling as_adb_screenshot (device screenshot) through context.
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?
Implies usage for IDE/desktop screenshot but lacks explicit when-to-use, when-not-to-use, or alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints; description adds bundletool context and return type. Does not disclose side effects like file overwriting or download requirements (confirm param hints but not elaborated).
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 plus a bullet list and return type. Front-loaded and no extraneous info.
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?
Adequate for a simple conversion tool with good schema coverage, but lacks behavioral details like output format structure or prerequisites beyond what schema indicates.
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 already cover parameters well (high schema coverage). Description only lists parameter names, adding minimal value 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 converts an .aab to .apks, naming the underlying tool (bundletool). It distinguishes from siblings like as_aab_install.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives. Implied usage but lacks context like prerequisites (e.g., having an .aab file) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds value by specifying the output format (JSON with file_size and download_size), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a docstring-style breakdown of args and returns. It is front-loaded with the purpose. Could be slightly more concise, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (implied), the description is complete enough. It explains what it measures and the return format. The annotations cover safety and idempotency.
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 description repeats the parameter name (params) and its type (ApkInput) but adds no meaning beyond what the input schema provides (the schema already has a description for apk_path). With 0% schema description coverage for the top-level parameter, the description could have compensated but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reports on-disk and estimated download sizes of an APK. It uses a specific verb ("report") and resource (APK sizes), distinguishing it from sibling tools like as_apk_info (general info) or as_apk_compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like as_apk_info or as_apk_compare. The description simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds that it uses a specific command and returns JSON with command and PID, providing some behavioral context. However, it does not elaborate on side effects or detailed behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated first, then the command, and finally the return type. It is front-loaded and efficient, though slightly technical with the command line syntax.
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 diff tool with an output schema, the description sufficiently covers the return type (JSON with command and PID) and the basic operation. It is complete given the tool's straightforward nature and the presence of other structured metadata.
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 'left' and 'right' parameters with descriptions. The description merely mentions 'left and right paths', adding no new semantic value. With schema coverage effectively providing parameter info, a 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 opens the IDE's visual diff viewer for two files or directories, using a specific verb and resource. It distinguishes from sibling tools like as_apk_compare which focuses on APK comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives, nor does it specify prerequisites or limitations. The usage is implied but not fully delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description simply states 'Copy a file' without disclosing behavioral traits like overwrite behavior, permissions required, or error cases. Annotations provide minimal help (destructiveHint=false), so the description carries the burden but adds little.
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 very concise—three lines including the docstring—with no wasted words. It front-loads the main action and includes return type information efficiently.
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 sufficiently complete for a simple file transfer tool, mentioning parameters and return type. However, it could be more complete by noting that `adb push` overwrites existing files on the device, but given the output schema exists and the tool is straightforward, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage (context signal), the description includes a docstring that clarifies parameter purposes: 'local (workspace path), remote (device path), serial'. This adds meaning beyond the input schema by specifying the path types.
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 ('Copy a file from this PC to the device') and resource ('file'), and it distinguishes itself from the sibling `as_adb_pull` which does the reverse operation.
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 for transferring files to a device but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives beyond the name.
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, destructiveHint, and idempotentHint, so the safety profile is clear. The description adds that it returns JSON with reference method count and per-package breakdown, which is not in annotations, thus providing additional behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The docstring-style Args/Returns adds structured clarity, though the Returns line is redundant given the output schema. Every part is justified except minor duplication.
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 reporting tool with one parameter and an output schema, the description covers input, output format, and tool action. It lacks details on what 'largest packages' means or edge cases, but overall it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0%, the description only restates 'apk_path' without adding meaning beyond the schema's 'Path to an .apk file'. No additional parameter context, validation rules, or examples are provided, leaving the agent with no extra comprehension.
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 reports dex method counts and the largest packages using apkanalyzer dex. This verb+resource combination is specific and distinguishes it from sibling APK tools like as_apk_filesize or as_apk_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when method counts are needed but provides no explicit guidance on when to use this tool versus alternatives like as_apk_info or as_apk_compare. An agent would rely on the tool name and purpose inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that it uses 'adb emu kill' and returns JSON output, but does not elaborate on side effects (e.g., behavior if emulator already stopped) or safety beyond annotations. It adds some context but not substantial.
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: two short sentences plus bulleted Args/Returns. Every sentence provides necessary information without redundancy, making it efficient for an agent to parse.
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, annotations, and an output schema, the description covers purpose, parameter, and return type. It lacks explicit mention of behavior when no emulator is running or confirmation of idempotency, but these are partially covered by annotations. Overall, it is sufficiently complete for its 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 a detailed description for the 'serial' parameter, including format and default behavior. The tool description merely restates 'optional serial (else the first running emulator)' without adding new semantic meaning. With high schema coverage, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stop' and the resource 'running emulator', with the parenthetical '(adb emu kill)' providing implementation detail. It distinguishes from sibling tools like as_avd_start, as_avd_list, and as_avd_delete, which have different actions.
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 for stopping an emulator and mentions optional serial filtering, but does not explicitly state when to use this tool vs. alternatives (e.g., as_avd_delete for removal). No exclusions or when-not-to-use guidance is 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe, idempotent operation. The description adds that the tool returns a JSON string in command.stdout, which is consistent and slightly more specific, but does not disclose additional behavioral traits.
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, using a single sentence to state the purpose and a compact list for parameters and return value. Every part contributes meaningfully 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 tool with 4 parameters and an existing output schema, the description covers the essential action, parameters, and return format. It is nearly complete; however, the output schema is not explicitly detailed, but the description mentions the return is a JSON string.
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?
Despite 0% schema description coverage, the description lists the parameters (project_dir, module, configuration, timeout) with brief explanations that mostly echo the schema's own descriptions. It does not add significant new meaning beyond what is 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 'prints the dependency tree for a module', which is a specific action on a specific resource (Gradle dependencies). This distinguishes it from sibling tools like as_gradle_tasks or as_gradle_assemble, which handle different Gradle operations.
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 use for inspecting dependencies but does not provide explicit guidance on when to use this tool versus alternatives, such as as_gradle_lint or as_gradle_signing_report. There is no mention of context or prerequisites.
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 idempotentHint=true and destructiveHint=false, indicating safety. The description adds that it returns JSON status and report paths but doesn't elaborate on behavioral traits like file modifications or Gradle sync requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sections: purpose, then Args/Returns. Every sentence adds value without 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 output schema existence, the description adequately covers return structure (JSON with status and report paths) and report location pattern. Slightly vague on timeout default but otherwise 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 has 0% description coverage according to context, so the description partially compensates by listing the parameter fields (project_dir, timeout) and their types. However, it lacks detail on default values or constraints beyond what 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 'Run Android Lint via Gradle and point to the generated reports,' which is a specific verb-resource pair. It distinguishes from sibling Gradle tools like assemble or test.
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 for running lint and viewing reports but lacks explicit guidance on when to use this tool versus alternatives (e.g., other gradle tools) or when not to use it. No exclusion criteria provided.
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 destructiveHint=false. The description adds that it returns JSON with 'log' and source path, and clarifies it is the server's own log, providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences summarizing the action, followed by clear Args and Returns sections. 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?
Given the tool's simplicity and the presence of annotations and output schema, the description covers the essential aspects: what it does, its parameters, and return format. It could be slightly more complete by hinting at when to use it, but it is largely 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?
The description only mentions 'lines, level (optional)' without adding details beyond the input schema, which already provides full descriptions, defaults, and ranges for these nested parameters. Thus, the description provides no additional value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the tail of the MCP server's own log file. This distinguishes it from sibling tools like as_logs_ide (IDE logs) and as_logcat_* (device logs).
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 information is provided on when to use this tool versus alternatives. There is no mention of preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent, and open-world. The description adds no behavioral traits beyond the action 'install'. It does not mention requirements like a connected device or potential side effects. The confirm parameter's purpose is covered in the schema but not reinforced in the description. This is adequate but minimal for a simple 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 extremely concise: one sentence for the main action, a line for arguments, and a line for return type. All information is front-loaded, and there is no superfluous text. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one top-level parameter (object) and three sub-parameters, all described in the schema. The description covers the overall purpose and return type. An output schema exists, so return value details are already provided. The description is complete for the tool's complexity, though it could mention the confirm flag's role (already in schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0%, meaning the description must compensate. The description only lists parameter names ('apks_path, serial, confirm') without adding any semantic details beyond the schema. It does not explain their purpose, formatting, or constraints, leaving the agent with only the schema descriptions. Given the low coverage, this is insufficient.
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: 'Install a .apks set onto a connected device'. It specifies the verb (install), resource (.apks set), and target (connected device). This distinguishes it from siblings like as_adb_install which installs regular APKs, and references the bundletool command, making the action 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 by stating it installs a .apks set, which differentiates it from APK installation tools like as_adb_install. However, it does not explicitly provide 'when to use' or 'when not to use' guidance, nor does it mention alternatives. The context is clear enough for an agent to select this tool when the input is an .apks set.
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 provide readOnlyHint and destructiveHint. Description adds non-streaming nature and return format (JSON with log and line_count).
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 plus arg/return list; 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?
Tool is simple; missing explicit usage guidance but return format and parameters are covered by schema. Adequate for a snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description only lists parameter names without additional meaning; schema already provides full descriptions. Despite schema coverage in tool description being 0%, schema itself is detailed, but description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it dumps a snapshot of recent device logs (non-streaming). It distinguishes from streaming logcat tools and as_adb_logcat_clear among 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?
No explicit guidance on when to use this vs streaming or clear tools; only implied by 'non-streaming'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds 'Does not delete data', which aligns with destructiveHint=false. However, it does not disclose potential side effects like losing unsaved app data or killing background services, which would add value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and direct: two sentences plus structured args/returns. It is front-loaded with the key purpose. No redundant information, though it could be slightly more structured with a usage note. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (force-stop, one parameter, output schema present), the description covers the essential behavior and return format. It omits aspects like device connection requirements or error handling, but the annotations and schema compensate. For a low-complexity tool, it is reasonably 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?
Although the tool description has 0% param coverage, the input schema provides detailed descriptions for serial, package, and confirm. The description adds 'confirm not required', which clarifies usage beyond the schema. Baseline is 3 due to high schema coverage, and the added hint justifies a 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 explicitly states 'Force-stop an app (am force-stop). Does not delete data.' This clearly identifies the action (force-stop) and the target (app). It distinguishes from siblings like as_adb_start_app and as_adb_uninstall by specifying no data deletion.
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 mentions 'confirm not required' but does not provide explicit when-to-use guidance or alternatives. It implies usage for force-stopping, but lacks context such as prerequisites or comparison to related tools like as_adb_uninstall. Sibling differentiation is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true. The description adds that it uses 'avdmanager' commands and returns JSON with names and optionally detailed info, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with a clear front-loaded purpose and structured Args/Returns sections. It could be slightly tighter but is well-organized.
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 output schema is stated but not shown, the description explains the return format (JSON with names and optional avds list) adequately. It covers the main behavioral aspects for a list 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 schema has 0% description coverage, so the description compensates somewhat by mentioning the 'detailed' parameter and its effect. However, it does not add substantial meaning beyond the schema's own description of the parameter.
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 'List configured Android Virtual Devices' with a specific verb (List) and resource (AVDs), distinguishing it from sibling tools like create, delete, start, stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the detailed parameter but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. Usage is implied but not 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?
Annotations indicate idempotentHint=true, destructiveHint=false. The description adds behavioral context: 'frees memory, clears stuck state' explains benefits, and 'Stop all Gradle daemons' clarifies the effect. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose, a short Args/Returns block, and no unnecessary text. Front-loaded with the tool's core 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?
Given the tool's simplicity, the description covers the main action and benefit. However, it does not detail the output format beyond 'JSON with command output,' and lacks guidance on when to use in relation to other gradle operations. Still mostly complete for this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, so description must compensate. The description only lists parameter names ('project_dir, timeout') without explaining their purpose or format, failing to add meaning beyond the schema's property names.
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 stops all Gradle daemons for the project, specifying the verb 'Stop' and resource 'Gradle daemons'. The parenthetical 'frees memory, clears stuck state' adds context. It distinguishes from other gradle siblings that build, test, or run tasks.
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 scenarios via 'frees memory, clears stuck state' but does not explicitly state when to use this tool vs alternatives or provide exclusions. No direct comparison with other gradle 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 description discloses the return format (JSON with 'log' and source path) beyond the readOnlyHint annotation, and no contradictions are 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 succinct, front-loaded with the main action, and uses clear formatting for args and returns with no wasted words.
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 tail-log tool with strong annotations and an output schema, the description covers the essential behavioral and return information completely.
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 description mentions 'lines' and 'level' with examples, but the input schema already provides complete descriptions. Thus no additional meaning is added, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the tail of Android Studio's idea.log with optional level filtering, distinguishing it from related tools like as_adb_logcat and as_logs_mcp.
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 over alternatives such as as_adb_logcat or as_logs_mcp, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, consistent with creating a backup file. The description adds behavioral details: excludes build artefacts and uses timestamp. However, it does not disclose file location or 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 very brief—one sentence for purpose, args, and returns—with 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 backup tool, the description covers the core functionality and return format. Missing details like output file path convention, but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a nested object with a described project_dir parameter ('Android project root.'), but the overall description adds no semantic value beyond echoing the parameter name. With 0% schema coverage, description should compensate but does not.
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 creates a timestamped .zip backup of a project excluding build artefacts, distinguishing it from sibling tools like as_backup_file (likely for individual files) and as_restore_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; the description implies it's for full project backups but does not compare to as_backup_file or as_restore_backup.
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 indicate readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral context: it generates files, requires 'confirm' to write to disk, and optionally opens in Android Studio. This goes beyond annotations to explain the tool's effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It includes key details on generated files, arguments, and return value without extraneous information. Minor improvement could be restructuring for even quicker scanning.
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 presence of an output schema and detailed input schema, the description covers essential context: the project generation process, required parameters, and return structure. It also mentions the confirmation flag and option to open in Studio, making it 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 input schema already provides detailed descriptions for all parameters, so the description's parameter list adds no new semantics. The description correctly mentions the return format, but parameter documentation is adequately handled by 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 scaffolds a new Android project, specifying generated files and optional opening in Android Studio. The verb 'scaffold' and resource 'Android project' are specific and distinct from sibling tools like as_open_project or as_gradle_assemble.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives like as_open_project or as_project_validate. The context of creating a new project is implied but lacks explicit when-not-to-use 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds the 'without building' context, consistent with annotations. No additional behavioral details beyond what annotations provide.
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 sentences plus Args/Returns. Front-loaded with core action. Every sentence adds value: purpose, source files, data extracted, and return format. No redundant text.
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?
Annotations cover safety, output schema exists (though not shown), description lists returned fields. Lacks error conditions or prerequisites, but for a read-only tool this is adequate. Slight gap in differentiating from sibling as_apk_info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the parameter description is minimal. The description only restates 'project_dir' without adding meaning beyond the schema's own description. Does not compensate for low 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?
Clear verb 'extract metadata' with specific resource 'Android project without building'. Lists concrete data items (modules, applicationId, etc.) and distinguishes from build tools by stating 'without building it'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool reads project metadata without building, implying it's for non-build introspection. No explicit when-not-to-use or alternatives, but the context is clear given sibling tools like as_apk_info and as_gradle_assemble.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context that it reads from Android Studio's config and returns a JSON with recent paths, but does not discuss potential stale data or other behavioral nuances.
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 with a one-line purpose, then an Args section, then a Returns section. No wasted words, front-loaded with the core action.
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?
The tool is simple with one parameter and an output schema available. The description covers the return format and the empty case. It is complete for its 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 describes the 'limit' parameter with min, max, default, and a clear description. The tool description merely repeats the parameter name without adding new information. Given high schema coverage, 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 'List recently opened projects from Android Studio's config', which is a specific verb+resource. Among siblings, no other tool lists recent projects, so it distinguishes well.
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 does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. However, the tool's purpose is clear and self-contained, so usage is implied.
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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true; description complements with return format details ('valid', 'problems', 'checks'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence docstring with Args and Returns sections. No wasted words, front-loaded with purpose.
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?
Simple single-parameter tool with output schema described. Description fully explains what the tool does, inputs, and outputs.
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 already describes 'project_dir' as 'Android project root.' Tool description repeats the param name and type but adds little beyond schema. Schema coverage 0% means tool description doesn't add param 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?
Description clearly states the action ('Check that a project has the expected structure') and the resource ('project'). This is distinct from siblings like as_project_info (status) and as_project_backup (backup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., as_project_info). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and read-write nature. Description adds that it removes app + data, requires confirm, and returns result or confirmation_required, providing useful behavioral context beyond 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?
Extremely concise: two clear sentences plus structured Args/Returns. No redundancy, every part carries 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 destructive tool with good annotations and output schema, description covers core behavior. Could mention error cases or multiple device handling, but 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 descriptions cover each parameter (serial, package, confirm) with detail. Description only lists parameter names without adding new meaning. Baseline 3 is appropriate given 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?
Explicitly states 'Uninstall an application (removes app + data)', clearly specifying the verb and resource. Distinguishes from sibling tools like as_adb_install and as_adb_shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides condition 'Requires confirm=true' but does not elaborate on when to use vs alternatives like adb shell or stop app. No explicit when-not or alternative tool mention.
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 provide readOnlyHint, destructiveHint, idempotentHint. The description adds context: it uses aapt2 badging as the primary method and falls back to apkanalyzer, which informs reliability and behavior beyond what annotations convey.
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 with a front-loaded summary of purpose, followed by technical method and structured Args/Returns. Every sentence adds value; 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?
Given the strong annotations (readOnly, idempotent) and the presence of an output schema, the description covers the core functionality well. It could mention error handling for invalid APKs, but overall is sufficient for a straightforward read 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?
Schema description coverage is 0% per context, but the schema itself includes a description for apk_path. The tool description merely mentions 'apk_path' without additional details. It lists return fields but does not compensate for limited parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes an APK and lists key output fields (package, version, SDK levels, etc.). It distinguishes from sibling tools like as_apk_compare or as_apk_filesize by focusing on manifest metadata extraction.
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 does not explicitly state when to use this tool versus alternatives like as_apk_compare or as_apk_verify_signature. It implies usage for general APK info extraction but lacks exclusions or guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds permanence of deletion and requirement for confirm=true. Also notes return includes confirmation_required, adding behavioral context beyond 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?
Four-line description with Args/Returns structure. No redundant text, front-loaded with core 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?
Covers action, required confirm flag, return type. Output schema exists. Could mention data loss consequence or permissions, but sufficient for a deletion tool with annotations.
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 provides descriptions for both parameters (name and confirm). Description merely lists them without added semantics. With schema coverage high, baseline is 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?
Description clearly states the tool deletes an AVD permanently. Verb-resource pair is unambiguous and distinct from siblings like as_avd_create, as_avd_list, as_avd_start, as_avd_stop.
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?
Description implies use for deletion with required confirm=true, but lacks explicit guidance on when to use vs alternatives or prerequisites. No exclusion criteria provided.
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 provide destructiveHint=true and idempotentHint=true. Description adds that backups are created before formatting and that confirm must be true, providing behavioral context beyond annotations. Does not fully detail error handling or consequences of false confirm.
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?
Description is concise, with a clear one-line summary, followed by essential backup and confirm notes, and structured Args/Returns sections. No wasted words, well 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?
Given the tool's complexity, the description covers key aspects: action, backup behavior, confirm requirement, and return format. Lacks info on error handling or edge cases, but annotations and schema fill some gaps. Nearly complete for a formatting 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?
Schema description coverage from tool text is 0%, but the input schema itself has detailed descriptions for each property (target, mask, recursive, confirm). The description only lists parameter names and emphasizes the confirm requirement, adding minimal extra value. Baseline 3 is appropriate as schema covers details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Reformat files in place using the IDE's formatter', providing a specific verb and resource. It distinguishes from sibling tools like as_inspect_code or as_gradle_lint by focusing on direct file formatting with backups and confirmation requirement.
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?
Explicitly requires confirm=true, giving a prerequisite for use. However, it does not discuss when to use this tool over alternatives or provide exclusion criteria. The context is clear but lacks comparative 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 declare destructiveHint=true and idempotentHint=true. Description adds the scope of deletion ('Only touches the build/ dir.'), which goes beyond annotations. No mention of side effects, but the destructive nature is clear.
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?
Extremely concise: two sentences for purpose plus minimal Args/Returns. Front-loaded with key action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with output schema, description covers purpose, scope, and return type. Could mention prerequisites like gradlew existence but overall sufficient.
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 0% per context signals, but the input schema itself provides descriptions for both parameters. The description merely lists parameter names (project_dir, timeout) without adding new semantics. 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?
Description clearly states 'Delete build outputs via 'gradle clean'. Only touches the build/ dir.' with a specific verb and resource, clearly distinguishing it from sibling gradle tools like as_gradle_assemble or as_gradle_bundle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative suggestions. The scoping comment 'Only touches the build/ dir.' implies safety but doesn't guide the agent on when to choose this over other gradle operations or related tools like as_gradle_stop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it starts a background capture and returns a watch_id, which is useful. However, it does not mention the default behavior of clearing the log buffer (clear_first defaults to true), which is a significant behavioral detail. Annotations do not contradict the description, but this omission reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, one for workflow, one for args, one for returns. It is front-loaded with the core purpose and structured logically, 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?
Given the complexity of starting a background watch, the description adequately explains the workflow and return format (watch_id and offset). It could be more complete by mentioning that the watch runs until explicitly stopped and that serial defaults to the only connected device, but it is sufficient for selecting and invoking the 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 description lists the parameters (serial, filter_spec, clear_first) in a concise 'Args:' line, but the input schema already provides descriptions for these nested properties. The description adds no new format, defaults, or constraints beyond what the schema states, despite low top-level schema description coverage (0%). It marginally compensates by listing them.
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 a background logcat capture you can poll incrementally', clearly specifying the verb (start), resource (logcat capture), and mode (background, poll). This differentiates it from siblings like as_adb_logcat (one-shot) and as_logcat_watch_read/stop (subsequent steps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the workflow: returns a watch_id, then use as_logcat_watch_read to poll and as_logcat_watch_stop to stop. This gives clear context but does not explicitly state when to use this over alternatives like as_adb_logcat, or exclude cases like needing a raw dump.
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 destructiveHint=false. Description adds value by specifying the return format (JSON with process list) and scope (server-specific processes).
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 plus return description; front-loaded and concise. Every sentence is necessary and 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?
Given zero parameters and no output schema, description includes return structure and scope. Adequately complete for a simple listing 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?
No parameters in schema; 100% coverage. Description correctly has no parameter info. Baseline 4 applies per guidelines for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List' and resource 'background processes started by this server', with scope 'all'. Distinguishes from sibling tools like as_proc_stop which stops processes.
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 vs alternatives. For a simple listing tool this is less critical, but still missing explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, destructive, and idempotent hints. Description adds no additional behavioral context beyond basic 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?
Extremely concise: one sentence of purpose followed by structured Args/Returns. 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?
Given annotations and schema, description covers purpose, inputs, and output. Lacks error handling details but adequate for a straightforward 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?
Input schema has well-described properties (mapping_file path, stacktrace text). Description restates them, adding clarity but schema does the heavy lifting.
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 de-obfuscates R8/ProGuard stack traces using a mapping file. It distinguishes from siblings by its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance provided. The description only explains the tool's function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the full sequence: assemble, install, launch, capture logcat, optional screenshot, and crash detection. It adds significant behavioral context beyond annotations (which only indicate readOnlyHint=false, destructiveHint=false). It could mention that install overwrites existing APK, but that is 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 concise: a front-loaded sentence, a brief analogy to Android Studio, and a bullet list of steps and arguments. No redundant information, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (build, install, launch, log capture, screenshot), the description covers the main process, inputs, and output structure (steps, apk path, crash detection). It could mention prerequisites like adb connection, but that is standard for device operations.
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 descriptions for all parameters in RunAppInput, so schema coverage is high. The description only lists the parameter names and adds no additional semantics beyond summarizing the return structure. Thus, it adds marginal value over 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 purpose: 'Build, install and launch an app on a device/emulator, then capture logs.' It identifies the verb and resource, and the 'one-shot equivalent of Android Studio's Run button' distinguishes it from siblings like as_gradle_assemble, as_adb_install, and as_adb_logcat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and positions it as a one-shot run command, but it does not explicitly state when to use it versus alternatives or when not to use it. It lacks explicit exclusions or comparisons 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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds value by disclosing the return value ('JSON with the command output, or confirmation_required'), which is a behavioral trait not captured in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for the main action, then 'Args' and 'Returns' sections. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 presence of annotations and output schema, the description covers the essential behavior. It could elaborate on the 'confirmation_required' case or prerequisites, but it is still fairly complete for the task.
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 descriptions for the nested parameters (confirm, timeout) with constraints. The description merely restates their names without adding new semantics. Schema coverage is high for sub-properties, 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 the action ('Accept') and the resource ('all pending Android SDK licenses'), and includes the equivalent command 'sdkmanager --licenses'. This distinguishes it from all sibling tools, which are unrelated to license acceptance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when there are pending licenses, but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. Sibling tools are unrelated, so no comparisons are needed, but usage context is minimal.
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, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that it returns JSON with raw 'tasks' output and parsed build status, providing useful behavioral context beyond 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 extremely concise: a one-line purpose followed by a structured Args and Returns section. Every sentence is necessary and contributes to understanding. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (listing tasks), the presence of annotations (readOnlyHint, idempotentHint) and an output schema, the description is complete. It specifies the input and output format sufficiently for an agent to invoke it 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 0%, meaning the main description does not describe parameters in detail. The description lists parameters ('project_dir, all_tasks (bool), timeout') but does not add semantics beyond what the schema already provides. 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 'List the Gradle tasks available in a project,' specifying the verb 'List' and the resource 'Gradle tasks.' This differentiates it from sibling tools like as_gradle_run_task (which runs a task) and as_gradle_assemble (which builds).
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 does not provide explicit guidance on when to use this tool versus alternatives. It is implied that it is used for listing tasks, but no context like 'Use this to discover available tasks before running them' or when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context about incremental reading via byte offsets and returning an offset for subsequent calls, which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-sentence purpose followed by Args and Returns sections. No unnecessary text, well-structured.
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 read-only tool with a defined output schema, the description covers the usage pattern (since offset), return structure, and parameter roles. It is complete given 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 provides detailed descriptions for all parameters (watch_id, since_offset, grep). The description only lists them without additional meaning. With schema coverage being effective, a 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 title 'Read new logcat-watch output' and description 'Read new output from a running logcat watch since a byte offset' clearly state the verb (read) and resource (logcat watch output). It is easily distinguished from sibling tools as_logcat_watch_start and as_logcat_watch_stop.
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 does not explicitly state when to use this tool or provide alternatives. However, the name and context of sibling tools imply it is for reading after a watch is started. No direct guidance on prerequisites or exclusion cases.
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 indicate readOnlyHint=true and destructiveHint=false, and the description adds behavioral details: uses specific adb command, saves PNG on PC, requires workspace root and optional serial. No contradictions; additional context beyond 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?
Three sentences: purpose, args (summarized), returns. No fluff, front-loaded, easy to parse. 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?
Covers core functionality, inputs, and output. Does not detail error handling or edge cases (e.g., multiple devices), but for a simple read-only tool with an output schema, it 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 has detailed descriptions for each parameter, but the description adds valuable context: 'inside a workspace root' clarifies file location, and outlines return structure. With 0% schema coverage in the description, it still adds 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 action ('Capture the device screen'), output format ('PNG'), and method ('adb exec-out screencap'). It distinguishes this tool from siblings like as_ui_screenshot or as_adb_shell by specifying it saves to the PC.
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 the basic usage context (input params, return value) but does not explicitly state when to use this tool over alternatives or when not to use it. The readOnlyHint annotation implies safety, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate mutation via readOnlyHint=false), the description reveals that the tool requires a confirm parameter to produce an AVD, and returns a JSON string or 'confirmation_required'. This provides insight into the creation flow. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the purpose, then covering prerequisite, arguments, and return value. No extraneous text. Each sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core creation purpose, prerequisite, parameter list, and return value. It does not mention error handling (e.g., if system image is missing) or what happens on duplicate names, but it is sufficient for a non-complex tool with an output schema. Slightly more detail could improve completeness.
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 description simply lists the parameters from the input schema (name, system_image, device, confirm) without adding additional meaning or constraints. Since the schema itself has detailed descriptions for each parameter, the description adds minimal value beyond enumeration.
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: 'Create a new Android Virtual Device from an installed system image.' It uses a specific verb ('create') and resource ('Android Virtual Device'), and distinguishes from sibling tools like as_avd_list or as_avd_start by focusing on creation.
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 explicit context by mentioning the prerequisite: 'The system image must already be installed (use as_sdk_install with e.g. 'system-images;android-34;google_apis;x86_64').' This guides the user to a related tool. However, it does not specify when not to use this tool or compare to sibling AVD tools like as_avd_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds that secrets are redacted, providing extra transparency beyond 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?
Very concise: two sentences for purpose/usage, plus an Args/Returns section. No unnecessary words, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations and an output schema, the description covers purpose, usage, and output format. Could mention the requirement for a project directory, but it's implied by the required parameter.
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 description simply lists parameter names (project_dir, timeout) but adds no new meaning beyond the schema, which already has descriptions. Baseline 3 is appropriate given schema descriptions 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 shows signing configs and certificate fingerprints (SHA1/SHA256), which is a specific verb+resource. It distinguishes from sibling gradle tools like as_gradle_assemble by focusing on signing info.
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 a clear use case: 'Useful for configuring API keys (Maps, Firebase).' It doesn't explicitly state when not to use or alternatives, but the context is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=true), so the description adds limited behavioral context beyond prerequisites and return value. It could disclose more about error handling or 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 concise, with a clear opening sentence summarizing purpose, followed by usage guidance and parameter/return specifications. 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?
The description covers purpose, prerequisites, and return type, but could elaborate on how arguments should match the target tool's schema. Given the output schema exists, the description is largely complete for a meta-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 description only lists parameter names without adding meaning beyond the schema, which already has detailed descriptions for 'name', 'arguments', and 'timeout'. With 0% schema_description_coverage, the description does not compensate.
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 invokes a tool on the IDE's MCP server for live control, using a specific verb ('Invoke') and resource ('tool on MCP server'). It distinguishes itself from the sibling tool 'as_ide_list_mcp_tools' by directing users to discover tool names first.
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?
Provides explicit guidance to use 'as_ide_list_mcp_tools' first to discover available tools, and mentions prerequisites (official MCP Server plugin, running IDE). This helps the agent decide when and how to use the tool.
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 and idempotentHint=true, so the tool is safe and non-destructive. The description adds detail on return fields, providing transparency beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists return fields. Concise, front-loaded, 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?
With no parameters and annotations covering safety, the description adequately outlines return fields. Lacks explanation of the 'guidance' field but is otherwise complete for a status 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?
No parameters (0), so schema coverage is 100%. Baseline of 4 applies as there is no need for 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 clearly states it reports live-IDE connectivity, listing specific fields like studio_running, builtin_server_up, and mcp plugin status, distinguishing it from siblings like as_status or as_is_running which are more general.
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 use to check IDE connectivity, but does not explicitly state when to use vs alternatives like as_is_running or as_status, nor provides exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: explains two-step process, force loses unsaved work. No contradiction with annotations (destructiveHint=true, readOnlyHint=false). Output schema exists, so return explanation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear first sentence and separate Args/Returns sections. Minor verbosity in Args line, but overall efficient.
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?
Missing prerequisite that Android Studio must be running. With 0% schema coverage on the main param, description should compensate more, but it does provide necessary details for force and confirm. Output schema covers return values.
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?
Description adds value by emphasizing confirm is required, which is not obvious from schema alone. Schema descriptions exist for nested parameters, but top-level param lacks description; description compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it restarts Android Studio by closing then relaunching, distinguishing it from siblings like as_close or as_launch. The verb 'Restart' and resource 'Android Studio' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires confirm=true and mentions force parameter. While it doesn't explicitly list alternatives, the sibling tools make it clear. Could improve by noting when not to use (e.g., for close-only or launch-only).
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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true) are well-provided. The description adds value by noting the 'confirmation_required' return case, which clarifies the need for the confirm parameter and the possibility of a two-step interaction.
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: two sentences plus an args/returns list. Every sentence earns its place, with no wasted words. The structure is front-loaded with the purpose and then parameter details.
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 installing SDK packages, the description plus annotations and return info provide sufficient context. The output schema exists (returns string), and idempotentHint indicates safe retries. Minor gap: no mention of underlying sdkmanager, but not essential.
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 contains detailed descriptions for all sub-parameters (packages with examples, confirm with 'Must be true', timeout with defaults). The main description summarizes these but adds marginal new information. Schema coverage is effectively high despite context signal indicating 0%, so baseline 3 is exceeded.
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 installs one or more Android SDK packages, including downloading and accepting licenses. This verb+resource combination distinguishes it from siblings like as_sdk_list and as_sdk_accept_licenses.
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 for installing SDK packages but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. The usage context is clear from the purpose but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-idempotent behavior, and the description adds that it 'sends real keystrokes' and captures a verification screenshot. This goes beyond annotations by detailing the side effects. It could mention potential UI disruptions, but the added value is substantial.
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, with four sentences covering core action, usage context, parameters, and return value. Every sentence adds value, and the key information is 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?
The description covers purpose, usage, parameters, and output format. It mentions the screenshot for verification. However, it does not explain the 'Focus Android Studio' action in detail or prerequisites like IDE running, leaving minor gaps for a destructive 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 tool's description includes a summary of the `params` structure and highlights that `confirm` must be true. However, the input schema already describes each parameter in detail. With 0% schema description coverage reported, the description does not significantly enhance understanding beyond the schema's own 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 'Focus Android Studio and send a raw SendKeys sequence', providing a specific verb and resource. It distinguishes itself from sibling tools like as_adb_input and as_ui_invoke_action by focusing on keystrokes to the IDE.
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 positions this tool as a 'lower-reliability fallback' and advises to 'prefer the CLI/Gradle/ADB tools', giving clear context on when to use it. However, it does not list explicit scenarios where not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the return format specifics and the underlying adb command, providing helpful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for return format. No wasted words, front-loaded with the core action, and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and that an output schema exists, the description still provides necessary return format details. It fully covers what the tool does and returns, making it complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description does not need to add parameter information, and it correctly omits any param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected devices and emulators, references the adb command, and details the return structure. It distinguishes from sibling adb tools (e.g., install, uninstall, shell) by focusing on listing only.
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?
Although the description implies usage for device discovery before other adb operations, it does not explicitly state when to use this tool vs alternatives or provide any exclusion criteria.
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 indicate destructiveHint=true and readOnlyHint=false. The description adds value by specifying the confirm requirement and the automatic backup of the current destination, providing behavioral context beyond 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 concise and well-structured: a one-sentence summary followed by an Args section and a Returns line. No redundant 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?
The description covers the essential behavioral details (confirm requirement, backup of destination), the return type (JSON string), and the parameters. With output schema and annotations present, the description 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 description lists the three arguments (backup_path, restore_to, confirm) but adds minimal meaning beyond the input schema, which already provides descriptions for each. Schema description coverage is reported as 0%, but the schema itself includes descriptions for the nested RestoreInput properties.
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 'Restore a previously-created backup file to a destination.' It uses a specific verb ('Restore') and resource ('backup file'), and distinguishes itself from sibling tools like as_backup_file and as_project_backup.
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 mentions that 'confirm=true' is required and that the current destination is backed up before overwriting, providing clear context. However, it does not explicitly state when to use this tool over alternatives or list any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by specifying that fetching available packages involves a network call (timeout parameter) and that the return includes 'installed' and 'available' lists with path, version, description, and raw output. This extra context goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with separate Args and Returns sections. Every sentence is meaningful: it states the purpose, parameter effects, and return format without redundancy. The front-loading of the main action ('List installed...') makes it easy to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers all necessary aspects: what it does, how parameters affect behavior, and the structure of the return value. With annotations confirming it is safe and idempotent, no additional behavioral details are required. The presence of an output schema is mentioned but not needed since the description already specifies the return format.
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 provides a description for 'installed_only' but not for 'timeout'. The description adds meaning by indicating that 'timeout' is related to the network operation when fetching available packages. It also briefly explains the effect of 'installed_only'. While the schema already covers some semantics, the description compensates for the missing parameter description and ties the parameters to the tool's behavior.
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: listing installed and optionally available Android SDK packages. The verb 'List' combined with 'installed (and optionally available) Android SDK packages' is specific and unambiguous. Among sibling tools, it is distinct from other list tools (e.g., as_avd_list) because it targets SDK packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of the 'installed_only' parameter (fast vs network fetch) and mentions the timeout parameter, giving context on when to use each mode. However, it does not explicitly state when not to use the tool or provide alternatives, and there is no guidance on prerequisites like having the SDK installed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true. Description adds context that it's a 'power tool' and 'escape hatch', and outlines return format (JSON with status, output, build outputs). Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus args/returns list. Front-loaded with purpose and guidelines. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and return format. Could mention potential duration or error handling, but timeout is in schema. Output schema exists, so return details are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description lists the four parameters (project_dir, tasks, args, timeout) with brief hints. However, schema already provides detailed descriptions and types for each field, so description adds minimal extra meaning.
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 verb 'Run', resource 'Gradle tasks', and scope 'arbitrary with optional extra args'. Distinguishes from sibling dedicated tools like assemble/test/lint/clean.
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?
Explicitly tells when to use (escape hatch for tasks not covered by dedicated tools) and when not to (use dedicated tools when possible). Provides concrete examples like installDebug.
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 discloses the dual fallback mechanism, the instant nature of the preferred method, and the return format. Annotations (idempotentHint=true) are consistent. No contradiction, and the description adds value beyond 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?
Four sentences, each serving a purpose: purpose, behavioral details, args, return. No redundant information. Front-loaded with the key 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?
The description covers the core functionality, fallback behavior, and return value. With a nested input schema and only one parameter, it is largely complete. Minor gap: no explicit mention of prerequisites (e.g., must have Android Studio running, but that is 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?
The schema already provides good descriptions for file, line, and column (100% coverage within the nested object). The description adds no extra meaning for parameters, just confirms their presence. 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 the verb (open), the resource (file), and the context (running Android Studio). It distinguishes from siblings like as_open_project which opens projects. The optional line/column detail adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the preferred method (IDE server) and fallback (studio64.exe), which helps the agent understand the behavior. However, it does not explicitly state when to use this tool versus alternatives like adb push for placing files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms no modification of project files, which aligns with idempotentHint=true and destructiveHint=false annotations. It adds that the IDE is launched or reused, providing useful context beyond 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 concise with three sentences covering purpose, behavior, and return value. It uses a structured Args/Returns format without 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?
Given the tool's simplicity (one required parameter, no nested objects, output schema present), the description covers core aspects: purpose, non-modification, and return type. It lacks mention of error handling or prerequisites like Android Studio being installed, but these are minor omissions.
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?
Even though the schema has a description for project_dir, the context signals indicate 0% schema description coverage, putting the burden on the description. The description states 'project_dir (must exist)', which adds meaning but could be more detailed about format or absolute/relative paths.
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 'Open an existing project directory in Android Studio', specifying a specific verb and resource. It distinguishes itself from siblings like as_project_create (create project) and as_open_file (open file) by focusing on opening an existing project.
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 mentions that the project_dir must exist and that the IDE is launched or reused. It does not explicitly state when not to use this tool or mention alternatives, but the context is clear enough for an agent to infer usage.
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 provide readOnlyHint, destructiveHint, idempotentHint. The description adds valuable context by specifying the return format (JSON string) and contents (resolved paths, allow-list, server URL), which goes beyond 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 extremely concise, front-loading the purpose in the first sentence, followed by a brief return format note. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists (as per context signals), the description fully explains the tool's behavior and return content. No additional details are necessary.
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?
No parameters are defined; baseline score is 4. The description correctly does not attempt to explain missing 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 shows the fully-resolved configuration with specific verb 'Show' and resource 'fully-resolved configuration'. It distinguishes itself well from sibling tools, none of which display configuration.
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 states 'Use this to debug discovery/path issues', providing a clear use case. It lacks explicit when-not or alternative recommendations, but the context is sufficiently clear.
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?
Annotations already provide readOnlyHint, etc. Description adds valuable context: bridges to platform-specific command, requires plugin, returns error message on failure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, purpose first, no wasted words.
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?
Covers plugin requirement, bridge detail, return structure (JSON with available/tools/error). Output schema exists but description explains it well.
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?
Single parameter 'timeout' fully described in input schema (coverage 100%). Description adds no extra meaning beyond naming the parameter.
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 tool lists tools exposed by the IDE's built-in MCP server. Distinguishes from sibling 'as_ide_call_mcp_tool' which calls a tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions required plugin and bridge to studio64.exe. No explicit when-not-to-use but return behavior ('actionable message if unavailable') provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful detail about the return format (JSON with running bool and processes list), which is sufficient.
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?
Description is extremely concise: one sentence for purpose and a clear return type description. No unnecessary words.
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?
Tool has no parameters and an output schema exists. The description adds just enough context (quick check, studio64.exe, return format) to be complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. No need for additional 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?
Description clearly states the verb 'check' and resource 'Android Studio process running status', distinguishing it from sibling tools like as_proc_list which list all processes.
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?
While it doesn't explicitly state when to use or not, its purpose is straightforward and distinct from alternatives, providing clear context for a quick check.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: what data is aggregated, that the report is markdown, and the return format (JSON with markdown and structured data). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four lines, front-loaded with purpose, and uses bullet points for aggregation details. Args/Returns are clearly marked. Minor verbosity in the aggregation list, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and annotations covering safety, the description provides sufficient context. It explains the report content and return type. The output schema existence (per context signal) reduces the need for detailed return description, but a brief note on the JSON structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (params.project_dir) is described in the schema as optional. The tool description adds that it optionally includes project metadata, clarifying its effect. With schema coverage effectively 0% (based on context signal), the description compensates well but could be more explicit about how the report changes with a project_dir.
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 produces a comprehensive markdown health report of the dev environment. It lists specific aggregated components (installation status, SDK packages, devices, AVDs, optional project metadata). The verb 'Produce' and resource 'health report' are specific, and it distinguishes from siblings by its unique focus on environment health.
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 health checking and mentions optional project inclusion, but does not explicitly specify when to use vs alternative tools. Since no sibling performs a similar comprehensive report, the lack of exclusions is acceptable. Clear enough for intended purpose.
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, destructiveHint, and idempotentHint. The description adds behavioral details like the 'deep' parameter controlling speed and scope, and the response format options. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the main purpose upfront, followed by parameter and return value details. It is slightly long but effectively concise, earning its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers all necessary aspects: purpose, when to use, parameters, return structure, and behavioral traits. Annotations and output schema reference complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains both parameters: 'response_format' and 'deep', including their values and effects. It provides clear meaning beyond the schema, which has minimal 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: 'Report the full Android Studio / toolchain environment status.' It specifies what it reports (installed, running, paths, etc.) and distinguishes itself from siblings by advising to use it first before acting.
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 instructs to use this tool first to understand the environment. However, it does not explicitly mention when not to use it or list direct alternatives, though sibling tools imply more specific use cases.
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?
Adds significant detail beyond annotations (destructiveHint=true): explains confirm mechanism, safe/destructive command patterns, and return format (JSON with stdout/stderr or confirmation_required). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with a clear opening sentence. Two short paragraphs cover purpose, safety, and returns. Could be slightly tighter but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (arbitrary shell commands), the description covers behavior, safety, parameters, and return value. With annotations and output schema assumed, it is complete and 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?
Schema covers all params with descriptions (so coverage is high). Description adds value by explaining the safety logic behind the confirm parameter and listing example words. Adds context 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?
Clearly states 'Run a shell command on the device' as verb+resource. Distinguishes from sibling adb-specific tools by being generic, and details safe vs destructive commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when confirm=true is needed, lists safe first-words and dangerous markers. Lacks explicit 'when not to use' but context implies use for arbitrary shell commands, not specific adb operations.
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?
Adds significant context beyond annotations: explains behavior of graceful close vs force-kill, data loss risk, confirmation requirement, and return payload. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with two paragraphs plus Args/Returns. Every sentence is meaningful, no fluff, front-loaded with key behavior.
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?
Covers purpose, usage variations, parameter constraints, and return type. Sufficient for a simple close action tool given output schema exists.
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 force and confirm. The description adds usage context (force loses unsaved work, requires confirm). Baseline 3 increased due to added value.
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 closes Android Studio, distinguishes graceful (default) from force-kill, and differentiates from siblings like as_restart and as_launch.
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 guidance on when to use force vs graceful close and the need for confirmation. Could be improved by explicitly contrasting with alternatives like as_restart.
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?
Goes well beyond annotations by disclosing detached mode, immediate return with PID, server startup delay, and the return format (JSON with pid, already_running, command). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: summary line, behavioral details, then structured Args/Returns sections. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a launch tool with output schema; explains launch behavior, detachment, optional project, and return format. No missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds that project_dir is passed to studio64.exe, explaining how the parameter is used, though could add more specifics about path formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Launch Android Studio (optionally opening a project)' with clear verb and resource, distinguishing it from sibling tools like as_open_project or as_run_app.
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 that the IDE starts detached and returns immediately, but does not explicitly mention when not to use or suggest alternatives among many siblings.
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?
Annotations indicate destructiveHint=true and openWorldHint=true. The description adds context: it drives IDE via UI (Find Action), best-effort, and needs verification. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: summary, mechanism, usage note, and structured args/returns. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter with nested object, output schema present), the description fully explains behavior, requirements, and verification process. It is complete for effective use.
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 fully describes each parameter with detailed descriptions. The description only adds 'Requires confirm=true' which is already in schema as default=false but with description stating it must be true. Minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it invokes IDE actions via Find Action, provides specific examples like 'Sync Project with Gradle Files', and distinguishes itself by recommending dedicated tools where available.
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?
It explicitly requires confirm=true, describes when to use (any IDE command), and advises preferring dedicated tools. It also notes it's a best-effort UI path and to verify with screenshot.
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?
Annotations indicate readOnly, non-destructive, idempotent. The description adds crucial details: launches offline engine, writes XML reports, requires indexing, and potential issues with concurrent IDE usage. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence, followed by necessary implementation details, and structured Args/Returns sections. Every sentence adds value 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?
Given the tool's complexity (headless inspection, indexing, contention), the description covers all important behavioral aspects. The return format is specified as JSON with key fields. Annotations and schema complement each other well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section summarizes parameters (project_dir, scope_dir, profile, max_problems, timeout) with brief explanations. Although the schema already provides detailed descriptions, this summary adds value by grouping them in one place and indicating the nested Input type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs Android Studio's code inspection headlessly and returns problems, specifying the same engine as 'Analyze > Inspect Code'. It effectively distinguishes itself from siblings like as_gradle_lint by naming the specific IDE tool.
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 advises against running while Android Studio is open due to config-dir contention, and notes that indexing can take minutes. It provides clear context for when to use this tool.
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

Android-Studio-MCP-Claude-Code MCP server

Copy to your README.md:

[![Android-Studio-MCP-Claude-Code MCP server](https://glama.ai/mcp/servers/MauricePutinas/Android-Studio-MCP-Claude-Code/badges/card.svg)](https://glama.ai/mcp/servers/MauricePutinas/Android-Studio-MCP-Claude-Code)

Score Badge

Copy to your README.md:

[![Android-Studio-MCP-Claude-Code MCP server](https://glama.ai/mcp/servers/MauricePutinas/Android-Studio-MCP-Claude-Code/badges/score.svg)](https://glama.ai/mcp/servers/MauricePutinas/Android-Studio-MCP-Claude-Code)

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/MauricePutinas/Android-Studio-MCP-Claude-Code'

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