Enhanced ADB MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation2/5
Multiple tools have overlapping or unclear boundaries, causing potential confusion. For example, 'screenshot' and 'capture_screen_for_comparison' both capture screenshots with different metadata purposes, 'clear_text_field' and 'input_text' both handle text input but with different actions, and 'tap' vs 'tap_element' vs 'find_element_by_id/text' create redundancy in UI interaction methods. While descriptions help, the sheer number of similar tools makes disambiguation challenging.
Naming Consistency4/5Tool names follow a mostly consistent snake_case verb_noun pattern (e.g., 'get_device_info', 'install_apk', 'toggle_wifi'), with clear action-oriented naming. There are minor deviations like 'shell_command' (which could be 'execute_shell_command' for full consistency) and some tools use gerunds ('scrolling') while others use base verbs ('tap'), but overall the naming is predictable and readable across the set.
Tool Count1/5With 77 tools, this is an extreme mismatch for an MCP server. The count is excessive and will overwhelm agents, making tool selection difficult and inefficient. While the domain (Android device testing/debugging) is broad, many tools could be consolidated (e.g., multiple screenshot methods, various toggle functions) or handled via parameters in fewer, more general tools.
Completeness5/5The tool surface is exceptionally complete for Android device testing and debugging. It covers comprehensive CRUD/lifecycle operations for apps (install, launch, force stop, uninstall), extensive UI interaction (tap, scroll, input), system controls (reboot, proxy, settings), debugging tools (logs, performance, accessibility), and file operations. There are no obvious gaps; agents can perform end-to-end testing workflows without dead ends.
Average 3/5 across 77 of 77 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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.jsonto 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?
No annotations are provided, so the description carries full burden but offers no behavioral details. It doesn't disclose if this is read-only, destructive, requires permissions, has rate limits, or describes output format (though an output schema exists). The description is too vague to inform agent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it's under-specified rather than efficiently informative, lacking necessary details for a tool with parameters and siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and sibling tools, the description is incomplete. It doesn't clarify the tool's role in the context of other logging tools or provide enough detail for effective use, though the output schema may help with return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. It doesn't explain what 'lines' or 'device_serial' mean, their defaults, or how they affect log retrieval. With 2 undocumented parameters, the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Flutter-specific logs' restates the tool name 'get_flutter_logs' with minimal elaboration, making it tautological. It specifies the resource ('Flutter-specific logs') but lacks a clear verb beyond 'Get' and doesn't differentiate from sibling logging tools like 'get_logcat' or 'get_crash_logs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. It doesn't mention context (e.g., debugging Flutter apps), prerequisites, or comparisons to sibling tools like 'get_logcat' for general logs or 'get_crash_logs' for crashes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails entirely. It doesn't mention if this is a read-only or destructive operation, what permissions or device states are required, potential side effects (e.g., app foregrounding), or error conditions. The description lacks any behavioral context beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Launch a specific activity', which is front-loaded and wastes no words. While this under-specifies the tool's functionality, it scores high on conciseness as every word contributes directly to the core idea without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (likely an Android automation tool with 3 parameters), lack of annotations, 0% schema coverage, and presence of an output schema (which the description doesn't reference), the description is completely inadequate. It fails to explain purpose, usage, behavior, or parameters, leaving the agent with insufficient information to use the tool correctly in context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (package_name, activity_name, device_serial) are documented in the schema. The description adds no information about what these parameters mean, their formats, or examples (e.g., Android package names vs. activity classes). This leaves parameters completely unexplained, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Launch a specific activity' is a tautology that essentially restates the tool name 'launch_activity' without adding meaningful specificity. It doesn't clarify what type of activity (e.g., Android app activity, system component) or distinguish it from sibling tools like 'launch_app' or 'get_current_activity', leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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. There are no mentions of prerequisites, context (e.g., device state), or comparisons to sibling tools such as 'launch_app' or 'get_current_activity', making it misleadingly simplistic for a tool that likely requires specific conditions to function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers no behavioral details. It doesn't specify if this is a read-only operation, what permissions are needed, how logs are formatted, if there are rate limits, or what the output contains. This is inadequate for a tool that retrieves system data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action and resource. There's no wasted text, though this brevity contributes to the lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of crash log retrieval, no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It fails to explain parameter usage, behavioral constraints, or differentiation from similar tools, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the two parameters (package_name and device_serial), such as their purpose, format, or how they filter logs. This leaves parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get crash/exception logs' clearly states the verb ('Get') and resource ('crash/exception logs'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_logcat' or 'get_anr_traces' that also retrieve logs, leaving ambiguity about what specific type of logs this tool targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'get_logcat' or 'get_anr_traces'. There's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints at capturing a screenshot and pixel analysis, but does not disclose behavioral traits such as permissions needed, performance impact, error handling, or what the output contains. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, avoiding unnecessary verbosity. However, it is under-specified rather than efficiently informative, as it lacks essential details about the tool's purpose and usage, which reduces its effectiveness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 3 parameters, no annotations, and an output schema, the description is incomplete. It does not explain the tool's function, parameters, or behavioral context, leaving users to guess based on the name and schema alone. The presence of an output schema does not compensate for the lack of descriptive content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the parameters (x, y, device_serial) or their roles. Without any parameter information in the description, users cannot understand what inputs are required or how they affect the tool's operation, failing to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It mentions capturing a screenshot and analyzing pixels, but does not specify the actual function or output. The name suggests getting colors at a position, but the description fails to articulate this purpose directly, making it vague and reliant on inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning 'actual color extraction' should use image processing on the screenshot, but it does not specify when to use this tool versus alternatives like 'screenshot' or other sibling tools. No explicit context, exclusions, or prerequisites are stated, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'comprehensive' but doesn't disclose what information is returned, format, permissions needed, or potential side effects. For a tool with no annotation coverage, this lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, 0% schema coverage, no output schema, and many sibling tools fetching device data, the description is inadequate. It doesn't clarify scope, output, or differentiation, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't mention the 'device_serial' parameter at all. With one parameter undocumented in both schema and description, the description fails to compensate for the coverage gap, leaving parameter meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get comprehensive device information' states the general purpose (verb+resource) but is vague about what 'comprehensive' entails. It doesn't differentiate from sibling tools like 'get_battery_stats', 'get_cpu_info', or 'get_memory_info' that retrieve specific device information subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools fetching specific device data (e.g., battery, CPU, memory), the description doesn't indicate whether this is a general-purpose tool or how it relates to them, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal critical traits: whether this requires device access, if it's a simulated or physical swipe, what happens on failure, or any side effects. For a tool with 6 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the action. It's front-loaded with the core purpose and wastes no words. However, it's overly terse given the tool's complexity, bordering on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and sibling tools with overlapping functions, the description is incomplete. It doesn't address behavioral context, parameter details, or usage scenarios. While an output schema exists (which might help with return values), the description alone leaves too many gaps for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description adds no parameter semantics beyond implying start and end coordinates. It doesn't explain units (e.g., pixels), the optional duration_ms, or device_serial for multi-device contexts. With low coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swipe from start to end coordinates' clearly states the action (swipe) and the resource (coordinates), making the purpose understandable. However, it doesn't differentiate this tool from similar sibling tools like 'scroll_down', 'scroll_up', or 'long_press', which also involve screen interactions. The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention context like UI testing, app navigation, or how it differs from other touch-based tools in the sibling list. There's no explicit or implied usage context, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets' statistics (implying read-only), but doesn't specify whether this requires special permissions, affects device state, has rate limits, or what format the statistics are returned in. The description is minimal and lacks important behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words. It's front-loaded with the core purpose and contains no unnecessary verbiage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a device monitoring tool with no annotations, no output schema, and undocumented parameters, the description is insufficient. It doesn't explain what statistics are returned, their format, whether this works for all devices, or any limitations. The minimal description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter (device_serial), the description provides no information about parameters. It doesn't mention the optional device_serial parameter at all, leaving the agent to guess when and how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed battery statistics' clearly states the verb ('Get') and resource ('battery statistics'), but it's vague about what constitutes 'detailed' statistics. It doesn't differentiate from potential sibling tools like get_cpu_info or get_memory_info beyond the battery 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/5Does 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. There's no mention of prerequisites, timing considerations, or comparison to other device monitoring tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions the filter_level parameter values without explaining what logcat output is, how it's retrieved, whether it's real-time or historical, or any permissions/limitations. For a tool with 5 parameters and no annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences. The first sentence states the purpose clearly, and the second provides parameter clarification. There's no wasted text, though it could benefit from better front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, but has output schema), the description is incomplete. While the output schema may cover return values, the description lacks context about what logcat is, how the tool behaves, and guidance for parameter use. For a tool in a mobile testing context with many sibling alternatives, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics by explaining the filter_level values (V, D, I, W, E, F). However, with 0% schema description coverage and 5 total parameters, it only covers 1 of 5 parameters. The baseline is 3 since it adds some value beyond the schema but doesn't compensate for the significant coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get logcat output' which clearly indicates the action (get) and resource (logcat output). However, it doesn't distinguish this tool from sibling tools like 'clear_logcat' or 'get_flutter_logs', leaving the specific scope and differentiation unclear. The purpose is understandable but lacks sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With sibling tools like 'clear_logcat', 'get_flutter_logs', and 'get_crash_logs', there's no indication of when this general logcat retrieval is preferred over more specific logging tools. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying a read-only operation), but doesn't specify if it requires device permissions, has side effects (e.g., network scans), rate limits, or error handling. For a tool with zero annotation coverage, this lack of detail is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Get network connectivity information'), which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter), lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or return values, leaving the agent with insufficient information for reliable tool invocation in a context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('device_serial') with 0% description coverage, and the tool description adds no parameter semantics. It doesn't explain what 'device_serial' is (e.g., a unique identifier for targeting a specific device), its format, or when it's required (default is null). With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get network connectivity information' clearly states the tool's purpose with a verb ('Get') and resource ('network connectivity information'), making it understandable. However, it's somewhat vague about what specific information is retrieved (e.g., Wi-Fi status, IP address, signal strength) and doesn't differentiate from sibling tools like 'get_device_info' or 'toggle_wifi', which might overlap in network-related contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., device connectivity), exclusions, or comparisons to sibling tools like 'get_device_info' (which might include network data) or 'toggle_wifi' (which controls network state). This leaves the agent with minimal 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers no details. It doesn't mention whether this requires device permissions, if it overwrites existing apps, potential side effects (e.g., data loss), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks critical context about behavior, parameters, and usage scenarios, making it insufficient for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'apk_path' represents (e.g., local file path, URL) or when 'device_serial' is needed (e.g., for multi-device setups). The description fails to provide meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Install an APK file' clearly states the action (install) and resource (APK file), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'push_file' or 'uninstall_app' that might handle APK files differently, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., device connectivity), when to choose this over other installation methods, or exclusions (e.g., incompatible APK types). This leaves 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Uninstall an app' implies a destructive mutation, but it doesn't disclose critical behavioral traits such as whether this requires specific permissions (e.g., root access), if the action is reversible, potential side effects (e.g., data loss), or error conditions (e.g., app not found). The description is too vague for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Uninstall an app', which is front-loaded and wastes no words. While it may be under-specified, it earns full marks for brevity and clarity within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an uninstall operation (a destructive mutation), lack of annotations, 0% schema coverage, and presence of an output schema (which might help but isn't described), the description is incomplete. It fails to address key aspects like behavioral risks, parameter usage, or context within sibling tools, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'package_name' (what format, where to find it) or 'device_serial' (when to specify it, default behavior). For a tool with 2 parameters and no schema documentation, this is insufficient to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Uninstall an app' clearly states the action (uninstall) and target (app), which is better than a tautology. However, it lacks specificity about what kind of app (e.g., Android app via package name) and doesn't distinguish it from sibling tools like 'clear_app_data' or 'force_stop_app', which also manage apps but perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., needing an installed app), exclusions (e.g., system apps might not be uninstallable), or related tools like 'install_apk' for installation or 'clear_app_data' for data removal without uninstallation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'get' which implies a read operation, but doesn't specify if it requires specific permissions, affects device state, has rate limits, or what the output entails. This leaves significant gaps for a tool that interacts with device performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and a vague purpose, it's minimally adequate for a read operation but lacks details on parameters and behavioral context that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'package_name' and 'device_serial' are undocumented in the schema. The description adds no meaning about these parameters—it doesn't explain what 'package_name' refers to (e.g., Flutter app package) or when 'device_serial' is needed. This fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Flutter rendering performance info' clearly states the action (get) and resource (Flutter rendering performance info), but it's vague about what specific information is retrieved. It doesn't distinguish from sibling tools like 'get_frame_stats' or 'get_gpu_info' which might also provide performance-related data, leaving ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like 'get_frame_stats' and 'get_gpu_info' that might overlap in performance monitoring, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get memory usage information' implies a read-only operation, but it doesn't specify permissions required, rate limits, whether it's real-time or cached data, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse quickly. It's appropriately sized for a simple tool, though this conciseness comes at the cost of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it lacks crucial details like parameter semantics and behavioral context, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage (only titles 'Package Name' and 'Device Serial'), and the description adds no information about these parameters. It doesn't explain what 'package_name' or 'device_serial' mean, their optional nature, or how they affect the memory info retrieved, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get memory usage information' clearly states the verb ('Get') and resource ('memory usage information'), making the purpose understandable. However, it doesn't specify what type of memory (device memory, app memory, etc.) or distinguish it from sibling tools like get_cpu_info or get_device_info, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention whether it's for system-wide memory, app-specific memory, or how it differs from other info-gathering tools in the sibling list, such as get_cpu_info or get_battery_stats, leaving the agent to guess based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't specify if it requires device access, returns structured data, has rate limits, or handles errors. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first clause. The additional context about responsive design adds value without unnecessary elaboration. However, it could be slightly more structured by explicitly mentioning the parameter or output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that retrieves screen specifications, with no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on return values, error handling, dependencies, or how it integrates with other tools, making it insufficient for an agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter ('device_serial') undocumented in the schema. The description adds no information about parameters, such as what 'device_serial' refers to, when it's required, or its format. This fails to compensate for the low schema coverage, leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed screen specifications'), and mentions a use case ('useful for responsive design'). However, it doesn't explicitly differentiate from sibling tools like 'get_device_info' or 'screenshot', which might also provide screen-related data, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 mentions 'useful for responsive design' as a general context, but doesn't specify scenarios, prerequisites, or exclusions compared to other screen-related tools in the sibling list, such as 'get_device_info' or 'change_screen_size'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('pull') which implies a read operation that copies a file, but doesn't mention permissions needed, whether it overwrites local files, error handling, or performance aspects like file size limits. This leaves significant gaps for a tool that interacts with device storage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's appropriately sized for a basic tool description and front-loads the core action. Every word earns its place by conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is minimally complete but lacks important context. It covers the basic 'what' but misses 'how' details like parameter usage, behavioral traits, and differentiation from siblings, making it adequate but with clear gaps for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for three undocumented parameters. The description mentions 'from the device' which hints at the 'device_serial' parameter, but doesn't explain 'remote_path' (what path format, what locations are accessible) or 'local_path' (where files are saved, path requirements). It adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pull a file from the device' clearly states the action (pull) and resource (file), but it's vague about scope and doesn't differentiate from sibling tools like 'pull_recordings' or 'read_file'. It specifies the source as 'the device', which provides some context but lacks detail on what types of files or from where on the device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'pull_recordings' (for recordings), 'read_file' (for reading without pulling), or 'list_files' (for listing). The description implies file retrieval but doesn't specify prerequisites, constraints, or comparison to other file-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions saving PNG files and returning comparison info, but lacks critical behavioral details: whether this requires device access, if it's a blocking operation, error conditions, or what specific metadata is captured. The description is insufficient for a mutation tool (file creation) with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and output. Every word earns its place, and the information is front-loaded with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates files (PNG outputs) and returns comparison data with no output schema and 0% schema description coverage, the description is incomplete. It doesn't explain the return format, error handling, device requirements, or how the comparison metadata is structured. The context signals indicate significant gaps in documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'screenshot with metadata' but doesn't explain what the three parameters (screen_name, output_dir, device_serial) mean or how they affect the capture. No parameter semantics are provided beyond what's in the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures screenshots with metadata for visual comparison, specifying the output format (PNG) and comparison target (Figma designs). It distinguishes from the generic 'screenshot' and 'screenshot_to_file' siblings by emphasizing comparison functionality, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the similar 'screenshot' or 'screenshot_to_file' tools, nor does it mention prerequisites, alternatives, or exclusions. Usage context is implied through the comparison purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it works, what permissions are required, whether it's read-only or has side effects, what happens if the app isn't running, or what the return format looks like. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple checking tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It states the basic purpose but doesn't address parameter usage, return values, behavioral characteristics, or integration with sibling tools. For a tool that likely returns boolean or status information, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions no parameters at all, leaving the 'device_serial' parameter completely undocumented. The description doesn't explain when this parameter is needed, what values it accepts, or what happens when it's omitted (defaults to null).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('Flutter app'), specifying the condition being checked ('currently in foreground'). It doesn't explicitly distinguish from sibling tools, but the purpose is unambiguous within the context of Flutter app testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites, related tools for similar checks, or scenarios where this check is appropriate versus other status-checking tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the effect ('like fresh install') but omits critical details: whether this requires specific permissions (e.g., root access), if it's reversible (likely not), potential side effects (e.g., loss of user data), or rate limits. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Clear all data for an app') and adds a clarifying analogy without redundancy. Every word earns its place, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 2 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (which helps), the description fails to address key aspects like behavioral risks, parameter usage, and differentiation from siblings, leaving gaps for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'an app' but doesn't clarify the 'package_name' parameter (e.g., format like 'com.example.app') or the optional 'device_serial' (e.g., for targeting specific devices in multi-device setups). No parameter details are provided beyond the tool's general purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear all data') and target resource ('for an app'), with a helpful analogy ('like fresh install') that clarifies the effect. However, it doesn't explicitly differentiate from sibling tools like 'uninstall_app' or 'force_stop_app', which would require more specific language about data vs. app removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'uninstall_app' (removes the app entirely) or 'force_stop_app' (stops the app without clearing data). The description lacks context about prerequisites (e.g., app must be installed) or typical use cases (e.g., resetting app state for testing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Force stop' implies a destructive, immediate termination, but the description doesn't clarify permissions needed, whether this affects device stability, what happens to background processes, or typical response behavior. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately scannable. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 2 parameters, 0% schema coverage, no annotations, but with an output schema, the description is incomplete. It states what the tool does but lacks crucial context about parameters, behavioral implications, and usage guidelines. The output schema helps with return values, but the description should do more to compensate for other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description provides no information about the two parameters (package_name and device_serial), their formats, examples, or relationships. It doesn't compensate for the schema gap, leaving the agent to guess parameter meanings from their titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Force stop an app' clearly states the action (force stop) and target (an app), making the purpose immediately understandable. It uses a specific verb that distinguishes it from gentler app management tools. However, it doesn't differentiate from sibling tools like 'clear_app_data' or 'uninstall_app' which also affect apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (like needing the app to be running), consequences (like potentially losing unsaved data), or when other tools like 'clear_app_data' or 'uninstall_app' might be more appropriate. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get') without details on permissions needed, output format, rate limits, or whether it's a read-only operation. This is inadequate for a tool that likely involves accessing system-level data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (likely involves system diagnostics), lack of annotations, and an output schema (which helps), the description is minimally adequate. It states what the tool does but fails to provide context on usage, behavior, or parameters, leaving gaps that the output schema alone cannot fully address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description does not mention any parameters. Since there is only one parameter and the schema lacks descriptions, the baseline is 3, as the description does not add value but also does not mislead given the minimal parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get ANR (Application Not Responding) traces' clearly states the verb ('Get') and resource ('ANR traces'), providing a basic understanding of the tool's function. However, it lacks specificity about what ANR traces are or how they differ from other diagnostic tools like 'get_crash_logs' or 'get_logcat' among the siblings, making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios like debugging app freezes or how it relates to sibling tools such as 'get_crash_logs' or 'get_flutter_logs', leaving the agent 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits such as whether it requires specific permissions, what format the detailed information is returned in, or any potential side effects. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving app information, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on what 'detailed information' includes, how to interpret parameters, or any behavioral context, making it inadequate for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description doesn't mention any parameters or provide meaning beyond the schema, failing to compensate for the coverage gap. It doesn't explain what 'package_name' or 'device_serial' represent or how they should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about an installed app'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_device_info' or 'get_current_activity' that also retrieve information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools that retrieve various types of information (e.g., 'get_device_info', 'get_current_activity'), there's no indication of what makes this tool specific or when it should be preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose success/failure conditions, permissions needed, side effects (e.g., app foregrounding), or error handling, leaving critical operational context unspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for the tool's apparent simplicity, achieving maximum clarity per character without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and a mutation tool with an output schema (unseen), the description is incomplete. It lacks behavioral context, parameter guidance, and fails to address complexity like multi-device handling or error scenarios, leaving the agent under-informed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details beyond the tool name. It mentions 'package_name' implicitly but doesn't explain format or examples, and ignores 'device_serial' entirely, failing to clarify semantics for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch') and target resource ('an app by package name'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'launch_activity' or 'start_screen_record', but it's specific enough to convey core functionality without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'launch_activity' or 'check_flutter_app_running'. The description lacks context about prerequisites (e.g., device connectivity) or exclusions, offering only basic functional intent without situational 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('push') but doesn't disclose critical details like whether it overwrites existing files, requires specific permissions, handles errors, or has side effects (e.g., affecting device storage). This leaves significant gaps for an agent to understand the tool's behavior safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a file transfer operation with 3 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (which might cover return values), the description fails to address key contextual aspects like error conditions, device state requirements, or interaction with sibling tools (e.g., 'pull_file'), leaving the agent with insufficient guidance for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'local_path', 'remote_path', or 'device_serial' mean, their formats, or examples (e.g., absolute vs. relative paths). This leaves all three parameters semantically unclear beyond their titles in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('push') and resource ('a file to the device'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'pull_file' by specifying directionality, though it doesn't explicitly differentiate from other file-related tools like 'list_files' or 'read_file' beyond the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention prerequisites (e.g., device connectivity), constraints (e.g., file size limits), or when to choose other tools like 'install_apk' for APK files or 'shell_command' for advanced transfers. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is for emulation only, which is useful context, but fails to describe what the simulation entails (e.g., does it trigger app behaviors, require specific setups, or have side effects like notifications). For a tool that likely interacts with device state, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, front-loaded sentence that wastes no words. Every part ('simulate incoming call' and 'emulator only') earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a simulation tool with no annotations, 0% schema coverage, and an output schema (which might help but isn't described), the description is incomplete. It lacks details on parameters, behavioral outcomes, error conditions, and how it fits with sibling tools, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention 'phone_number' or 'device_serial' at all, leaving both parameters undocumented. The description adds no meaning beyond the schema, failing to clarify what these inputs represent or how they affect the simulation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('simulate incoming call') and specifies the environment ('emulator only'), which distinguishes it from real device operations. However, it doesn't explicitly differentiate from sibling tools like 'send_sms' or other communication-related tools, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'emulator only', which provides some context on when to use it (in emulation environments), but offers no guidance on when not to use it (e.g., on real devices) or alternatives for real device testing. There's no mention of prerequisites or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool changes screen density for testing, implying a mutation operation, but doesn't specify whether this requires device permissions, if changes persist across reboots, potential side effects, or what the output contains. For a mutation tool with zero annotation coverage, this is insufficient behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two clauses, front-loading the core purpose ('Change screen density') followed by a brief usage context. Every word earns its place with zero redundant information, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 2 parameters (1 required), 0% schema coverage, no annotations, but with an output schema present, the description provides basic purpose but lacks crucial context about parameter usage, behavioral implications, and relationship to sibling tools. The output schema existence means return values don't need description, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'DPI' which maps to the 'dpi' parameter, but doesn't explain valid ranges, units, or typical values. It completely ignores the 'device_serial' parameter and its optional nature. The description adds minimal value beyond what's inferable from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Change screen density' with the specific verb 'Change' and resource 'screen density', and adds context about being 'useful for testing different DPI'. It distinguishes from sibling tools like 'reset_density' and 'change_screen_size' by focusing specifically on density/DPI changes rather than resetting or changing screen dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'useful for testing different DPI', which implies a testing context but doesn't specify when to use this tool versus alternatives like 'reset_density' or 'change_screen_size'. No explicit when/when-not guidance or prerequisites are mentioned, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions 'sending delete keys,' hinting at a simulated keypress action, but doesn't disclose critical traits like whether it requires UI focus, potential side effects (e.g., cursor movement), or error handling. For a tool with no annotations, this leaves significant gaps in understanding its 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('clear text in current field') and method ('by sending delete keys'). There is no wasted verbiage, making it easy to parse quickly, though it could benefit from more detail given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a UI interaction tool with no annotations and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, and context (e.g., mobile testing environment). While an output schema exists (not provided here), the description doesn't address key aspects like success/failure states or integration with sibling tools, making it inadequate for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain 'length' (number of delete keystrokes) or 'device_serial' (target device), leaving these entirely undocumented. However, with only 2 parameters and default values provided in the schema, the baseline is 3, as the description doesn't actively mislead but fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('clear text') and target ('current field'), specifying the method ('by sending delete keys'). It distinguishes from siblings like 'clear_app_data' or 'clear_logcat' by focusing on UI text fields. However, it doesn't explicitly mention the UI context (e.g., mobile app testing), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'input_text' (which might overwrite text) or manual deletion. The description implies usage for clearing text in a focused field, but lacks explicit context about prerequisites (e.g., needing a field selected) 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('double tap') but lacks details on effects (e.g., whether it triggers UI events, requires specific app states, or has side effects), permissions, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Double tap at coordinates') with no wasted words, making it front-loaded and easy to parse. It efficiently conveys the core action in a single phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with 3 parameters, 0% schema coverage, no annotations, but an output schema), the description is insufficient. It lacks details on behavior, parameter meanings, usage context, and expected outcomes, making it incomplete for effective agent use despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It implies coordinates (x, y) but doesn't explain units, coordinate system, or the optional 'device_serial' parameter. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Double tap at coordinates' clearly states the action (double tap) and target (coordinates), which is specific and unambiguous. It distinguishes from siblings like 'tap' (single tap) and 'long_press', though it doesn't explicitly mention this differentiation. The purpose is not tautological with the name 'double_tap'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'tap' or 'long_press', nor does it mention any prerequisites, context, or exclusions. It merely states what the tool does without indicating appropriate scenarios or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get CPU usage information' implies a read-only operation but doesn't specify whether it requires device access, returns real-time or historical data, has rate limits, or what format the output takes. This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and poor parameter documentation, it lacks context about device dependencies or behavioral constraints, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (device_serial) with 0% schema description coverage, and the description adds no information about parameters. It doesn't explain what device_serial is, when it's required, or how it affects the CPU info retrieval, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get CPU usage information' clearly states the verb ('Get') and resource ('CPU usage information'), making the purpose immediately understandable. It distinguishes itself from sibling tools like get_memory_info or get_gpu_info by specifying CPU usage, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_device_info or get_frame_stats, nor does it mention any prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves stats but doesn't disclose behavioral traits such as whether it requires app to be running, permissions needed, rate limits, or what the output format entails. The mention of 'detecting jank' adds some context but is insufficient for a mutation-free read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and adds a brief utility note. There is no wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 2 parameters with 0% schema coverage, and an output schema present, the description is minimally adequate. It states the tool's purpose but lacks details on parameters, behavioral context, and usage guidelines. The output schema may cover return values, but the description doesn't provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'package_name' or 'device_serial' mean, their formats, or how they affect the stats retrieval. With 2 parameters and no schema descriptions, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'frame rendering stats for an app', specifying it's for detecting jank. It distinguishes from siblings by focusing on performance metrics rather than UI elements, logs, or device actions, though it doesn't explicitly contrast with tools like get_flutter_performance_overlay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_flutter_performance_overlay or get_cpu_info for performance analysis. The description mentions it's 'useful for detecting jank', which implies a context but doesn't specify prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'duration' but lacks details on permissions, side effects (e.g., app responses), error handling, or device interaction specifics. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action and key parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the basic action but lacks behavioral context, parameter details, and usage guidance, though the output schema may mitigate some gaps in return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'coordinates' and 'duration', hinting at 'x', 'y', and 'duration_ms', but doesn't explain units (e.g., pixels for coordinates, milliseconds for duration) or the optional 'device_serial' parameter. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('long press') and target ('at coordinates'), specifying the verb and resource. It distinguishes from siblings like 'tap' or 'double_tap' by mentioning duration, but doesn't explicitly differentiate from similar tools like 'swipe' or 'tap_element' in the sibling 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/5Does 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 'tap', 'double_tap', or 'swipe' is provided. The description implies usage for touch interactions requiring sustained pressure, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Press the back button' implies a UI interaction that may affect app state or navigation, but it doesn't describe what happens (e.g., navigates to previous screen, closes dialogs), whether it requires specific device states, or potential side effects. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and target. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter) and the presence of an output schema (which means return values are documented elsewhere), the description could be adequate. However, with no annotations and 0% schema description coverage, the description fails to provide essential context about behavior, usage, or parameter meaning. It's incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has only one parameter (device_serial), and schema description coverage is 0%, meaning the schema provides no description of this parameter. The description doesn't mention parameters at all, which is acceptable for a tool with zero parameters but problematic here. However, since there's only one parameter and its purpose (identifying target device) is somewhat inferable from context, the description gets a baseline 4 rather than lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press the back button' clearly states the action (press) and target (back button), which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like press_home, press_recent_apps, or press_key, which all perform similar 'press' actions on different targets. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. There's no mention of context (e.g., navigating back in an app vs. using other navigation methods), prerequisites, or exclusions. Given the sibling tools include various navigation and interaction methods, this lack of guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions reading a text file but doesn't specify error handling (e.g., if the file doesn't exist), permissions required, or output format details. This leaves significant gaps for an agent to understand how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse quickly. It's front-loaded with the core action and resource, which is ideal for conciseness in tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should cover return values), the description's minimalism is somewhat acceptable. However, for a tool with 2 parameters (one required) and no annotations, it lacks details on error cases, device targeting, or file constraints, leaving the agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain what 'remote_path' or 'device_serial' mean, their expected formats, or how they interact. This lack of semantic context makes parameter usage unclear beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('a text file from the device'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_files' or 'pull_file', which also involve file operations, so it doesn't achieve full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'list_files' or 'pull_file', nor does it mention prerequisites such as device connectivity or file existence. It simply states what it does 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Reboot' implies a potentially disruptive operation, the description doesn't warn about device downtime, data loss risks, or permission requirements. The mode parameter values hint at different reboot behaviors but aren't explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief with just two lines, front-loading the core purpose. However, the second line about mode values feels tacked on without proper integration, slightly disrupting flow. Every word serves a purpose, but more structure could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a potentially destructive operation with 2 parameters and no annotations, the description is inadequate. While an output schema exists, the description doesn't address critical behavioral aspects like disruption level, success indicators, or error conditions. The parameter documentation is incomplete, and there's no safety guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides mode parameter values ('normal', 'bootloader', 'recovery') which add meaningful context beyond the schema's generic string type. However, it doesn't explain what these modes do or mention the device_serial parameter at all, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reboot') and resource ('the device'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other device control tools like 'toggle_wifi' or 'rotate_screen' beyond the specific reboot action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like device connectivity or state requirements. There's no indication of when rebooting is appropriate versus other troubleshooting tools like 'clear_app_data' or 'force_stop_app'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('tap') but doesn't mention what happens after the tap (e.g., UI response, potential app navigation), whether it requires specific device states, or any side effects. This leaves significant behavioral gaps for a UI interaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's function. There's zero wasted language, and it's front-loaded with the essential information. This is an excellent example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and simple parameters, the description is minimally adequate. However, for a UI interaction tool that likely has important behavioral considerations (timing, device state requirements, visual feedback), the description should provide more context about how and when to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'screen coordinates (x, y)' which helps explain the required x and y parameters, but completely ignores the optional 'device_serial' parameter. This leaves one of three parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tap at') and target ('screen coordinates'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'double_tap' or 'tap_element', but it's specific enough to understand the basic 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/5Does 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 'double_tap', 'long_press', 'tap_element', or 'swipe'. It simply states what the tool does without any context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral context. It doesn't disclose permissions needed, whether this requires physical device access, side effects on other connectivity features, confirmation requirements, or error conditions. 'Enable or disable' implies mutation but lacks safety/impact details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple toggle operation and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a device control tool with 2 parameters, 0% schema coverage, no annotations, but with an output schema, the description is insufficient. It doesn't explain parameter usage, device targeting logic, behavioral implications, or error handling. The output schema helps but doesn't compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'enable or disable' which hints at the boolean 'enable' parameter purpose, but doesn't explain the device_serial parameter at all. It adds minimal semantic value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable or disable airplane mode' clearly states the verb (enable/disable) and resource (airplane mode), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like toggle_wifi or toggle_talkback beyond naming the specific feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or contextual constraints. It doesn't mention device selection logic (when device_serial is needed) or relationship to other connectivity tools like toggle_wifi.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Enable or disable' implies a state change operation, but there's no information about permissions required, whether changes persist across reboots, what happens on different Android versions, or error conditions. The description is minimal and doesn't provide meaningful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple toggle operation and front-loads the essential action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a state mutation tool with no annotations, 0% schema description coverage, and multiple similar sibling tools, the description is inadequate. It doesn't explain what high contrast text affects, whether it requires specific Android settings or permissions, what the output contains (though output schema exists), or how it differs from other accessibility toggles. The presence of an output schema helps but doesn't compensate for the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't mention parameters at all. The schema shows 'enable' (boolean) and 'device_serial' (optional string), but the description provides no context about what 'enable' actually does, when device_serial is needed, or how these parameters interact. Baseline is 3 since schema coverage is low but description adds no parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('enable or disable') and resource ('high contrast text'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'toggle_color_inversion' or 'toggle_show_layout_bounds' which are also accessibility toggles, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or context. With multiple toggle tools in the sibling list (color_inversion, show_layout_bounds, show_taps, talkback), there's no indication of when high contrast text is appropriate versus other accessibility features.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Enable or disable WiFi' implies a system-level mutation operation, but it doesn't disclose permission requirements, whether changes are reversible, potential side effects, or interaction with other connectivity tools. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just three words, front-loading the core functionality with zero wasted text. Every word earns its place in communicating the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a system mutation tool with no annotations, 2 parameters, and an output schema (which helps), the description is insufficient. It should address behavioral aspects like permissions, side effects, or relationship to other connectivity controls, given the tool's potential impact on device state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, while the schema has 2 parameters with 0% description coverage. However, the parameter names ('enable' and 'device_serial') are self-explanatory enough that the baseline score of 3 is appropriate, as the description doesn't need to compensate heavily for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable or disable WiFi' clearly states the tool's function with a specific verb ('enable or disable') and resource ('WiFi'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'toggle_airplane_mode' or 'toggle_talkback' beyond the WiFi 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/5Does 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, prerequisites, or contextual constraints. It lacks any mention of when this operation is appropriate or how it relates to other device control tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'change' implies a mutation, the description doesn't specify whether this requires specific permissions, if changes are reversible, what happens on different devices, or any rate limits. It mentions testing use but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two phrases that directly address purpose and use case. Every word earns its place with zero redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and moderate complexity (3 parameters with 2 required), the description provides basic purpose and context but lacks important details about behavioral implications, parameter usage, and differentiation from sibling tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'screen resolution' which implies width and height parameters, but doesn't explain the optional 'device_serial' parameter or provide any format/unit details. It adds minimal value beyond what the schema titles suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('change') and resource ('screen resolution'), and provides a use case ('useful for testing different screen sizes'). However, it doesn't explicitly differentiate from the sibling tool 'reset_screen_size', which appears to be a related 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a general use case ('testing different screen sizes') but provides no guidance on when to use this tool versus alternatives like 'reset_screen_size' or 'get_screen_specs'. There are no explicit when/when-not instructions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'Returns element details including tap coordinates,' which adds some behavioral context beyond the basic purpose. However, it lacks critical details: whether this requires specific permissions (e.g., accessibility services), if it's read-only or has side effects, error handling, or performance characteristics. The disclosure is minimal for a tool interacting with UI elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, and the second adds key behavioral information. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (finding UI elements on a device), the description is somewhat complete but has gaps. An output schema exists, so return values don't need explanation. However, with no annotations and low schema coverage, the description should do more to cover behavioral aspects like permissions, side effects, and error cases. It's adequate but not fully comprehensive for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics: it implies 'resource_id' is used to identify the UI element, but doesn't explain what a resource ID is, its format, or how to obtain it. It doesn't mention 'device_serial' at all. With low coverage, the description partially compensates but leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find a UI element by its resource ID.' It specifies the verb ('Find') and resource ('UI element'), and distinguishes it from sibling tools like 'find_element_by_text' by mentioning the search method ('by its resource ID'). However, it doesn't explicitly differentiate from other element-finding tools beyond naming the method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention when to prefer resource ID over text-based search (e.g., 'find_element_by_text'), nor does it discuss prerequisites like needing a running app or device connection. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the tool 'Returns element details including tap coordinates,' which adds some context about output behavior. However, it doesn't disclose critical traits like whether this requires UI automation permissions, if it works only on visible screens, potential performance implications, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that each add value. The first sentence states the core purpose, and the second adds important behavioral context about return values. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain returns in detail. However, for a UI interaction tool with 3 parameters, 0% schema coverage, and no annotations, the description should provide more context about when and how to use it effectively. The mention of 'tap coordinates' is helpful but insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters explicitly, though it implies the 'text' parameter through 'containing specific text.' It doesn't explain 'partial_match' or 'device_serial' at all. With 3 parameters and 0% schema coverage, the description adds minimal value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find UI elements containing specific text' specifies the verb (find) and resource (UI elements) with a key constraint (containing specific text). It distinguishes from siblings like 'find_element_by_id' by specifying text-based search, but doesn't explicitly contrast with 'get_all_text_on_screen' or 'scroll_to_text'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention when to prefer this over 'find_element_by_id', 'get_clickable_elements', or 'get_all_text_on_screen', nor does it specify prerequisites like needing an active UI session or device connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't reveal important behavioral traits: whether this is a read-only operation, what permissions are needed, what format the information returns, or potential side effects. The description is functional but lacks transparency about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 words, front-loading the core purpose and following with a brief usage context. Every word earns its place with no redundancy or unnecessary elaboration. The structure efficiently communicates essential information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which should document return values), the description's minimal approach is somewhat acceptable. However, for a tool with no annotations and undocumented parameters, the description should provide more context about what accessibility information is retrieved, how it's structured, and typical use cases beyond just 'a11y testing'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the single parameter 'device_serial' is undocumented in the schema. The description provides no information about this parameter - it doesn't explain what device_serial is, when to use it, or what happens when it's null. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('accessibility service information'), and the 'a11y testing' context adds useful specificity. However, it doesn't explicitly distinguish this from sibling tools like 'toggle_talkback' or 'toggle_high_contrast' which also relate to accessibility features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'useful for a11y testing', which suggests when this tool might be appropriate. However, it doesn't offer explicit guidance on when to use this versus alternatives like 'get_device_info' or 'get_app_info', nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves elements 'on screen' and includes coordinates, but fails to describe critical behaviors: whether it requires device connectivity, how it handles no elements, if it's read-only or has side effects, performance implications, or error conditions. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: two short sentences that directly state the tool's function and a high-level use case. Every word earns its place, with no redundancy or fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (interacting with device UI), no annotations, and an output schema (which likely handles return values), the description is incomplete. It covers the basic purpose but misses behavioral details, parameter context, and usage nuances. The output schema may help, but the description alone doesn't provide enough for reliable agent operation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no parameter information. Since there's only one parameter and no schema details, the baseline is 4, but the description doesn't compensate by explaining the 'device_serial' parameter's role (e.g., optional device targeting). This results in a score of 3, as the description adds no value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all clickable/interactive elements on screen with their coordinates.' It specifies the verb ('Get'), resource ('clickable/interactive elements'), and key output ('coordinates'). However, it doesn't explicitly differentiate from sibling tools like 'find_element_by_id' or 'get_all_text_on_screen', which reduces the score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance with 'Perfect for understanding what can be tapped,' which implies a context for UI exploration or automation. However, it lacks explicit when-to-use instructions, alternatives (e.g., vs. 'find_element_by_text'), or exclusions. No specific scenarios or prerequisites are mentioned, leaving the agent with vague direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only), but doesn't mention any side effects, permissions needed, rate limits, or what happens if the device_serial is invalid. For a diagnostic tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's diagnostic nature, one parameter, and an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation, it lacks context about behavioral constraints and parameter usage, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It doesn't mention the device_serial parameter at all, leaving its purpose and format undocumented. However, with only one optional parameter, the baseline is higher, but the description adds no value beyond what's implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('GPU rendering information'), and adds a use case ('performance debugging'). However, it doesn't explicitly differentiate from sibling tools like get_cpu_info or get_memory_info, which have similar diagnostic purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general use case ('performance debugging') but offers no explicit guidance on when to use this tool versus alternatives like get_cpu_info or get_frame_stats. There's no mention of prerequisites, exclusions, or specific scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool dumps the UI hierarchy as XML with details on elements, but fails to describe critical behaviors such as performance impact, permissions required, whether it works on locked screens, or error handling. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two sentences that directly state the tool's function and output details without any unnecessary words. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dumping UI hierarchy) and the presence of an output schema, the description is minimally adequate but incomplete. It explains what the tool does but lacks context on usage, behavioral traits, and parameter meaning, which are crucial for effective tool selection and invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('device_serial') with 0% description coverage, and the tool description does not mention any parameters. Since there is only one parameter, the baseline is 4, but the description adds no semantic information about what 'device_serial' means or when to use it, reducing the score to 3 due to the lack of compensatory detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Dump') and resource ('complete UI hierarchy as XML'), explaining it shows visible elements with their properties, bounds, and content descriptions. However, it does not explicitly differentiate from sibling tools like 'get_accessibility_info' or 'get_all_text_on_screen', which might offer overlapping functionality, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 lacks context on prerequisites, such as device connectivity or app state, and does not mention any exclusions or recommended scenarios, leaving the agent to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states what the tool does but doesn't disclose important traits like whether it requires device permissions, what format the output takes, if it's paginated, or potential error conditions. 'List files' implies a read operation, but no safety or performance characteristics are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and only 2 parameters, the description is minimally complete. It states the basic purpose but lacks context about device state requirements, error handling, or output structure beyond what the output schema will provide. For a simple read operation, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description mentions 'in a directory' which hints at the 'remote_path' parameter's purpose, but doesn't explain 'device_serial' or provide any format details. Since there are only 2 parameters and the description gives some context for one, it meets the baseline but doesn't fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List files') and target resource ('in a directory on the device'), making the purpose immediately understandable. However, it doesn't differentiate from potential siblings like 'list_devices' or 'list_packages' that also list things, though those are clearly different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites like device connectivity, nor does it compare with other file-related tools like 'read_file' or 'pull_file' that might be used in similar contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions filtering capability but doesn't disclose important behavioral traits: whether this requires specific permissions, how results are formatted/paginated, if it's a read-only operation, performance characteristics, or what happens when no packages match. The description is minimal and leaves critical operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) and front-loaded with the core purpose. Every word earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is minimally adequate. The existence of an output schema means return values don't need explanation, but the description should provide more context about the tool's behavior, usage scenarios, and parameter meanings to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description doesn't add any parameter-specific information beyond the generic 'optionally filtered' hint. It doesn't explain what 'filter_text' matches, what 'include_system' means, or when 'device_serial' is needed. However, the parameters have clear titles in the schema, providing some baseline understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('installed packages'), and specifies optional filtering. However, it doesn't distinguish this tool from potential sibling package management tools (none exist in the sibling list, but the description doesn't explicitly note this uniqueness).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While there are no obvious package-related siblings, it doesn't mention prerequisites, timing considerations, or relationships with other tools like 'get_app_info' or 'uninstall_app' that might be used in similar contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (press a key) but lacks critical behavioral details: it doesn't specify which device or context this applies to (e.g., Android device control), whether it requires specific permissions, potential side effects, or error handling. The keycode list adds some context but doesn't cover behavioral traits adequately for a tool with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by a useful list of keycodes. Every sentence earns its place, with no redundant information. However, the list formatting could be slightly more structured for readability, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a key-pressing tool with 2 parameters, no annotations, and an output schema), the description is partially complete. It explains the keycode parameter well but lacks context on device targeting (via 'device_serial'), behavioral aspects, and integration with sibling tools. The presence of an output schema means return values don't need explanation, but other gaps remain, making it adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. The schema has 0% description coverage and only lists 'keycode' and 'device_serial' as parameters. The description explains that 'keycode' can be a name or number and provides a comprehensive list of common keycodes with mappings, which clarifies the parameter's expected values and usage. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Press a key by keycode name or number.' It specifies the verb ('press') and resource ('key'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'press_back' or 'press_home', which are more specific versions of this general key-pressing functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention sibling tools like 'press_back' or 'press_home' that handle specific keys, nor does it explain when to use keycodes versus those dedicated tools. Usage context is implied through the keycode list but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'pull' implies data transfer and 'all screen recordings' suggests bulk operation, it doesn't disclose important behaviors: whether this overwrites existing files, requires device connectivity, has timeouts, or handles errors. For a data transfer tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's front-loaded with the main action and follows a logical flow from source to destination. Every word serves a purpose in this compact formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and only 2 parameters, the description provides the minimum viable information about what the tool does. However, for a data transfer operation that could have significant side effects (file system changes, device connectivity requirements), the description lacks completeness regarding behavioral expectations and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'local directory' which corresponds to 'local_dir' parameter, and 'from device' which relates to 'device_serial', adding some semantic meaning. However, it doesn't explain parameter formats, optionality, or the implications of null device_serial. The description provides basic mapping but insufficient detail for confident parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('pull') and target resource ('all screen recordings from device'), making the purpose understandable. It specifies 'to local directory' which adds useful context about the destination. However, it doesn't explicitly differentiate from sibling tools like 'pull_file' or 'screenshot_to_file', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'pull_file' or 'screenshot_to_file'. There's no mention of prerequisites, timing considerations, or when this tool would be preferred over other data retrieval methods. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Save screenshot to a local file' implies a write operation that creates or modifies files, but doesn't specify where files are saved (local to what?), permissions needed, file format constraints, or error conditions. It mentions 'local file' which adds some context about storage location, but lacks details on behavior like overwriting existing files or path resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and relatively simple parameters with defaults, the description is minimally adequate. However, as a file-writing tool with no annotations, it should ideally mention more about file system behavior, permissions, or error handling. The description covers the basic purpose but leaves important behavioral aspects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention either parameter (filename or device_serial), so it adds no semantic value beyond what's inferred from parameter names. With 2 parameters and 0% schema coverage, the description fails to compensate, but since parameters have default values and clear titles, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save screenshot to a local file' clearly states the action (save) and resource (screenshot), making the purpose immediately understandable. However, it doesn't differentiate from the sibling 'screenshot' tool, which appears to be a similar screenshot-related function. The description is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'screenshot' or 'capture_screen_for_comparison'. There's no mention of prerequisites, constraints, or typical use cases. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions scrolling behavior but fails to explain what happens when text isn't found (e.g., error handling), whether scrolling is incremental or continuous, visual feedback during operation, or any performance implications. For a tool with interactive UI effects, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core functionality and appropriately sized for the tool's apparent complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, interactive UI operation) and the presence of an output schema (which should cover return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it leaves significant behavioral and contextual gaps that could hinder effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't mention any parameters. However, with only 3 parameters (one required, two with defaults), the baseline is moderate. The description implies 'text' parameter usage but doesn't clarify 'max_scrolls' behavior or 'device_serial' context, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scroll until text is found') and target ('on screen'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from similar scrolling tools like 'scroll_down' or 'scroll_up', which would require sibling differentiation for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'find_element_by_text' or 'get_all_text_on_screen'. It lacks any context about prerequisites, when-not scenarios, or explicit alternatives, leaving usage decisions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'scroll up' implies a UI interaction, it doesn't specify what 'current screen' means (which app/context), whether scrolling has limits, what happens at the top, or if it requires specific UI elements to be present. Significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality upfront with zero wasted words. It's appropriately sized for a simple scrolling operation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and presence of an output schema (which handles return values), the description is minimally adequate. However, for a UI interaction tool with no annotations, it should provide more context about scrolling behavior, limitations, and when it can be used versus alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameter 'device_serial' is self-explanatory for device targeting. The description doesn't mention this parameter at all, but since there's only one optional parameter with a clear name, the baseline is appropriate. No additional parameter semantics are provided beyond what the schema name implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll up on the current screen' clearly states the action (scroll up) and target (current screen), providing a specific verb+resource combination. However, it doesn't differentiate from its sibling 'scroll_down' beyond the direction, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'scroll_down' or 'scroll_to_text'. The description only states what it does, not when it's appropriate or what prerequisites might exist for scrolling functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Set GPS location' implies a write/mutation operation, the description doesn't address permissions needed, whether changes persist, what happens on physical devices, or error conditions. The emulator note is helpful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words) with zero wasted words. It's front-loaded with the core functionality and includes important qualification about emulator compatibility in parentheses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no annotations, the description is minimal but covers the essential action. The presence of an output schema means return values don't need explanation. However, more context about the mutation's impact and limitations would be valuable given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no parameter information beyond what's in the schema. It doesn't explain what latitude/longitude values are expected, what device_serial does, or provide any usage examples. The baseline is 3 since the schema itself documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Set') and resource ('GPS location'), and adds important context about emulator compatibility. However, it doesn't explicitly differentiate from sibling tools that might also manipulate device settings or location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no prerequisites mentioned, no indication of when this operation is appropriate, and no comparison to other location-related tools (though none appear in the sibling list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool sets a proxy for debugging, implying a configuration change, but doesn't specify whether this requires device permissions, affects other network operations, is persistent across reboots, or has side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in a single sentence with zero wasted words. It front-loads the core purpose ('Set HTTP proxy for the device') followed by a brief usage note ('useful for debugging network requests'). Every element earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (device configuration change), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and hints at usage context but lacks details on parameters, behavioral implications, and alternatives. The presence of an output schema prevents a lower score, but significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It mentions 'HTTP proxy' which relates to 'host' and 'port', but doesn't explain parameter semantics (e.g., host format, port range, optional 'device_serial' for multi-device contexts). With 3 parameters entirely undocumented in schema, the description adds minimal value beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set HTTP proxy') and resource ('for the device'), making the purpose immediately understandable. It distinguishes from sibling tools like 'clear_proxy' by specifying a setting action rather than clearing. However, it doesn't explicitly differentiate from other network-related tools like 'get_network_info' or 'toggle_wifi' beyond the proxy-specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'useful for debugging network requests', suggesting this tool is for diagnostic purposes. However, it lacks explicit guidance on when to use this versus alternatives (e.g., 'clear_proxy' for removing proxy settings) or prerequisites (e.g., device connectivity requirements). The context is helpful but incomplete for optimal agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions reliability as a behavioral trait, which is useful, but lacks details on permissions needed, error handling, what happens if multiple elements match, or interaction effects. For a UI automation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every sentence adds value: the first states the purpose, and the second provides a key behavioral insight. This is an efficient use of language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context: no annotations, 3 parameters with 0% schema coverage, and an output schema exists (so return values needn't be explained), the description is moderately complete. It covers the core purpose and a reliability advantage but misses details on parameters, error cases, and behavioral nuances, making it adequate but with clear gaps for a UI interaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'text or resource ID' which maps to two of the three parameters, but doesn't explain 'device_serial' or provide details on format, constraints, or how parameters interact (e.g., if both text and resource_id are provided). The description adds some meaning but doesn't fully address the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tap on an element') and the targeting method ('by text or resource ID'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'tap' or 'double_tap' beyond mentioning reliability compared to raw coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'More reliable than raw coordinates,' suggesting this tool should be preferred over coordinate-based tapping methods. However, it doesn't explicitly mention when to use this versus alternatives like 'tap' (which might use coordinates) or other interaction tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal whether this requires specific permissions, affects device state persistently, has side effects, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It states what the tool does but lacks behavioral context and usage guidance, making it incomplete for optimal agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, and schema description coverage is 0%, so the schema provides all parameter documentation. The description doesn't add meaning beyond the schema, but with 2 parameters (one required), the baseline is 3 as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and the resource ('display color inversion'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'toggle_high_contrast' or 'toggle_show_layout_bounds' that also toggle display settings, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'toggle_high_contrast' or other display-related tools. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool shows layout bounds for debugging, implying a read-only or diagnostic operation, but doesn't disclose behavioral traits like whether it requires specific permissions (e.g., accessibility services), affects app performance, has side effects (e.g., visual overlays), or how results are returned (though output schema exists). The description adds some context but lacks critical details for a tool that likely interacts with device UI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Show layout bounds for all views - great for debugging layouts'. It's front-loaded with the core purpose and adds a brief context clause. There's no wasted verbiage, making it appropriately concise for a tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (UI debugging with 2 parameters), no annotations, and an output schema (which handles return values), the description is incomplete. It states the purpose but lacks usage guidelines, parameter explanations, and behavioral details (e.g., how it interacts with devices). The output schema mitigates some gaps, but overall, the description doesn't provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters, leaving both 'enable' (boolean) and 'device_serial' (optional string) undocumented in terms of purpose or usage. Since no parameter info is provided in the description, it fails to compensate for the low schema coverage, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show layout bounds for all views - great for debugging layouts'. It specifies the action ('show layout bounds'), target ('all views'), and context ('debugging layouts'), which is more specific than just restating the name. However, it doesn't explicitly differentiate from sibling tools like 'get_ui_hierarchy' or 'get_accessibility_info' that might also help with layout debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions 'great for debugging layouts', which implies a use case but doesn't specify when to use this tool versus alternatives like 'get_ui_hierarchy' for inspecting layout structure or 'screenshot' for visual debugging. No explicit when-not-to-use scenarios or prerequisites (e.g., device connection) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't mention important behavioral traits like whether this requires USB debugging enabled, if it affects device state persistently, what permissions are needed, or potential side effects. 'Enable or disable' implies mutation but lacks safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for this simple toggle operation and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations but with an output schema (which handles return values), the description is minimally adequate. It states the action but lacks important context about device requirements, permissions, and behavioral implications. For a tool that modifies device accessibility settings, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, while the schema has 2 parameters with 0% description coverage. However, the parameters are straightforward (a boolean 'enable' and optional 'device_serial'), and the tool's purpose inherently explains the 'enable' parameter's meaning. The description doesn't add explicit parameter semantics but the tool's simplicity keeps it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and the target resource ('TalkBack accessibility service'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'toggle_color_inversion' or 'toggle_high_contrast' that also toggle accessibility features, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like device connectivity or accessibility permissions. While the context suggests it's for Android device testing, this is implied rather than stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this requires specific permissions, whether it affects system stability, what confirmation (if any) is provided, or what the output contains. 'Clear' implies a destructive operation, but the description doesn't elaborate on implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single verb phrase that communicates the core functionality without any wasted words. It's front-loaded with the essential action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation tool with no annotations, the description is minimal but complete enough to understand the basic function. The presence of an output schema means return values don't need explanation in the description. However, more behavioral context would be helpful given this is a system modification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters at all, but with only one optional parameter (device_serial) and 0% schema description coverage, the baseline would be lower. However, the tool's purpose is so specific (clearing a system buffer) that the single parameter's role is reasonably inferable - it identifies which device to target when multiple are connected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and target resource ('the logcat buffer'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'get_logcat' beyond the verb, but the verb itself provides clear distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the verb 'clear' suggests it's for resetting/emptying the buffer, there's no mention of prerequisites, side effects, or when this operation is appropriate versus just reading logs with 'get_logcat'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Clear HTTP proxy settings' implies a write operation that changes device configuration, but it doesn't specify whether this requires specific permissions, if changes are immediate or require reboot, what happens to existing proxy configurations, or potential side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a configuration mutation tool with no annotations but with an output schema, the description is minimally adequate. It states what the tool does but lacks important context about behavioral implications, success/failure conditions, and relationship to sibling tools. The existence of an output schema helps but doesn't compensate for the missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has only one optional parameter (device_serial) with 0% schema description coverage. The description doesn't mention parameters at all, which is acceptable since there's only one optional parameter and the schema provides basic information. However, it could clarify when device_serial is needed versus using a default device.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and resource ('HTTP proxy settings'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'set_proxy' or other configuration tools, which would require more specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'set_proxy' or other configuration management tools. There's no mention of prerequisites, typical use cases, or what happens after clearing proxy settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool does ('Get the currently focused app and activity') but lacks details on permissions required, output format, error conditions, or side effects. For a tool with no annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get the currently focused app and activity.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on behavior, output, or usage scenarios. For a tool with no annotations or output schema, it should provide more guidance to be fully complete, but it meets the bare minimum for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, but the parameter is optional (required parameters: 0). The description doesn't mention the parameter at all, which is acceptable since it's optional and the tool likely defaults to a primary device. With 0 required parameters, the baseline is 4, as the description needn't detail parameters that aren't essential for basic use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the currently focused app and activity.' It uses a specific verb ('Get') and identifies the resource ('currently focused app and activity'), which is distinct from sibling tools like 'get_app_info' or 'get_device_info.' However, it doesn't explicitly differentiate from siblings beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., device connectivity), exclusions, or comparisons to similar tools like 'get_accessibility_info' or 'get_ui_hierarchy,' which might overlap in functionality. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all connected Android devices with details') but doesn't explain what 'details' include, whether this is a read-only operation, if it requires specific permissions, or how it handles multiple devices. For a tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It is appropriately sized for a simple listing tool, making it easy for an agent to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, with no annotations and many sibling tools, it lacks context on behavior and usage, which could hinder agent selection. It meets basic requirements but has clear gaps in guidance and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here, but it could have clarified output semantics (though an output schema exists). Baseline is 4 for zero parameters, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('connected Android devices with details'), making the purpose specific and understandable. However, it doesn't explicitly distinguish itself from sibling tools like 'get_device_info' or 'get_screen_specs', which might also provide device-related information, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling tools that interact with devices (e.g., 'get_device_info', 'list_packages'), there is no indication of context, prerequisites, or exclusions for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Press the home button') without mentioning effects (e.g., returning to home screen, potential app state changes), permissions required, or any side effects like rate limits or device-specific behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence ('Press the home button') with no wasted words, making it highly concise and front-loaded. Every word earns its place by clearly stating the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple action with one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on usage scenarios and behavioral details, which are needed for full completeness, especially with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (device_serial) with 0% description coverage, and the description doesn't mention parameters at all. However, since there's only one optional parameter, the baseline is high. The description doesn't add meaning beyond the schema, but the minimal parameter count keeps the score from dropping lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press the home button' clearly states the action (press) and target (home button), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'press_back' or 'press_recent_apps' beyond the button name, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like 'press_back' or 'press_recent_apps', nor does it mention any prerequisites or context for usage. It merely states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose what 'Open' entails (e.g., whether it's a toggle, how long it takes, if it requires device interaction), leaving gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that front-loads the core action. There's no wasted wording, making it easy to parse quickly while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and a mutation-like action ('Open'), it should ideally include more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has one optional parameter ('device_serial'), but schema description coverage is 0%, so the description must compensate. Since the description doesn't mention any parameters, it doesn't add semantics, but with 0 required parameters and a simple optional one, the baseline is high. The lack of parameter explanation is less critical here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and the target ('recent apps / app switcher'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'press_back' or 'press_home', but it's specific enough to know this triggers a system UI component rather than a navigation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention prerequisites (e.g., device state), exclusions, or how it differs from similar navigation tools like 'press_home' or 'press_back' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this requires specific permissions, affects device performance, is reversible, or has side effects like a reboot. More context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, one parameter, and an output schema (which handles return values), the description is minimal but covers the basic action. However, for a mutation tool that likely alters device settings, more detail on behavior and usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, but with only one optional parameter (device_serial) and 0% schema description coverage, it adequately implies a device-specific operation. For a single parameter tool, the baseline is high as the description focuses on the core action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reset') and the target ('density'), specifying it's to 'physical default'. It distinguishes from sibling 'change_density' by indicating a reset rather than a change, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'change_density' or other device configuration tools. The description lacks context about prerequisites, such as device state or permissions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('reset') but doesn't clarify if this requires specific permissions, whether it affects device state permanently, or what happens if the device is disconnected. For a mutation tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and outcome, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and a simple single optional parameter, the description is minimally adequate. However, as a mutation tool with no behavioral context or usage guidelines, it lacks completeness for safe and effective use by an AI agent, especially compared to siblings like 'change_screen_size'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, but the input schema has only one optional parameter ('device_serial') with 0% schema description coverage. Since there are zero required parameters, the baseline is high. The description implies the tool operates on a device, which aligns with the parameter, but doesn't add specific details beyond what the schema title ('Device Serial') suggests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reset') and target ('screen size') with the specific outcome ('to physical default'). It distinguishes from sibling tools like 'change_screen_size' by focusing on restoration rather than modification. However, it doesn't explicitly contrast with 'reset_density', which is a similar reset operation for a different property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'change_screen_size' or 'reset_density'. It doesn't mention prerequisites, such as needing a connected device, or scenarios where resetting is appropriate (e.g., after testing different sizes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('scroll down') but fails to describe how it behaves—such as scroll distance, speed, direction, or effects on UI state. For a UI interaction tool with zero annotation coverage, this is a significant gap in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, which is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks details on behavioral aspects like scroll behavior or device context, leaving gaps in overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('device_serial') with 0% description coverage, and the description doesn't mention parameters at all. Since there's only one optional parameter, the baseline is high, but the description doesn't add any semantic context about when or why to specify the device serial, missing an opportunity to clarify its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scroll down') and the target ('on the current screen'), providing a specific verb+resource combination. However, it doesn't differentiate from its sibling 'scroll_up' or other navigation tools like 'swipe', leaving room for improvement in distinguishing between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'scroll_up', 'swipe', or 'scroll_to_text'. It lacks context about prerequisites (e.g., needing a screen to be active) or exclusions, offering minimal usage direction beyond the basic action stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions stopping recordings but doesn't disclose what happens to the recording file, whether this requires specific permissions, if it works across all devices, or what the expected outcome is. The description is too sparse for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence that states the core functionality upfront. There's no wasted verbiage or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema present, the description is minimally adequate. The output schema will provide return value details, but the description lacks important context about behavior, prerequisites, and relationships with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter (device_serial), the description adds no parameter-specific information. However, since there's only one optional parameter, the baseline is appropriately high. The description implies the tool works without parameters to stop 'any' recording, which aligns with the optional nature of device_serial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and target ('any ongoing screen recording'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'start_screen_record' or 'pull_recordings' beyond the obvious opposite 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/5Does 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, prerequisites for use, or what constitutes 'ongoing screen recording.' It doesn't mention the relationship with 'start_screen_record' or other recording-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions extracting 'visible text' but doesn't specify behavioral traits like whether it requires specific permissions, how it handles dynamic content, error conditions, or performance implications. This leaves gaps in understanding the tool's operation beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that directly state the purpose and a usage hint. Every word earns its place, and there's no unnecessary information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (text extraction from a screen), no annotations, and an output schema present, the description is minimally adequate. It covers the basic purpose and a usage hint but lacks details on behavioral aspects and parameter context, which could be important for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('device_serial') with 0% description coverage, and the tool description doesn't mention any parameters. Since there's only one parameter and it's optional (default: null), the baseline is moderate. The description doesn't add meaning beyond the schema, but the simplicity of the parameter list keeps it from scoring lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract all visible text from current screen.' It specifies the verb ('extract') and resource ('all visible text'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_ui_hierarchy' or 'screenshot', which might also provide text-related data, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance with 'Useful for verifying text content matches designs,' suggesting a context for when to use it. However, it lacks explicit alternatives or exclusions, such as when to choose this over 'get_ui_hierarchy' for text extraction or 'screenshot' for visual verification, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the emulator constraint, it doesn't describe what happens after sending (e.g., success/failure response, delivery confirmation, error conditions), whether there are rate limits, or authentication requirements. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 words, with zero wasted language. It's front-loaded with the core action and includes the critical constraint in parentheses. Every word serves a purpose, making this optimally efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (sending messages with 3 parameters), no annotations, but with an output schema available, the description provides minimal but sufficient context for basic usage. The emulator constraint is important context, but more behavioral information would be helpful since this appears to be a testing/development tool among many device control siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters at all, failing to explain what 'phone_number', 'message', or 'device_serial' represent or their expected formats. However, with only 3 parameters and an output schema available, the baseline is 3 as the agent can infer basic usage from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send an SMS') and the target ('to the emulator'), with the parenthetical '(emulator only)' providing important scope limitation. However, it doesn't distinguish this tool from potential alternatives like 'simulate_call' or other communication tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with '(emulator only)', suggesting this tool should only be used with emulated devices rather than physical ones. However, it provides no explicit guidance on when to choose this over other communication tools like 'simulate_call' or when not to use it, leaving the agent to infer appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a critical behavioral trait: 'Use with caution - this gives full shell access,' warning about potential risks like destructive actions or security issues. However, it lacks details on permissions needed, rate limits, output format, or error handling, which are important for a tool with such broad access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the purpose and a critical warning. Every sentence earns its place with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (arbitrary shell execution) and lack of annotations, the description is incomplete. It warns about risks but doesn't cover prerequisites, output behavior, or error scenarios. The presence of an output schema helps, but for such a powerful tool, more context on safe usage and limitations is needed to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'ADB shell command,' which hints at the 'command' parameter, but doesn't explain the 'device_serial' parameter or provide examples or syntax for commands. With 2 parameters and no schema descriptions, this adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute an arbitrary ADB shell command.' It specifies the verb ('Execute') and resource ('ADB shell command'), making it unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_devices' or 'reboot_device', which might also involve ADB commands but are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance with 'Use with caution - this gives full shell access,' implying it should be used carefully due to its power. However, it doesn't specify when to use this tool versus more specific siblings (e.g., 'reboot_device' for rebooting) or mention alternatives, leaving usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool's function ('Show visual feedback for taps') and use case, but doesn't disclose behavioral traits such as whether it requires specific permissions, if changes are persistent, potential side effects (e.g., performance impact), or what the output schema returns. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with two clauses—and front-loaded with the core purpose. Every word earns its place by stating the action and context without redundancy. It efficiently communicates the essential information in a minimal format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and 0% schema coverage, the description is incomplete. It covers the basic purpose and use case but lacks details on parameters, behavioral nuances, and how it integrates with sibling tools. For a tool with two parameters and no annotation support, more context would be beneficial to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description doesn't mention any parameters explicitly, but it implies the 'enable' parameter through the action 'Show' (which suggests toggling on/off). However, it doesn't explain the 'device_serial' parameter or provide details beyond basic inference. With low schema coverage, the description adds minimal value, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show visual feedback for taps' indicates it controls a visual indicator for touch interactions. It specifies the context ('useful for demos/recordings'), which helps distinguish it from general tap-related tools like 'tap' or 'tap_element'. However, it doesn't explicitly differentiate from 'toggle_show_layout_bounds', which is a similar visual toggle tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('useful for demos/recordings'), suggesting when this tool might be beneficial. However, it doesn't provide explicit guidance on when to use it versus alternatives (e.g., other visual feedback tools) or any prerequisites (e.g., device connection). The context is helpful but lacks specificity for sibling tool differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Rotate') which implies a mutation, but doesn't disclose whether this requires specific permissions, affects device state persistently, has side effects (e.g., on apps), or what the output includes. The description adds minimal context beyond the basic action, leaving key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with the purpose stated in the first three words and parameter details following directly. Every sentence earns its place by providing essential information without redundancy. The structure is efficient, with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with 2 parameters) and the presence of an output schema (which reduces the need to describe return values), the description is partially complete. It excels in parameter semantics but lacks behavioral context, usage guidelines, and integration with sibling tools. The output schema likely covers return values, but the description doesn't address mutation risks or device-specific considerations, leaving gaps in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explicitly defines the valid values for the 'orientation' parameter ('portrait', 'landscape', 'reverse_portrait', 'reverse_landscape', or 'auto'), providing crucial semantics that the schema lacks. This compensates fully for the schema's deficiency, making parameter usage clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rotate screen orientation') and identifies the resource ('screen'), making the purpose immediately understandable. It distinguishes itself from siblings like 'change_screen_size' or 'screenshot' by focusing on orientation rather than size or capture. However, it doesn't explicitly differentiate from all possible alternatives in the sibling list, such as device-specific controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or context. It doesn't mention whether this is for testing, accessibility, or general device control, nor does it reference sibling tools like 'change_screen_size' or 'get_screen_specs' for related operations. Usage is implied through the parameter explanation but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits like whether this simulates keyboard input, whether it overwrites existing text, if there are rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (2 parameters, no annotations but with output schema), the description covers the basic action but lacks important context about how it works, error conditions, or interaction patterns. The presence of an output schema helps, but for a mutation tool that interacts with UI elements, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters, leaving both 'text' and 'device_serial' completely undocumented. However, with only 2 parameters and an output schema present, the baseline is 3 as the description doesn't add value but the schema structure is simple.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Type text') and target ('into the currently focused field'), distinguishing it from sibling tools like 'clear_text_field' or 'tap_element'. It uses precise verb+resource language that leaves no ambiguity about its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('currently focused field') but doesn't explicitly state when to use this versus alternatives like 'tap_element' followed by input_text, or clarify prerequisites like needing a field to be focused first. It provides basic contextual guidance 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool's purpose and use case but doesn't describe important behavioral aspects: whether this requires specific permissions, if changes persist across reboots, what happens on different Android versions, or what the output contains. For a system configuration tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence explains what the tool does with specific parameter semantics. The second sentence provides clear usage context. No wasted words, well-structured, and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values), no annotations, and moderate complexity (2 parameters with 0% schema coverage), the description is moderately complete. It covers the main purpose and use case but misses important behavioral context for a system configuration tool and leaves one parameter undocumented. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description explains the 'scale' parameter values (0, 1, 0.5) and their meanings, which adds significant value beyond the bare schema. However, it doesn't mention the 'device_serial' parameter at all, leaving half the parameters undocumented. The description partially compensates but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set animation scale' with specific scale values explained (0=off, 1=normal, 0.5=fast). It distinguishes itself from siblings like 'set_font_scale' by focusing on animation rather than font or other UI settings. However, it doesn't explicitly differentiate from all possible UI configuration tools beyond the immediate context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Useful for speeding up UI tests.' This gives practical guidance about its primary use case. However, it doesn't specify when NOT to use it or mention alternatives like other performance optimization tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (base64 PNG) and implies a read-only operation, but lacks details on permissions, device state requirements, or potential side effects (e.g., if it interrupts device usage).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the primary action and efficiently convey the return value. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and minimal parameters, the description adequately covers the basic purpose and output. However, it lacks context on error conditions, device compatibility, or how the base64 output should be handled, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema (which has 0% coverage), but since there's only one optional parameter (device_serial), the tool's core functionality is clear without it. The baseline is high due to minimal parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a screenshot') and the target ('device screen'), distinguishing it from sibling tools like 'screenshot_to_file' or 'capture_screen_for_comparison' by specifying the output format (base64 PNG).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'screenshot_to_file' (which saves to a file) or 'capture_screen_for_comparison' (which may have different functionality). The description only states what it does, not when it's preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a system-level setting change ('Set system font scale') and mentions accessibility testing purpose, but doesn't disclose important behavioral aspects like whether changes persist across reboots, require specific permissions, affect all apps or just the current session, or have any side effects on other display properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two focused sentences that each earn their place. The first sentence states the purpose with concrete values, and the second sentence provides the usage context. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a system configuration tool with no annotations, 2 parameters (one well-explained, one undocumented), and an output schema exists (reducing need to describe return values), the description does reasonably well. It covers the core functionality and testing context but leaves gaps about the device_serial parameter and some behavioral implications of changing system settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It provides excellent semantic context for the 'scale' parameter by defining the meaning of specific values (0.85=small, 1.0=normal, etc.), which is crucial information not in the schema. However, it doesn't mention the 'device_serial' parameter at all, leaving one of the two parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Set') and resource ('system font scale'), including concrete scale values (0.85-1.3) with accessibility testing context. It distinguishes from sibling tools like 'change_density' or 'reset_screen_size' by focusing specifically on font scaling rather than other display properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Useful for testing font scaling accessibility'), which implicitly suggests it's for accessibility testing scenarios rather than general UI adjustments. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the recording runs in the background, has a maximum duration of 180 seconds, and requires 'stop_screen_record' to stop early. However, it doesn't mention permissions, file format, or storage location, which are gaps for a tool with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses only two concise sentences that each provide essential information—no wasted words. It efficiently conveys key constraints and usage instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a background recording operation with 3 parameters and no annotations), the description covers the core behavior and usage well. However, it lacks details on output (though an output schema exists, so this is mitigated) and doesn't fully address all parameters, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies a 'duration_seconds' parameter by mentioning 'Max duration is 180 seconds' but doesn't explain the other two parameters ('filename', 'device_serial'). This adds some meaning but falls short of fully compensating for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start recording the screen') and resource (the screen), distinguishing it from sibling tools like 'screenshot' or 'stop_screen_record'. It explicitly defines the tool's function without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to start recording) and when to use an alternative ('use stop_screen_record to stop early'). It also mentions the maximum duration constraint, which helps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/rahulkr/r_adb_mcp_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server