AutoMobile

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between pressButton and pressKey (both press hardware buttons, with pressKey described as the 'Maestro equivalent'), and between scroll and swipe (both handle directional movement, with swipe described as a 'unified scroll command'). These overlaps could cause confusion for an agent trying to select the right tool.
Naming Consistency4/5
Tool names are mostly consistent with a verb_noun pattern (e.g., clearText, installApp, launchApp), but there are minor deviations like observe (verb only) and getAllConfigs (verb_adjective_noun). Overall, the naming is readable and follows a predictable convention with only a few outliers.
Tool Count2/5
With 38 tools, the count is excessive for an Android automation server, making it feel heavy and potentially overwhelming. A more focused set of 10-20 tools would be more appropriate for this domain, as many tools could be consolidated or omitted without losing functionality.
Completeness5/5
The tool surface is highly complete for Android device automation, covering installation, configuration, navigation, input, interaction, and device management. It includes CRUD-like operations (e.g., installApp, listApps, terminateApp) and supports core workflows without obvious gaps, ensuring agents can handle most automation tasks effectively.
Average 2.9/5 across 38 of 38 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on July 22, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides almost none. It doesn't indicate whether this is a read or write operation, what happens when the element isn't found, whether it requires specific device states, or what the expected outcomes are. The description fails to disclose critical behavioral traits needed for safe and effective tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just 4 words, this is under-specification rather than effective conciseness. The single phrase doesn't provide enough information to be useful, and it's not front-loaded with the most critical information. Every word should earn its place, but here the words don't provide sufficient value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a 5-parameter mobile interaction tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behaviors to expect, or how parameters interact. For a tool that performs UI actions on mobile devices, this minimal description leaves the agent guessing about critical operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly with descriptions and enums. The description mentions 'text or resourceId' which loosely maps to the text and id parameters, but doesn't add meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tap supporting text or resourceId' is a tautology that essentially restates the tool name 'tapOn' without adding meaningful specificity. It mentions 'supporting text or resourceId' which hints at the text/id parameters, but doesn't clearly state what the tool actually does (perform UI interactions on mobile elements). It doesn't distinguish this from similar sibling tools like swipeOnElement or pressButton.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to other interaction tools like swipeOnElement, pressButton, or inputText. There's no indication of prerequisites, constraints, or typical use cases for mobile UI automation.
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 setting parameters but doesn't clarify if this is a write operation, what permissions are needed, whether changes are reversible, or any side effects like device state changes. This is inadequate for a tool with multiple parameters and nested objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action. However, it lacks detail that would enhance clarity, making it somewhat under-specified rather than optimally concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't cover behavioral aspects, parameter interactions, or usage context, leaving the agent with insufficient information to invoke the tool correctly without relying heavily on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only some parameters documented in the schema. The description adds no meaning beyond the schema, failing to explain the purpose of modes like 'exploration' or 'testAuthoring,' or how parameters interact. For a tool with 4 parameters and nested objects, this leaves significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Set parameters for a particular device in a given mode,' which provides a general purpose (setting device parameters) but is vague about what specific modes or parameters are involved. It doesn't distinguish from sibling tools like 'setActiveDevice' or 'resetConfig,' which also involve device settings, leaving ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the device must be active or in a specific state, and doesn't mention any sibling tools as alternatives, leaving the agent to infer usage from the input schema 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 mentions 'Automatically handle' but doesn't specify what this entails—e.g., whether it interacts with UI elements, requires permissions, has side effects like closing dialogs, or handles errors. For a tool that likely involves system-level interactions, this lack of detail is a significant gap, making it hard for an agent to predict outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's front-loaded with the core action ('Automatically handle'), but could be slightly improved by specifying the outcome (e.g., 'dismiss' or 'select'). Overall, it's concise and well-structured, earning a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of handling system dialogs, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like success/failure conditions, return values, or error handling. For a tool that interacts with system UI, more context is needed to ensure the agent can use it effectively, making this inadequate for the task's demands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions and an enum for 'preference'. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions (e.g., that 'customAppPackage' is only relevant for 'custom' preference) or usage examples. Since the schema is well-documented, the baseline score of 3 is appropriate, but the description doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Automatically handle system intent chooser dialog with specified preferences', which provides a verb ('handle') and resource ('system intent chooser dialog'). However, it's somewhat vague about what 'handle' means (e.g., dismiss, select, interact) and doesn't clearly distinguish from sibling tools like 'detectIntentChooser' or 'openLink', which might have overlapping functionality. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like when an intent chooser appears, prerequisites (e.g., after launching an app), or exclusions (e.g., not for web links). With siblings like 'detectIntentChooser' and 'openLink', there's no indication of how this tool fits into a workflow, 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 performs an action but doesn't describe what happens (e.g., whether it triggers UI changes, requires specific device states, or has side effects like closing keyboards). For a tool with potential mutation effects and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Perform an IME action') and includes relevant examples. There's no wasted text, making it easy to parse, though it could be slightly more structured (e.g., by clarifying the IME context upfront).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of IME actions (likely involving device input handling), no annotations, and no output schema, the description is incomplete. It doesn't explain what IME stands for, the expected outcomes, error conditions, or how it integrates with sibling tools. For a 2-parameter tool with potential behavioral nuances, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('action' and 'platform') fully documented in the schema via enums and descriptions. The description adds no additional parameter semantics beyond the examples in parentheses, which align with the enum values. Given high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Perform[s] an IME action' with examples (done, next, search), which provides a basic verb+resource understanding. However, it's vague about what IME actions are and doesn't distinguish this tool from sibling tools like 'pressKey' or 'inputText' that might handle similar input scenarios. The purpose is understandable but lacks specificity about the IME 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active IME context), exclusions, or how it differs from sibling tools like 'pressKey' for keyboard actions. Usage is implied through examples but not explicitly defined, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('input text') but doesn't explain how it behaves—e.g., whether it simulates typing, requires device focus, has side effects like triggering UI responses, or handles errors. This leaves 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Input text to the device' is front-loaded and directly conveys the core purpose without unnecessary details, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't address behavioral aspects, usage context, or output expectations, leaving gaps that hinder the agent's ability to invoke it correctly in a device interaction scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'text', 'imeAction', and 'platform'. The description adds no additional meaning beyond implying text input, which aligns with the schema but doesn't enhance understanding. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Input text to the device' clearly states the action (input) and target (device), but it's vague about what 'input' entails (e.g., typing, pasting) and doesn't distinguish it from sibling tools like 'clearText' or 'selectAllText'. It avoids tautology by not restating the name exactly, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage from sibling tool names alone, which is insufficient for clear 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 full burden. It states the action ('swipe') but doesn't disclose behavioral traits such as whether it requires prior element identification, what happens on failure (e.g., if element not found), or any side effects (e.g., UI changes). This is a significant gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for its content, though it could be more informative. Every word earns its place by stating the core action concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 5 parameters, the description is incomplete. It lacks behavioral context (e.g., success/failure outcomes), usage guidelines, and doesn't compensate for the absence of structured fields, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters with descriptions and enums. The description adds no meaning beyond what the schema provides, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swipe on a specific element' states a clear verb ('swipe') and target ('specific element'), but it's vague about what constitutes an 'element' (e.g., UI component) and doesn't distinguish it from sibling tools like 'swipe' or 'swipeOnScreen'. It provides basic purpose but lacks specificity for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'swipe' or 'swipeOnScreen'. The description implies usage for swiping on elements, but there's no explicit context, exclusions, or prerequisites mentioned, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions swiping in a direction but doesn't explain effects like whether it simulates user input, requires device permissions, has side effects (e.g., changing app state), or handles errors. For a tool with 4 required 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Swipe on screen') and specifies the key constraint ('in a specific direction'), making it easy to parse quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 4-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what the tool returns, error conditions, or prerequisites (e.g., device state). For a tool that likely interacts with device interfaces, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'direction' as direction to swipe, 'duration' in milliseconds). The description adds no additional meaning beyond the schema, such as explaining how parameters interact or default behaviors. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swipe on screen in a specific direction' clearly states the action (swipe) and target (screen), but it's vague about the scope and context. It doesn't specify whether this is for UI testing, device control, or another use case, and it doesn't distinguish itself from sibling tools like 'swipe' or 'swipeOnElement'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'swipe' and 'swipeOnElement' available, there's no indication of how this tool differs—such as whether it's for general screen swipes, specific to certain apps, or requires particular device states. This leaves the agent without clear usage 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. While 'Clear text' implies a destructive write operation, the description doesn't specify what 'clear' entails (e.g., deletion, reset to empty), whether it requires specific permissions, or how it interacts with the UI (e.g., triggers events). This leaves significant gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error conditions), usage context, and return values, which are critical for an AI agent to invoke it correctly in a UI automation scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'platform' fully documented in the schema as 'Platform of the device' with enum values. The description adds no parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear text') and target ('currently focused input field'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'selectAllText' or 'inputText', which might have overlapping or related functionality for text manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a focused input field), exclusions, or comparisons to sibling tools like 'selectAllText' or 'inputText' for text-related operations.
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 action and outcome but doesn't address important behavioral aspects like whether this requires specific permissions, if it's reversible, what happens to existing demo mode settings, or potential side effects. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's zero wasted language, and it's front-loaded with the core action. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that presumably changes system behavior (disabling demo mode), the description is inadequate given no annotations and no output schema. It doesn't explain what 'demo mode' is, what 'normal status bar behavior' means, or what the tool returns. The minimal description leaves too many contextual gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'platform' parameter with its enum values. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Disable demo mode') and the outcome ('return to normal status bar behavior'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'enableDemoMode' beyond the obvious opposite action, 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/5
Does 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. The description doesn't mention prerequisites, timing considerations, or what 'demo mode' represents in context. It simply states what the tool does without contextual usage information.
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 querying deep links and intent filters but fails to describe key behaviors: whether this is a read-only operation, what the output format looks like (e.g., list of links, JSON structure), any rate limits, or authentication needs. This is inadequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of querying deep links (which may involve app inspection and data retrieval), the description is insufficient. With no annotations and no output schema, it fails to explain the return values or behavioral traits. The description alone does not provide enough context for an agent to use the tool effectively, especially compared to more complete tool definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'appId' parameter clearly documented as 'Android app package ID to query for deep links'. The description does not add any additional meaning beyond this, such as examples or constraints on the appId format. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Query') and resource ('available deep links and intent filters for an Android application'), making it easy to understand what the tool does. However, it does not explicitly differentiate this tool from potential siblings like 'openLink' or 'detectIntentChooser', which might also handle deep links in different ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., needing an installed app), exclusions, or comparisons to sibling tools such as 'openLink' (which might open a link) or 'detectIntentChooser' (which might handle intent detection). This leaves the agent without clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions installation but lacks details on permissions required, whether it overwrites existing apps, error handling, or side effects. This is insufficient 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/5
Is 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.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like success/failure outcomes, dependencies, or device requirements, leaving significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting the 'apkPath' parameter. The description adds no additional semantic context beyond what the schema provides, such as file format specifics or path examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('install') and target resource ('an APK file on the device'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'installPlatformDependencies' or 'setAppSource', which could provide similar functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'installPlatformDependencies' or 'setAppSource', nor does it mention prerequisites such as device state or permissions. It simply states what the tool does 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('install') but doesn't describe what this entails—whether it modifies system state, requires specific permissions, has side effects, or provides feedback on success/failure. For a tool that likely performs system modifications, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and scope without any wasted words. It's appropriately sized for a tool with two parameters and clear purpose, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely performs system installations. It doesn't explain what 'install' entails behaviorally, what dependencies are installed, how success is indicated, or potential errors. For a tool with potential side effects, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('platform' and 'update') well-documented in the schema. The description adds no additional parameter semantics beyond implying the platform parameter's existence ('for the specified platform'). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('install') and resource ('dependencies and tools') with specific scope ('for the specified platform'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'checkPlatformDependencies', but the action is distinct enough to infer 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'checkPlatformDependencies' or other setup-related tools. There's no mention of prerequisites, typical scenarios, or exclusions, 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?
No annotations are provided, so the description carries the full burden. 'Kill' implies a destructive operation, but the description doesn't specify if this is irreversible, requires permissions, affects other processes, or has side effects like data loss. This leaves critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Kill a running device'), which is front-loaded and wastes no words. It efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (destructive operation with nested parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral risks, prerequisites, or what happens post-execution, making it inadequate for safe and 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond the input schema, which has 0% description coverage. However, there is only 1 parameter (a nested object), so the burden is lower. The schema defines the nested properties clearly, making the description's lack of detail less critical, but it still doesn't explain what 'device' entails in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('kill') and resource ('a running device'), which clarifies the basic action. However, it doesn't distinguish this tool from sibling tools like 'terminateApp' or 'startDevice', leaving ambiguity about scope and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'terminateApp', 'startDevice', and 'setActiveDevice', there's no indication of whether 'killDevice' is for physical devices, emulators, or specific contexts, leading to potential misuse.
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 basic action without disclosing behavioral traits. It doesn't mention whether this requires specific permissions, what happens if the app isn't installed, potential side effects, or error conditions. For a tool that likely interacts with device/app 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/5
Is 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with apps/device state), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or important behavioral context needed for safe operation in a testing/automation environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch') and target resource ('an app by package name'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'startDevice' or 'openLink' which might also involve launching/opening functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'openLink' for URLs or 'startDevice' for device startup. It also doesn't mention prerequisites such as needing an app to be installed first, which is implied but not 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 full burden. It states a read operation ('List'), implying non-destructive behavior, but doesn't disclose any behavioral traits such as permissions needed, rate limits, output format, or whether it lists all apps or just user-installed ones. This is inadequate 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/5
Is 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 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, app details included) or address behavioral aspects like error handling. For a tool with zero structured coverage beyond input schema, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'platform' fully documented in the schema as a required enum. The description adds no additional meaning about parameters beyond what the schema provides, such as explaining why platform selection matters. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all apps installed on the device'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'listDevices' or 'listDeviceImages', which also list resources but different ones, so it misses 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention when to choose 'listApps' over 'recentApps' or other listing tools, nor does it specify prerequisites or exclusions, leaving usage context vague.
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 action ('List') but lacks behavioral details: it doesn't specify if this requires permissions, what the return format looks like (e.g., list structure, pagination), or any side effects (e.g., whether it triggers device scans). 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/5
Is 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 purpose ('List all connected devices') and adds clarifying detail ('both physical and virtual devices') without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns a list of devices. It doesn't explain what information is returned (e.g., device IDs, statuses) or any constraints (e.g., only active devices). For a read operation with no structured output documentation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'platform' fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides (e.g., it doesn't explain why platform filtering is needed or how it affects results). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all connected devices'), specifying both physical and virtual devices. It distinguishes from obvious siblings like 'listApps' or 'listDeviceImages' by focusing on devices rather than apps or images. However, it doesn't explicitly differentiate from all siblings, such as 'getAllConfigs' which might also retrieve device-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'setActiveDevice', 'startDevice', or 'killDevice', there's no indication of prerequisites, sequencing, or comparative use cases. The agent must infer usage from 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?
No annotations are provided, so the description carries the full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific device states, has performance impacts, returns structured data, or handles errors. This leaves significant gaps for a tool interacting with device screens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, front-loading the core action and resource. It efficiently communicates the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of device interaction and no annotations or output schema, the description is insufficient. It lacks details on return values (e.g., hierarchy format), error conditions, dependencies on other tools (e.g., 'startDevice'), or behavioral constraints, making it incomplete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'platform' fully documented in the schema (enum: 'android', 'ios'). The description adds no additional parameter semantics beyond implying it retrieves screen data, which aligns with the schema but doesn't provide extra value like format details or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('view hierarchy of what is displayed on screen'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getAllConfigs' or 'listApps', which also retrieve information but about 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for device interaction (e.g., 'tapOn', 'scroll', 'listApps'), there's no indication of context, prerequisites, or exclusions for using 'observe'.
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 ('press') but doesn't explain what happens after pressing (e.g., device response, side effects, or error conditions). For a hardware interaction 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste—it efficiently conveys the core action without unnecessary details. It's appropriately sized and front-loaded, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a hardware interaction tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral outcomes, error handling, or dependencies, leaving the agent with incomplete context 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('button' and 'platform') fully documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as explaining button effects or platform-specific nuances. The baseline score of 3 reflects adequate but minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('press') and resource ('hardware button on the device'), making the tool's function immediately understandable. However, it doesn't distinguish this from sibling tools like 'pressKey' or 'tapOn', which might have overlapping functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'pressKey' or 'tapOn'. There's no mention of prerequisites, such as device state or dependencies, or explicit exclusions for when other tools might be more 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Open') but doesn't describe what happens after opening (e.g., does it return a list, require user interaction, or just trigger a system UI?). It also omits critical details like whether this requires specific device states (e.g., unlocked screen) or has side effects (e.g., interrupting current apps). For a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Open') and target ('recent apps list'), making it immediately scannable and efficient. Every word earns its place, and there's no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (one parameter, no output schema), the description is minimal but inadequate. It lacks context about what 'opening' entails (e.g., UI interaction vs. data retrieval), expected outcomes, or device requirements. Without annotations or output schema, the description should provide more behavioral clarity to be complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'platform' fully documented in the schema (enum: android/ios). The description adds no parameter-specific information beyond implying platform relevance through the action. Since schema coverage is high, the baseline score of 3 is appropriate—the description doesn't add value but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open the recent apps list' clearly states the action (open) and target (recent apps list), making the purpose immediately understandable. It distinguishes itself from siblings like 'listApps' (which likely lists installed apps) and 'homeScreen' (which navigates to home). However, it doesn't specify what 'recent apps' means in this context (e.g., system-level recent apps view vs. app-specific history), 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be unlocked), exclusions (e.g., not available on certain platforms), or compare it to similar tools like 'homeScreen' or 'listApps'. The agent must infer usage from the tool name and 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 full burden. It states the tool sets orientation, implying a mutation, but doesn't disclose behavioral traits like whether it requires specific device states, has side effects (e.g., affecting apps), or error conditions. This is a significant gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and 2 required parameters, the description is incomplete. It lacks information on behavioral context (e.g., device requirements, effects), usage guidelines, and output expectations. The high schema coverage helps but doesn't compensate for missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('orientation' and 'platform') well-documented in the schema with enums and descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining interactions between parameters. Baseline is 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rotate') and the target ('the device'), specifying it sets a specific orientation. It uses a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling tools that might also manipulate device orientation, though none are explicitly listed among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be active), exclusions, or related tools. Among siblings, tools like 'setDeviceMode' or 'shake' might be alternatives in some contexts, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions scrolling 'to find an element' but doesn't describe what happens when found/not found, error conditions, performance characteristics, or side effects. The agent must infer behavior from the tool name and parameters alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality. However, it could be more front-loaded by explicitly stating the primary purpose before the optional capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how errors are handled, or the interaction between scrolling and element-finding. The agent lacks critical context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds marginal value by mentioning 'supports text and selectors' which relates to the 'lookFor' parameter, but doesn't provide additional semantic context beyond what's already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scroll') and target ('scrollable container'), and mentions the optional element-finding capability. It distinguishes from siblings like 'swipe' or 'swipeOnElement' by focusing on scrolling within containers, but doesn't explicitly contrast with 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'swipe' or 'swipeOnElement', nor does it mention prerequisites or contextual constraints. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention whether this requires specific permissions, if the change is persistent, potential side effects, or error conditions. For a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, target, and purpose concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about what 'active device' means operationally, how this affects other tools, return values, or error handling. Given the complexity of device management in the sibling context, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters well-documented in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between deviceId and platform or usage context. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('active device ID'), specifying it's for 'subsequent operations'. However, it doesn't differentiate from sibling tools like 'setDeviceMode' or 'setAppSource' that also modify device settings, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'for subsequent operations', but provides no explicit guidance on when to use this tool versus alternatives like 'setDeviceMode' or prerequisites. There's no mention of when-not-to-use scenarios or clear context for selection among siblings.
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 implies a mutation ('set'), but doesn't specify if this requires specific permissions, whether changes are reversible, or what happens on success/failure. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like side effects, error handling, or return values, leaving significant gaps in understanding how to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning beyond what's in the schema, such as explaining interactions between parameters or usage examples, resulting in the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and the target ('source code path and platform') for a specific resource ('appId'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'installApp' or 'resetConfig', which might involve app-related operations, so it misses 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether it's for initial setup, updates, or specific contexts like development vs. testing. It also lacks prerequisites, like needing an existing app or device configuration, 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 states the action but doesn't disclose behavioral traits like whether this requires specific permissions, if it's safe/reversible, what happens to the device state, or any side effects (e.g., interrupting apps). This is a significant gap 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/5
Is 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, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 3 parameters, the description is incomplete. It lacks behavioral context, usage guidelines, and details on effects, leaving gaps for an agent to understand when and how to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (duration, intensity, platform) with descriptions and defaults. The description adds no parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Shake the device' clearly states the action (shake) and target (device) with a specific verb+resource. However, it doesn't differentiate from sibling tools like 'swipe' or 'rotate' that also manipulate device orientation/motion, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'swipe' or 'rotate' for other motions) or in what context (e.g., testing, simulation). The description lacks any usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Start') but doesn't describe what happens during startup (e.g., boot time, state changes), potential side effects (e.g., resource consumption, impact on other devices), or error conditions (e.g., if device is already running). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It doesn't explain what 'starting' entails behaviorally, what the expected outcome is, or how parameters map to the device image concept, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'platform' has a description, 'localDevice' lacks one). The description mentions 'device image' but doesn't clarify how it relates to the parameters (e.g., whether 'deviceId' or 'name' corresponds to the image). It adds minimal value beyond the schema, failing to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and resource ('a device with the specified device image'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'setActiveDevice' or 'killDevice', which would require more specific context about what 'starting' entails versus activating or terminating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be stopped), related tools (e.g., 'killDevice' for stopping, 'listDevices' for checking status), or specific scenarios (e.g., testing with a particular image). This leaves the agent to 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 the full burden of behavioral disclosure. It mentions 'no index support due to reliability', which adds some context about limitations, but fails to describe critical behaviors like whether this is a read-only or mutating operation, what happens on success/failure, or any performance/rate-limit considerations for a scrolling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a single sentence that communicates the core functionality and a key limitation. It's front-loaded with the main purpose, though it could be slightly more structured by separating the capability statement from the limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a scrolling tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how errors are handled, or provide context about scrolling behavior differences across platforms. The 'no index support' note is helpful but doesn't compensate for other missing behavioral information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema - it mentions direction and speed but doesn't explain their interaction or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a 'Unified scroll command' that supports direction and speed, which is a specific verb+resource combination. It distinguishes itself from siblings like 'scroll' by mentioning 'no index support due to reliability', though it doesn't explicitly differentiate from 'swipeOnElement' or 'swipeOnScreen'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'scroll', 'swipeOnElement', or 'swipeOnScreen'. It mentions 'no index support' as a limitation but doesn't explain when this tool is preferred or when other tools might be better suited.
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 'Terminate' implies a destructive action, it doesn't specify whether this requires special permissions, what happens to app data, whether it's reversible, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the essential information with zero wasted words. Every element ('Terminate', 'app', 'package name') earns its place in this efficient single-sentence structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral implications, return values, error conditions, or how it differs from similar tools. Given the complexity of app termination, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its single parameter ('appId'), so the baseline is 3. The description adds no additional parameter information beyond what's already in the schema, maintaining this adequate but unenhanced level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Terminate') and target resource ('an app by package name'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'killDevice' or 'launchApp' which also affect app/device state, so it doesn't reach the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'killDevice' or 'launchApp', nor about prerequisites or context. The description only states what the tool 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'check' implies a read-only diagnostic operation, the description doesn't clarify what 'installation status' means (e.g., returns boolean, list of missing dependencies, detailed report), whether it has side effects, or what permissions/context it requires. This leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple diagnostic tool 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple diagnostic tool with one well-documented parameter and no output schema, the description is minimally adequate. However, it lacks important context about what the check returns (status format, error conditions) and how it relates to the sibling 'installPlatformDependencies' tool, which reduces completeness for practical agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'platform' clearly documented in the schema as a required enum with values 'android' or 'ios'. The description adds no additional parameter semantics beyond what the schema already provides, which meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('check') and resource ('installation status of platform dependencies and tools'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'installPlatformDependencies', which could create ambiguity about when to use each tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With a sibling tool named 'installPlatformDependencies', there's a clear related alternative, but the description doesn't mention it or provide any context about prerequisites, timing, or workflow sequencing.
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 detects a dialog but doesn't explain what happens upon detection (e.g., returns a boolean, triggers an action, or provides details). It also omits critical context like permissions needed, side effects, or error handling, which is inadequate for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded with the core action ('detect') and resource, making it highly efficient and easy to parse. Every word contributes to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of UI automation and lack of annotations or output schema, the description is incomplete. It doesn't specify what the tool returns (e.g., detection status, dialog details) or behavioral traits like error cases. For a tool that likely interacts with device states, more context on usage and outcomes is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately avoids discussing parameters, focusing on the tool's purpose instead. This meets the baseline for tools with no parameters, as it doesn't add unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting a system intent chooser dialog in the current view hierarchy. It uses specific verbs ('detect') and resources ('system intent chooser dialog', 'current view hierarchy'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'handleIntentChooser', which might handle or interact with the same dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an active device or view hierarchy, or compare it to siblings like 'handleIntentChooser' for context on usage scenarios. This leaves the agent without explicit direction on application.
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 pressing the home button but fails to disclose behavioral traits like whether this action is safe (e.g., read-only vs. destructive), if it requires specific device states, or what happens post-execution (e.g., screen changes). This leaves significant 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the action and method without unnecessary details. It is front-loaded and wastes no words, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter with full schema coverage) and no output schema, the description is minimally adequate but incomplete. It lacks details on behavioral outcomes (e.g., what 'returning to home screen' entails) and doesn't compensate for the absence of annotations, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'platform' parameter fully documented in the schema. The description adds no additional meaning about parameters beyond implying device interaction, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return to the home screen') and the method ('by pressing the home button'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'recentApps' or 'pressButton', which could have overlapping functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'recentApps' for app switching or 'pressButton' for generic button presses. It lacks explicit context, prerequisites, or exclusions, 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 cover critical aspects like whether this requires specific permissions, if it's synchronous/asynchronous, potential errors (e.g., invalid URLs), or side effects (e.g., opening a browser window). This is inadequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential action without any waste. It's appropriately sized for a simple tool, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose but misses behavioral details and usage context, which are important for a tool that interacts with system browsers and devices. 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters ('url' and 'platform') with descriptions and an enum for 'platform'. The description adds no additional semantic meaning beyond what's in the schema, such as explaining why 'platform' is required or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and resource ('a URL in the default browser'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'launchApp' or 'getDeepLinks', which might have overlapping browser-related functionality, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for testing web links, launching apps via URLs, or other contexts, nor does it mention prerequisites like needing a browser installed. This lack of context leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a 'Maestro equivalent' which suggests some emulation behavior, but doesn't disclose whether this requires specific device states, what happens if the key press fails, whether it's synchronous/asynchronous, or any side effects. For a hardware interaction 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/5
Is 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 action tool 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a hardware interaction tool with 2 parameters, 100% schema coverage, but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks important behavioral context about how the key press actually works, what happens on different platforms, or what the expected outcomes are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press a hardware key') and target resource ('on the device'), with a specific verb+resource combination. It distinguishes from the sibling 'pressButton' by specifying this is the 'Maestro equivalent', though it doesn't fully explain the functional difference between pressing a hardware key versus a software button.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'pressButton' or other input methods. While it mentions this is the 'Maestro equivalent of pressButton', it doesn't clarify the specific use cases for hardware keys versus software buttons or when this tool is preferred.
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 that the tool 'will clear all saved configuration,' which implies a destructive mutation, but doesn't specify whether this is reversible, requires permissions, or has side effects (e.g., affecting app state). This leaves significant gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero wasted words. It front-loads the core action ('reset to default settings') and follows with a clarifying consequence ('clear all saved configuration'), making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks details on what 'default settings' entail, whether the reset is immediate or requires confirmation, and what the response looks like (e.g., success/failure indicators).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but this is appropriate given the lack of parameters, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reset to default settings') and the resource ('all saved configuration'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'clearText' or 'getAllConfigs', but the verb 'reset' implies a specific configuration restoration rather than general clearing or reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether configuration must exist), exclusions, or related tools like 'getAllConfigs' for checking current settings before resetting.
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 it's a retrieval operation, implying read-only behavior, but doesn't specify what 'configuration' includes, whether it's device-specific, or if there are any side effects like caching or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no annotations and no output schema, the description is minimally adequate. It states the purpose but lacks details on what 'configuration' entails, potential return values, or behavioral nuances, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have clarified the scope of 'configuration' (e.g., device, app, or system).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve current configuration' clearly states the verb ('Retrieve') and resource ('current configuration'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'resetConfig' or explain what 'configuration' specifically refers to in this 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or how it differs from other configuration-related tools like 'resetConfig', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it 'List[s] all available device images', which suggests a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns paginated results, what format the images are in, or if there are any side effects. For a tool with zero annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all available device images') and specifies the key constraint ('for the specified platform'). There is zero waste, and every word earns its place by clarifying the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage (100%), the description is minimally adequate. However, with no annotations and no output schema, it lacks context about behavioral traits (e.g., read-only vs. destructive, authentication needs) and return values (e.g., what 'device images' includes). This leaves gaps for an AI agent to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'platform' fully documented in the schema (type: string, enum: [android, ios], description: 'Target platform'). The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'available device images' means or how the platform selection affects the output. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'device images', specifying 'for the specified platform'. It distinguishes from obvious siblings like listDevices (which lists devices, not images) and listApps (which lists apps, not images). However, it doesn't explicitly differentiate from less obvious siblings like getAllConfigs or installPlatformDependencies, which might also involve platform-specific resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing available device images for a platform, but provides no explicit guidance on when to use this tool versus alternatives like listDevices or checkPlatformDependencies. It doesn't mention prerequisites, exclusions, or specific scenarios where this tool is preferred over others in the sibling set.
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 outcome ('consistent status bar indicators') but doesn't describe side effects, permissions needed, whether changes persist, or what happens if the tool fails. For a configuration tool with 8 parameters, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Enable demo mode' states the action, 'with consistent status bar indicators' specifies the configuration aspect, and 'for screenshots' provides the use case context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, configuration operation) and absence of both annotations and output schema, the description is minimally adequate. It states what the tool does but lacks information about behavioral consequences, error conditions, or what success looks like. The 100% schema coverage helps but doesn't compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (like explaining relationships between parameters or providing usage examples). Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable demo mode') and the purpose ('with consistent status bar indicators for screenshots'), distinguishing it from sibling tools like 'disableDemoMode' by specifying its enabling function. It's specific about the resource being manipulated (demo mode configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (for screenshots) but doesn't explicitly state when to use this tool versus alternatives like 'setDeviceMode' or 'disableDemoMode'. No prerequisites or exclusions are mentioned, leaving the agent to infer appropriate 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 provided, the description carries full burden for behavioral disclosure. It describes the action but doesn't mention potential side effects (e.g., might trigger notifications), platform-specific variations beyond the parameter, or what happens if the tray is already open. The description is minimal and lacks 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and method. Every word contributes essential information with zero waste, making it perfectly front-loaded and appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. However, it doesn't explain what 'opening' means in behavioral terms (e.g., visual feedback, interaction state) or address potential failure modes, leaving some contextual gaps despite the simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'platform' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('open') and target resource ('system notification tray') with precise implementation details ('by swiping down from the status bar'). It distinguishes itself from sibling tools like 'swipe' or 'swipeOnScreen' by specifying the exact gesture and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (opening the notification tray) but doesn't explicitly state when to use this tool versus alternatives like 'swipe' for general swiping or 'recentApps' for app switching. No guidance is provided about prerequisites or when-not-to-use 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 describes the action ('long press + tap on 'Select All'') but lacks details on permissions, side effects, error conditions, or response behavior. For a tool with no annotation coverage, this is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Select all text') and provides necessary context without waste. Every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does but lacks behavioral details and explicit usage guidelines. For a simple UI automation tool, this is minimally viable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, fully documenting the single parameter 'platform' with its enum values. The description does not add any parameter-specific information beyond the schema, but with only one parameter and high schema coverage, a baseline of 3 is appropriate. The score is elevated to 4 because the tool has zero parameters in practice (the description implies no additional inputs beyond the schema), making it straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Select all text') and the target resource ('currently focused input field'), using precise verbs. It distinguishes itself from sibling tools like 'clearText' or 'inputText' by focusing on text selection rather than text modification or input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the context ('currently focused input field'), but it does not explicitly state when to use this tool versus alternatives like 'clearText' or 'inputText'. No exclusions or prerequisites are mentioned, leaving usage guidance incomplete.
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:

[![auto-mobile MCP server](https://glama.ai/mcp/servers/zillow/auto-mobile/badges/card.svg)](https://glama.ai/mcp/servers/zillow/auto-mobile)

Score Badge

Copy to your README.md:

[![auto-mobile MCP server](https://glama.ai/mcp/servers/zillow/auto-mobile/badges/score.svg)](https://glama.ai/mcp/servers/zillow/auto-mobile)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zillow/auto-mobile'

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