ghost-in-the-droid
OfficialServer Quality Checklist
Latest release: v1.5.1
- Disambiguation2/5
Many tools have overlapping purposes (e.g., tap_element vs tap, get_elements vs get_screen_tree vs get_screen_xml, screenshot variants, OCR variants, app listing tools, and CRM lookup tools). Even with descriptions, an agent may struggle to select the correct tool.
Naming Consistency3/5Mostly snake_case verb_noun, but there are bare verbs (swipe, tap, wait), noun-only names (device_health, app_state, screen_recording_status), and inconsistent prefix usage (crm_lookup_contact vs lookup_lead). The pattern is readable but not fully consistent.
Tool Count1/566 tools is excessive for a single server, far beyond the typical 3-15 well-scoped set. This causes usability issues despite the broad domain.
Completeness3/5The server covers many mobile automation areas (UI, OCR, workflows, skills, crashes, CRM), but notable gaps remain—no direct app uninstall, no lead update/reply, no device setting controls. Agents can work around some gaps via workflows.
Average 3.8/5 across 66 of 66 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 468 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions that on iOS it performs the 'best available' browser/navigation back action, which hints at platform-specific behavior, but it does not explain what that action is, what happens if no back navigation is available, or any side effects. This is insufficient for a tool that affects device state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point without unnecessary words. It covers the action and platform nuance efficiently. However, it is terse and could incorporate more detail on parameters or behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and the presence of an output schema, the description does not need to detail return values. However, with no annotations and a sparse description, the tool lacks critical context such as what happens on unsupported platforms, error conditions, and how this differs from the sibling 'browser_back.' The description is minimally viable but leaves significant gaps for an agent to operate reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'device' parameter at all. The tool name and description imply the action is performed on a device, but there is no information about how to specify the device (e.g., ID, format, or how to obtain it). The parameter is essentially undocumented, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Press Back' and clarifies the target platform ('Android' or 'iOS'), distinguishing it from generic actions. It mentions 'browser/navigation back action,' which hints at its scope. However, it does not explicitly differentiate from the sibling tool 'browser_back,' leaving some ambiguity about which tool to prefer for browser-specific scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'browser_back' or 'press_home.' It states what the tool does but does not mention prerequisites, exclusions, or contexts where another tool would be more appropriate. The phrase 'best available' implies some decision-making, but no clear selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the navigation action and does not disclose side effects, state changes, or behavior when no history exists. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It is front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool itself is simple, the description lacks context about the parameter and alternatives. It doesn't clarify the difference between browser navigation and system back, and doesn't mention the output or error behavior, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a required 'device' parameter with no description (0% coverage). The description does not explain what 'device' means or how it relates to the action, leaving the agent without enough information to correctly provide the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Navigate back') and identifies the scope ('current browser/app context'), making it clear what the tool does. However, it doesn't explicitly distinguish from the sibling 'press_back', which might also navigate back, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives like 'press_back' or 'tap_element'. The description gives no context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully explain behavior. It discloses that it checks health and includes recovery steps, but it is unclear whether 'recovery steps' are merely shown or executed, and whether the tool has side effects or requires special permissions. This ambiguity is significant for a diagnostic tool, especially when a sibling tool (fix_device_health) suggests a separate fix operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the main action front-loaded in the first sentence. Every word earns its place, and there is no redundant filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema is present (so return values may be covered), the description lacks crucial context: what 'comprehensive' includes, whether it covers non-iOS platforms, and how it relates to fix_device_health. The tool's complexity and the presence of closely related siblings demand more behavioral and usage context, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'device' with zero description coverage (0%). The description does not explain what 'device' refers to (e.g., device ID, name, or serial) or provide any format hints. Since the schema provides no semantic meaning, the description fails to compensate, leaving the parameter effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') with a clear resource ('device health check') and adds scope ('comprehensive'). It also provides concrete examples (iOS Appium/WDA status, active session details, recovery steps), which helps distinguish it from siblings like fix_device_health. However, it doesn't explicitly name an alternative or contrast with similar tools like get_phone_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It mentions iOS specifics but does not state whether this is the go-to for diagnostics or when to prefer fix_device_health. Usage is implied at best, and no exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden. It merely says 'apply a recovery action' without disclosing any side effects, permissions required, or potential destructive behavior. For a tool that likely modifies device state, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's core function without wasted words. Every word earns its place, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter descriptions and no annotations, the description is incomplete. While an output schema exists, so return values don't need explanation, the description fails to explain the meaning of the parameters or the nature of the recovery action, making it insufficient for an agent to invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (device and issue) with zero descriptions, and the description provides no explanation of what these parameters mean. The description references device_health.recommended_fix but does not clarify what 'issue' or 'device' should contain, leaving the agent to infer from the sibling tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool applies a recovery action returned by device_health.recommended_fix, using the specific verb 'apply' and the resource 'recovery action'. It implicitly distinguishes itself from the sibling tool device_health, which recommends fixes, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used after obtaining a recommended_fix from device_health, but it does not explicitly state when to use it vs alternatives or any prerequisites. It provides clear context that the action comes from device_health, but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It reveals the platform-dependence caveat but does not describe error behavior, device handling, or what happens if the URL is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it structurally efficient. However, it omits parameter semantics, so it is somewhat under-specified despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema is present, likely covering return values, and the tool is conceptually simple. Still, the missing parameter explanation and lack of usage guidelines leave notable gaps for an agent, though not severe enough to be considered inadequate for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only required parameter, device, has no schema description and the tool description does not mention it. With schema description coverage at 0%, the description fails to compensate, leaving the parameter entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current browser URL, with a caveat about platform exposure. It is specific and unambiguous, but it does not explicitly differentiate from sibling browser tools such as open_url or browser_back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to prefer this tool over alternatives or when not to use it. The phrase 'when the platform exposes it' is a technical precondition rather than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic action and target, but with no annotations, it carries the full burden of behavioral disclosure. It lacks details on platform-specific behavior, prerequisites (e.g., screen must be on), side effects, or failure modes. This is minimal information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It is efficiently written with no unnecessary words. While it is short, it is not tautological and communicates the core operation clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, a short description might suffice, but the complete absence of parameter semantics and usage context makes it insufficient. The output schema exists, but the description does not reference any return value or behavior. The tool is not fully specified for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'device' parameter with no description, and schema coverage is 0%. The description provides no information about the device parameter, such as expected format, allowed values, or how it affects behavior. The description fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pull down') and clearly identifies the resource ('notification shade or iOS Notification Center'). This distinguishes it from sibling tools like get_notifications and clear_notifications, which perform different actions on notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention situations where get_notifications or clear_notifications would be more appropriate, nor any conditions or prerequisites. The usage context is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool opens a page and returns headlines/snippets, but does not mention side effects (e.g., navigating away from current app), device requirements, network usage, or behavior on failure. The 'smoke workflow' hint is vague and insufficient for understanding the tool's operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and gets to the point. The first sentence states the core functionality, and the second gives context. No filler or redundant phrasing. However, the brevity comes at the cost of missing critical information, so it is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, an output schema, and no annotations, the description is grossly incomplete. It neither explains the parameters' meanings nor the tool's overall workflow. The 'smoke workflow' reference is too vague. A tool with this complexity needs a much richer description to be safely and correctly invoked by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting parameters. It does not mention any of the 7 parameters (url, device, wait_s, bundle_id, max_articles, max_headlines, save_screenshots) or provide any hint about how they affect the tool's behavior. This is a major gap, as the agent is left with only parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Open a news page and return structured headlines plus article snippets.' This specifies the verb (open/return), resource (news page), and outcome (headlines + snippets). It is not explicitly differentiated from siblings like extract_articles, but the mention of 'iOS Chrome/WebDriver smoke workflow' provides some unique context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'This is the iOS Chrome/WebDriver smoke workflow exposed as a single tool.' This tells the agent this is intended for smoke testing on iOS Chrome via WebDriver. It does not offer explicit exclusions or mention alternatives, but the context is specific enough to guide when to use it.
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?
There are no annotations, so the description carries the full burden. It mentions waiting and returning text context but does not describe timeout behavior (despite a timeout parameter), failure conditions, polling semantics, or what 'visible text context' precisely includes. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the primary action. It is front-loaded with the core behavior and contains zero superfluous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no parameter descriptions, no annotations, and only a vague output description, the tool is underdocumented. The description does not address device selection, timeout outcomes, or the exact structure of the returned text context, so an agent cannot confidently invoke it in diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It implicitly explains 'text' (the text to wait for) but does not clarify 'device' or 'timeout' (units, semantics, or behavior). The description adds minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for text to appear and returns visible text context, identifying the core function with a specific verb and resource. However, it does not explicitly differentiate this from sibling tools like 'wait' or 'find_on_screen', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'wait' or 'find_on_screen'. It simply states what the tool does without indicating appropriate contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not mention potential failure modes, permissions, or behavior when the clipboard is empty. The output schema exists but the description adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action and subject. It contains no filler or redundant information, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is minimal but still incomplete. It lacks usage context, parameter explanation, and edge-case behavior. The output schema exists but does not compensate for the missing contextual guidance in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, 'device', with no description and 0% schema description coverage. The description does not explain what 'device' means, what values are accepted, or how it relates to the operation, leaving the agent without essential parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('clipboard text'), with scope ('from the device'). It is unambiguous and distinguishes from sibling tools like clipboard_set (set) and paste_text (paste).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as clipboard_set or paste_text. The description does not mention any context or exclusions, leaving 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic extraction intent but does not explain what 'likely' means, whether the page is modified, whether it scrolls, or what limitations exist. No safety or side-effect information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the primary function. It is front-loaded with the verb and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, minimal parameter documentation, and the presence of sibling extraction tools, the description is incomplete. It provides no usage context, parameter semantics, or expected output details beyond what an output schema might convey.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain the 'device' parameter or the 'max_items' parameter. The description only references 'current browser page,' which indirectly hints at 'device' but provides no explicit meaning or usage guidance for the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Extract' with a clear resource: 'likely visible article/headline candidates from the current browser page.' It distinguishes itself from sibling tools like extract_visible_text (general text) and read_news (news-specific) by focusing on article/headline detection in the current page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool over alternatives such as extract_visible_text or get_elements. No exclusions or alternative tools are mentioned, leaving the agent without guidance on selecting this tool in contexts where other extraction 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?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the action and that the result is saved as an MP4, but it does not mention error behavior if no recording is active, file destination, or any permissions/requirements. This is a minimal disclosure that leaves important behavioral aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the key action ('Stop') and provides a necessary detail ('save the MP4'). It wastes no words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description still lacks context about device identification, prerequisites, error conditions, and side effects. For a simple stop action, it covers the core function, but the absence of behavioral detail and parameter guidance makes it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'device' parameter, and the description does not compensate by explaining what 'device' refers to or its expected format. Since there is no parameter information in either the schema or the description, the agent has no guidance on how to provide this value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stop' and the resource 'device screen recording', then adds the outcome 'save the MP4'. This distinguishes it from sibling tools like start_screen_recording and screen_recording_status, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The mention of 'running device screen recording' implies a prerequisite, but there is no reference to sibling tools or conditions under which this should be called. The agent is left 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it returns a status, without mentioning edge cases, required permissions, or what the status values represent. It doesn't even explicitly confirm this is a read-only operation, though 'Return' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the action and resource. Every word contributes to the purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one parameter and an output schema, the description is minimal but not entirely inadequate. However, the absence of any usage context or parameter detail means the agent may not know valid device values or when to invoke this tool. The low complexity does not compensate for the lack of guidance and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'device' parameter beyond the input schema's bare type. It says 'for a device' but doesn't specify the expected format (e.g., from list_devices) or any constraints. With schema_description_coverage at 0%, the description fails to compensate for the missing parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with the resource 'active screen recording status' for 'a device', clearly distinguishing this from sibling tools like start_screen_recording and stop_screen_recording. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention typical scenarios, such as checking before stopping a recording, nor does it reference sibling tools or exclusions. The agent must infer usage context 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does reveal platform-specific mechanisms (WDA MJPEG via ffmpeg for iOS, adb screenrecord for Android), which adds useful context. However, it omits important behaviors such as output file handling, permission requirements, or that recording continues until stopped. Score 3 reflects partial coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear purpose sentence followed by platform-specific details. No wasted words, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context for a recording operation: how to stop recording (though sibling exists), where files are saved, device selection requirements, and potential side effects. The platform details are helpful but not sufficient for a complete operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'device' or 'filename' parameters at all. No guidance on device identifier format, filename defaults, or allowed values. This is a significant gap for a tool with only two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start recording the device screen' with a specific verb and resource, distinguishing it from siblings like stop_screen_recording and screenshot. The platform details reinforce the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like screenshot or stop_screen_recording. It mentions platform-specific implementation but does not suggest 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds a useful platform-specific limitation (iOS only returns configured/common bundle IDs verified through Appium), but does not mention other behavioral aspects like permissions, read-only nature, or response format beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the core purpose, and the second adds a relevant limitation. No redundant filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential details. The iOS limitation is an important caveat. However, it could be more complete by mentioning when to use it versus similar tools, and by elaborating on the device parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (device) with no description, and the description itself does not elaborate on this parameter. The name 'device' is somewhat self-explanatory, but with 0% schema coverage, the description should have provided at least a hint about what values are expected (e.g., device ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists installed apps, including human-readable names and package names/bundle IDs. However, it does not explicitly distinguish this from sibling tools like list_packages or search_apps, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only mentions an iOS limitation but offers no context about when to prefer this over list_packages or search_apps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists output fields and suggests a read-only use case, but the claim of 'all UI elements' conflicts with the interactive_only parameter default true, which likely filters results. With no annotations, the description carries the full burden but omits this filtering behavior, making it misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the main action, the second provides essential field names and usage context, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description fails to explain the required device parameter and misrepresents the element list scope due to the interactive_only filter. This creates ambiguity about how the tool actually behaves in default mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero descriptions (0% coverage), and the tool description does not mention parameters at all. The required 'device' and optional 'interactive_only' are completely unexplained, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all UI elements on the current screen as a JSON array' with a specific verb and resource, and distinguishes from siblings like get_screen_tree by focusing on a flat element list with specific fields. It also references tap_element() by idx, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Call this to understand the screen layout before acting,' providing clear context for when to use. It also shows how to use the output with tap_element(), but does not explicitly mention when not to use it or alternatives like get_screen_xml.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states a coordinate-based press and provides use cases, but doesn't disclose details like whether it validates coordinates or that duration_ms controls the press length. It is not misleading, just minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the action front-loaded. Every word serves a purpose—no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no parameter descriptions and no annotations, this description is too sparse. It lacks guidance on coordinate origin, duration defaults, and how it differs from tap. The use-case examples are useful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter details. It mentions 'coordinates' but doesn't explain x/y semantics, device usage, or duration_ms default. The agent gets no help understanding parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Long press at coordinates' with a specific verb and resource, and provides examples of use cases. It distinguishes from siblings like tap_element by focusing on the long-press gesture, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use it: 'for context menus, drag initiation, etc.' This gives clear context but doesn't provide exclusions or mention alternatives like tap for simple clicks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that the stream is not opened, and it describes platform-specific metadata reporting (iOS: WDA MJPEG URL/settings, screenshot fallback, unsupported Portal/WebRTC; Android: Portal/H264/screencap), which is valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The following sentences add focused platform-specific detail without fluff or repetition, earning their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose and platform behavior are well covered, and the presence of an output schema covers return-value details. However, the absence of parameter semantics and explicit usage guidance leaves gaps that could affect correct invocation, so it is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (fps, mode, device, quality). No meaning or effect of these parameters is provided, leaving the agent without sufficient information to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Return effective stream metadata without opening the stream.' It also differentiates from sibling tools by detailing platform-specific metadata (iOS vs Android), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without opening the stream' implies a lightweight use case, but no explicit guidance is provided on when to choose this tool over alternatives. There are no mentions of exclusions, prerequisites, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does (tap at coordinates) but does not disclose side effects, screen state requirements, coordinate origin, or error behavior. This is a minimal transparency level for an input-injection action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (tap at coordinates with two integer params), the description is nearly complete. It covers the essential semantic of pixel coordinates, though it omits coordinate origin and any return value context. Still, with an output schema present and a straightforward action, it is sufficiently comprehensive for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that x and y are 'exact pixel coordinates' on the device screen, adding meaning beyond the schema's bare integer definitions. However, it does not specify the coordinate origin (e.g., top-left), which leaves some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('tap') and the specific resource ('device screen'), and distinguishes itself from siblings like tap_element by emphasizing 'exact pixel coordinates'. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as tap_element or swipe. The description does not mention any prerequisites, exclusions, or contextual cues for when coordinate-based tapping is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It explicitly states the action (pause execution) and the duration (seconds), but does not mention whether the call blocks, can be interrupted, or any edge cases. For a simple delay, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action verb 'Pause'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is minimally complete. It does not cover edge cases or context, but the tool's simplicity reduces the need for extensive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, seconds, with no description (0% coverage), so the description must compensate. It mentions 'seconds' but does not explain the parameter's range, default, or behavior if omitted, leaving the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pauses execution for a fixed number of seconds, using a specific verb and resource. It distinguishes from conditional wait tools like wait_for_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wait_for_text, nor any exclusions or prerequisites. The description only states what it does, leaving usage implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it merely restates the action. It does not disclose side effects, permissions, reversibility, or what happens to app data. 'Force-stop' implies forceful termination but adds no deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It conveys the essential operation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists, the description lacks broader context such as device requirements, when to choose force-stop over other navigation actions, or potential outcomes. It is adequate for a simple operation but missing some surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'package' parameter by specifying it accepts Android package names or iOS bundle identifiers, which is valuable given the schema has no descriptions. 'Device' remains generic but is self-explanatory in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (force-stop/terminate) and the target (Android package/iOS bundle id), making it distinct from sibling tools like launch_app or app_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and no prerequisites or exclusions are mentioned. The description only states the action without 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?
The description lacks details about side effects, permissions, or potential risks of launching arbitrary intents. Since no annotations are available, this information gap is significant. Examples show usage but not behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single leading sentence and three practical examples that earn their place. No redundant text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and 0% schema descriptions, the description provides useful examples but misses the required device parameter and fails to explain return or error behaviors. It is adequate for common cases but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The examples illustrate the use of action, data, package, and extras parameters, but the required 'device' parameter is entirely unaddressed. With 0% schema coverage, this leaves a critical gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Launch a full Android intent' with a specific verb and resource. It also differentiates from the sibling tool launch_app by saying 'More powerful than launch_app()'. The examples further demonstrate the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions this tool against launch_app, providing a comparative usage guideline. However, it does not specify when NOT to use it or alternative tools for specific intents, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about how key names are transformed (KEYCODE_ prefix) and platform support, but it does not describe return values, error conditions (e.g., unsupported iOS keys), or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and uses clear structure to separate Android and iOS behavior. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two-parameter schema, no annotations, and presence of an output schema, the description is reasonably informative but missing some context: it does not mention what the tool returns, how errors are surfaced, or whether this tool should be preferred over the dedicated press_back/press_home siblings for specific use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'key' parameter by listing accepted formats on Android and iOS, but it does not explain the 'device' parameter (e.g., device ID or name). Partial compensation is provided, but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a platform key event, with a specific verb and resource. It is distinguishable from sibling tools like press_back and press_home by covering generic keys, but it does not explicitly differentiate itself from those dedicated key-press tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the platform-specific key names (Android KEYCODE_* and iOS HOME/ENTER/BACK), but there is no explicit guidance on when to use this tool versus the dedicated press_back/press_home alternatives. The description does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that it runs a workflow on the device, without disclosing side effects, blocking behavior, permission requirements, or failure semantics. This is a significant gap for a tool that executes code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear one-line summary, an actionable prerequisite, and two illustrative examples. Every sentence contributes value, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values need not be described. The description covers how to identify available workflows and how to pass parameters with examples. It is fairly complete for a tool of this complexity, though it could mention error cases or confirm device identification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must compensate. It does so with two concrete examples showing order and format, and explains that params is a JSON string of keyword arguments. It also points to list_skills() for available skills/workflows. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an installed skill workflow on the device, with a specific verb and resource. It also directs users to call list_skills() first, which adds context about the resource type. However, it does not explicitly differentiate from sibling tools like run_flow or run_action, which could overlap in 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a prerequisite (call list_skills() first) and examples, which implies when to use the tool. However, it lacks explicit guidance on when not to use this tool versus alternatives like run_flow or run_action, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses core behaviors: it launches the app, taps interactive elements, builds a state graph, and returns JSON. However, with no annotations provided, it omits important operational details such as potential side effects on app state, duration, or that tapping may trigger irreversible actions. This is a moderate level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, each serving a distinct purpose: purpose, method, output, and usage. It is well front-loaded with the main verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the what, how, output, and typical use, and the presence of an output schema covers return details. However, for an autonomous tool that launches and interacts with an app, it lacks warnings about side effects or guidance on controlling exploration via max_depth/max_states, making it incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has zero coverage of the four parameters (device, package, max_depth, max_states). It neither mentions nor explains them, leaving only the property names and defaults to convey meaning. Since schema coverage is 0%, the description must compensate and fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Explore an app's UI autonomously using BFS.' It clearly explains the workflow (launches app, taps elements, builds state graph) and distinguishes itself from sibling UI inspection tools by emphasizing the autonomous exploration and output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage scenario: 'Use this to understand an unfamiliar app before writing automation for it.' This gives clear context for when to use it, but it does not mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose one behavioral trait: browser chrome is filtered by default, which is useful context. However, it does not explain what constitutes 'visible text', how max_lines affects output, or error behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core action and a key behavioral nuance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which likely covers return values, but the description does not mention prerequisites (e.g., needing a device from list_devices) or provide details on parameter interactions like max_lines. For a simple tool, it is minimally adequate but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The mention of 'browser chrome filtered by default' indirectly informs the include_controls parameter, but device and max_lines are not described. The schema itself provides no descriptions, so this is insufficient for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Extract visible text from the current screen' with a specific verb and resource. It also distinguishes itself from siblings by noting 'browser chrome filtered by default', which differentiates it from raw screen-tree or OCR tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get visible text from the current screen), but does not explicitly mention alternatives or when not to use it. With siblings like ocr_screen, get_screen_tree, and get_elements, explicit guidance would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return format, which is useful, but doesn't explicitly state that the operation is read-only, nor does it mention potential side effects, permissions, or error conditions. The read-only nature is somewhat implicit from the verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and return format without any wasted words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description omits any explanation of the required 'device' parameter. While the return format is given, the missing parameter guidance and lack of any usage conditions make the description incomplete for a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'device' parameter with no description (0% schema coverage). The description does not mention this parameter, its purpose, or how to specify it. This is a significant gap because the device identifier is essential for using the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get active notifications') and the resource, with a specific return format ('JSON array of {package, title, text}'). This distinguishes it from sibling tools like open_notifications and clear_notifications, which are write or navigation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading notifications but provides no explicit guidance on when to use it versus alternatives like open_notifications or clear_notifications. No prerequisites or conditions are mentioned, so the usage context is only implied.
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?
There are no annotations, so the description bears full responsibility for disclosing behavioral traits. It only mentions calling list_skills first, but does not disclose potential side effects, permissions required, or how errors are handled. Since the tool can execute arbitrary skill actions, the agent is left without warnings about possible destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded: the purpose is stated in the first sentence, followed by a necessary prerequisite and two illustrative examples. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description misses critical contextual information for such a powerful tool. It does not explain how to discover valid parameters for each action (beyond list_skills), how to format complex params, or any caveats about state changes. The agent would likely need to rely on trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the examples illustrate the argument order (device, skill, action, params) and that params is a JSON string. However, it does not define what a skill or action is, nor does it explain the meaning of 'device' or the params format beyond the examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Run a single skill action on the device,' which clearly states the verb ('run') and resource ('skill action'). The word 'single' differentiates it from sibling tools like run_workflow or run_flow, which likely execute sequences of actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Call list_skills() first to see available actions,' which is an explicit prerequisite for using the tool. However, it does not mention alternatives or situations where this tool should not be used, such as when a workflow would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: it uses XML heuristics rather than an LLM, implying speed and a rule-based approach. Yet it omits potential failure modes, limitations, or side effects, though the output schema may cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the core purpose, then a behavioral note, and finally a usage cue. Every sentence earns its place with no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and has an output schema, so return value details are unnecessary. The description covers purpose, usage, and a key behavioral aspect. The main gap is the missing parameter explanation, but that is already penalized under parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the single required parameter 'device,' and the description never mentions it. The description adds no semantic meaning beyond the schema's parameter name, leaving the agent to infer what value to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies the current screen into app, screen type (home, search, profile, settings, dialog, error, loading), and keyboard state. It also differentiates from siblings by noting 'No LLM needed' and 'uses XML heuristics,' which sets it apart from OCR or accessibility-tree-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for quick state checks before deciding what action to take,' providing a clear use case. However, it does not mention specific alternatives or when not to use it, leaving the guidance slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is raw identifiers rather than display names, which is useful behavioral context. However, it does not explicitly state that the operation is read-only or describe any error conditions, though 'list' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the primary action stated first and the alternative guidance second. There is no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the core purpose and provides an alternative. However, it omits any explanation of the device parameter and any prerequisites for use, such as needing a device identifier from list_devices, leaving a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, device, with no description, and the schema description coverage is 0%. The tool description does not explain what 'device' refers to or how to obtain valid values, leaving the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists raw Android package names or iOS bundle ids, using a specific verb and resource. It also distinguishes from list_apps by noting that list_apps should be preferred for display names, which clarifies 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Prefer list_apps() for display names' explicitly names an alternative tool and gives a criterion for choosing between them. This tells the agent when to use this tool (when raw identifiers are needed) and when to use a sibling (for display names).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the action and its result, providing a transparent behavioral contract. It does not discuss edge cases or side effects, but for a simple button press, the disclosed behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no filler. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits an explanation of the 'device' parameter and does not mention any usage context beyond returning home. While an output schema exists, the lack of parameter semantics and usage guidance leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'device' with 0% description coverage. The description does not explain what 'device' refers to or how to specify it. The parameter name suggests it is the target device, but the description does not compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Press') and resource ('the platform Home button'), clearly distinguishing it from siblings like press_back or tap_element. It also explains the outcome ('Returns to the home screen'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user wants to return to the home screen, but it does not explicitly discuss when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral details: 'Coordinates are in device pixels' and 'Returns base64-encoded JPEG.' However, it omits coordinate origin/order (top-left vs bottom-right), bounds validation, and implications for the 'device' parameter, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff: action, coordinate system, use case, and return format. It is front-loaded with the main purpose and each sentence adds value. The parenthetical examples make the use case concrete without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the core need: what it does, when to use it, coordinate units, and return format. However, it is not fully complete because it leaves the 'device' parameter undefined and does not clarify how the coordinate pair defines the region, which could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that coordinates are in device pixels, giving some meaning to x1/y1/x2/y2, but it does not define what the coordinate pairs represent (e.g., top-left and bottom-right corners) and does not explain the 'device' parameter at all. This is a significant gap for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Take a screenshot of a specific region of the screen.' This specific verb+resource phrasing distinguishes it from siblings like 'screenshot' (full screen) and 'screenshot_annotated' (annotated) by emphasizing the cropped region and 'zoom in' use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Use this to zoom in on a specific area (e.g., a form field, a notification, a chart).' It does not explicitly mention alternatives or when not to use it, but the guidance is sufficient for a focused screenshot tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains that the tool dismisses visible notifications and sets a precondition regarding a 'clear control', but it does not disclose what happens if no control is exposed, whether all notifications are dismissed, or any permission requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the core purpose and a key condition. It is front-loaded and contains no unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the essential action and condition. It could be more complete by clarifying what 'clear control' means or specifying the device parameter, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description does not mention the 'device' parameter at all. The param name is self-explanatory to a degree, but there is no explicit statement about what values it expects or how it is used, leaving the agent to infer its meaning from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Dismiss') and resource ('visible notifications'), and adds a distinguishing condition ('when the platform exposes a clear control'). This separates it from sibling tools like get_notifications (read-only) and open_notifications (opens the shade), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use ('when the platform exposes a clear control'), implying that it should be used only when such a control exists. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what the tool returns (app, activity, keyboard state, focused element) and implies a lightweight read-only operation, but it doesn't explicitly mention permission requirements, side effects, or the structure of 'focused element.' Since the tool name and description strongly suggest a read-only getter, a neutral score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly written, with the core purpose in the first sentence and a valuable use-case clarification in the second. Every word earns its place, and the structure front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so return values are covered. The description explains what the tool returns and when to use it, covering the core functional context. However, the parameter semantics are omitted, and the 'focused element' part could be ambiguous without further detail, holding it back from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'device' with no description (coverage 0%), and the tool description does not mention the parameter at all. The agent is left to infer that 'device' refers to a device identifier from context, which is likely but not explicitly explained. The description adds no semantic value beyond the bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly states the resource: 'current app, activity, keyboard state, and focused element.' It also distinguishes itself from sibling tools like get_elements and get_screen_tree by framing itself as a 'quick way to check what app/screen the device is on without parsing full elements.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it's the go-to for a quick state check without parsing the full element hierarchy. It doesn't explicitly name sibling alternatives or state when not to use it, but the phrase 'quick way' and 'without parsing full elements' effectively communicates the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the dependency on get_elements() and the action of tapping, but does not mention error handling, out-of-bounds behavior, or UI wait conditions. This is adequate for a simple action but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no fluff. Every sentence earns its place by explaining both the action and the prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tap action with an output schema present, the description covers the core workflow (call get_elements, then tap by index). It lacks details about edge cases and the device parameter, but is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'idx' comes from get_elements(), giving some meaning, but the required 'device' parameter is entirely unexplained, leaving a significant gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool taps a UI element by its index from get_elements(), using a specific verb and resource. It distinguishes itself from sibling tools like 'tap' by specifying the index-based method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the user to call get_elements() first to obtain indices, providing a clear prerequisite. However, it does not explicitly contrast with alternative tapping tools like 'tap' (which may use coordinates), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does communicate the three-state check (installed, running, foreground) which is useful, but it does not mention return format, platform differences, error behavior, or whether it performs any implicit device checks. This is adequate but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the verb and includes all essential information. No filler or redundant phrases; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple query tool with only two required parameters and an output schema present, so the description does not need to explain return values. It covers the core behavioral scope and package semantics well. Missing minor contextual details like platform support nuances, but overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'package' can be either an Android package or iOS bundle id, which adds meaning beyond the schema. However, the 'device' parameter is left unexplained, and there is no detail about accepted formats or how to specify the device. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check whether') and names the exact resource ('Android package or iOS bundle id') and the three queried states (installed, running, foreground). This clearly distinguishes it from sibling tools like launch_app, force_stop, and list_apps, which manage or enumerate apps rather than report their runtime state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying app state, and the context of sibling tools (e.g., launch_app, force_stop) makes the use case clear. However, it does not explicitly state when to prefer this tool over alternatives or mention any prerequisites such as a connected device or platform limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the core action (setting clipboard text) but does not disclose prerequisites, side effects, or failure conditions. It is adequate but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and followed by a practical tip. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation and the existence of an output schema, the description covers the essential purpose and a key usage pattern. It doesn't mention device prerequisites or edge cases, but for a clipboard setter it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The wording 'clipboard text' maps to the 'text' parameter and 'on the device' maps to 'device', giving basic semantic meaning. However, it does not explain valid formats, constraints, or how to obtain a device identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set clipboard text on the device.' It identifies the verb 'set', the resource 'clipboard text', and the scope 'device', distinguishing it from sibling tools like clipboard_get (read) and type_text (direct input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage context: 'Use with press_key(PASTE) to paste into fields.' This tells the agent a common workflow, though it does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly signals a read-only listing operation ('List') and scope ('all installed'), which is useful. However, it does not mention any potential side effects, permissions, or parameter-dependent behavior such as what 'supported_only' does. Some context is added, but the description could be more transparent about the tool's filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: the first states the action, the second explains the discovery purpose, and the third gives a clear usage preference. Each sentence adds value, and the description is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity listing tool with an output schema, the description covers the core purpose and usage guidance well. However, it omits parameter semantics (device and supported_only) and does not mention how these affect the result. With the output schema present, return format is covered, but the lack of parameter clarity leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 0% description coverage. The description fails to explain the 'device' parameter and only vaguely hints at filtering through 'platform support', which could relate to 'supported_only' but is not explicit. Since the schema provides no descriptions, the description should compensate but does not meaningfully do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists installed mobile automation skills with specific attributes (actions, workflows, platform support). This distinguishes it from raw interaction tools and other listing tools like list_apps by focusing on skills and the context of high-level automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs when to use: to discover available high-level automations. It also provides an actionable preference rule: use run_workflow() instead of raw tap/swipe when a skill exists. This goes beyond generic descriptions and gives clear guidance on when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses case-insensitive matching and that the return value includes Android packages or iOS bundle IDs. The example reveals the output shape. It doesn't mention side effects, but this is a search operation, and the behavior described aligns with a safe read-only tool. Missing details like what happens on no match are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, with no fluff. It is front-loaded with the purpose and provides a concrete output example that aids understanding. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return format is covered. However, the description does not explain the required 'device' parameter, and the example mismatches the schema's required two parameters. This incomplete parameter guidance makes the description only partially adequate for a 2-parameter tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. The example clarifies 'query' as the app name, but the 'device' parameter is never explained and the example even omits it, despite being required. This is a notable gap and could mislead an agent into calling the tool with only one argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches installed apps by name, with a specific verb and resource. The example with TikTok and its package/bundle ID makes the purpose unambiguous and distinguishes it from list_apps (which would list all apps) and launch_app (which launches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to find a specific app by name, use search_apps. It does not explicitly mention alternatives like list_apps for enumerating all apps, but the search-by-name behavior makes the intended context clear. No exclusions are stated, but the example provides a concrete use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds contextual behavior by indicating the gesture is used for scrolling and notifications, but does not disclose other behavioral aspects such as speed, sensitivity, edge cases, or return values. For a simple swipe gesture this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus two example lines. It is front-loaded with the core action and immediately gives practical usage patterns. Every sentence earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple gesture tool with an output schema, the description covers the primary usage and provides actionable examples. It misses documentation of duration_ms and any error/edge-case behavior, but the tool's simplicity and existing examples make the description reasonably complete. The output schema likely covers return values, so the description need not explain those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema has no descriptions, so the description must compensate. It provides concrete examples showing how x1, y1, x2, y2 map to start/end points (e.g., scroll down vs up), giving meaning beyond the raw schema. However, it does not explain the duration_ms parameter or define the coordinate system/units, leaving some parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a swipe gesture from (x1,y1) to (x2,y2), which is a specific verb+resource combination. It distinguishes itself from siblings like tap or long_press by specifying the swipe action and coordinates. The examples further clarify intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for scrolling, pulling down notifications, etc.' and provides common patterns for scroll up/down, giving the agent clear guidance on when to invoke this tool. It does not explicitly mention when not to use it or provide alternative tool names, but the guidance is sufficient for the intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it reveals the input format, supported actions, iOS-specific parameter handling, and side effect of writing elements files (elements_ios.yaml/elements.yaml). It does not mention overwrite behavior or error conditions, but the disclosed details are substantial. Minor confusion around app_package vs ios_bundle_id in iOS case slightly detracts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a purpose sentence, a JSON example, supported actions, iOS handling, optional elements, and a follow-up command. It is somewhat long but every part provides necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and platform nuances, the description covers key aspects: creation, step format, action types, iOS platform handling, optional element maps, and the replay workflow. It omits details about return values, but the presence of an output schema reduces that need. Missing overwrite or error behavior prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains the `steps` parameter with an example, and gives meaning to `platforms`, `app_package`, `ios_bundle_id`, `elements_ios`, and `elements_android`. However, `name` is never described, and the wording 'either app_package or ios_bundle_id' is ambiguous given that `app_package` is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new reusable skill from a JSON list of recorded steps.' It clearly distinguishes from siblings like run_workflow (replay) and draft_skill, and provides a concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool (creating skills from recorded steps) and explicitly instructs the follow-up: 'After creating, use run_workflow(dev, name, "recorded", params) to replay it.' It also gives platform-specific guidance for iOS. However, it does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states the tool is read-only and describes the returned data categories, which is helpful. However, it omits potential error conditions, permission requirements, and any data freshness caveats, making it only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The return information is captured in a compact bullet-like list, and the Args section is clearly structured. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema exists), the description covers the essential aspects: purpose, parameter format, and return categories. It lacks explicit error handling or use-case differentiation, but those are less critical for a focused lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name and type with no description. The description compensates fully by explaining the 'handle' parameter in the Args section, including the useful detail that it can be used with or without '@'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('stored fact sheet'), and the target ('one local CRM contact by handle'). It distinguishes from sibling tools like lookup_lead by explicitly scoping to local CRM contacts and their fact sheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need a contact's fact sheet by handle. However, there is no explicit when-not-to-use or any mention of alternatives such as lookup_lead or crm_list_unread_messages, leaving room for confusion in a large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that on iOS it uses Appium/WDA and defaults to a configured browser bundle id, which adds transparency. It does not mention all behaviors (e.g., Android handling or if it waits for page load), but for a simple open-URL tool, it provides meaningful context beyond a bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and adds a concise platform-specific note. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the main context: what it does, iOS-specific behavior, and default bundle id. The presence of an output schema reduces the need to explain return values. It lacks Android specifics, but overall it is reasonably complete for this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only indirectly references bundle_id ('defaults to the configured browser bundle id') and gives no explicit meaning for device or url. The url property is somewhat obvious from the tool name, but device and bundle_id remain under-explained, leaving the agent to infer or guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open a URL in the platform browser.' It uses a specific verb ('Open') and resource ('URL'), and adds platform context. This distinguishes it from sibling tools like launch_app or web_search, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to open a URL in the browser. It also gives platform-specific details (iOS uses Appium/WDA, default bundle id). However, it does not explicitly mention alternatives or when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the overlay behavior, the connection to get_elements(), and the base64-encoded PNG output. However, it does not mention potential prerequisites (e.g., accessibility permissions) or failure modes, but for a screenshot tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding meaningful information: action, element-index correspondence, usage guidance, and return format. There is no redundant or vague wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an output schema, the description covers the core functionality, usage, and output format. The missing explanation of 'device' is a notable gap, but overall the tool is simple enough that the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'device' with zero description, and the description does not clarify its meaning or possible values. Since schema coverage is 0%, the description should have compensated, but it does not, leaving the agent uncertain about what 'device' refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Take a screenshot with numbered element labels overlaid on interactive elements.' It also distinguishes itself from sibling tools like 'screenshot' by explaining the labels correspond to get_elements() indices, making it unique and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this when you want to SEE the screen with elements visually labelled.' It indicates when to use the tool, though it does not explicitly mention alternatives or exclusions, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the observable effect ('interactive elements get visible numbered labels') and the relationship to get_elements() indices. It does not mention side effects or persistence, but for a reversible toggle this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, followed by behavioral detail and use cases. Every sentence adds value with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description covers the purpose, effect, and appropriate use cases. The existence of an output schema means return values need not be explained. Minor gaps include parameter semantics and potential prerequisites, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not explain the 'device' or 'visible' parameters at all, though the names are somewhat self-explanatory and the phrase 'when on' hints at the visible flag. This is inadequate compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Toggle the numbered element overlay') and the resource ('on the device screen'). It further specifies the overlay's behavior (numbered labels matching get_elements() indices), which uniquely distinguishes it from siblings like screenshot_annotated or get_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear use cases: 'visual debugging or when sending screenshots to a vision model.' This gives context on when to use the tool, though it does not explicitly mention alternatives or exclusions. The guidance is sufficient for a simple toggle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Nothing is written', making the side-effect-free nature clear. It also discloses the return contents (steps, app_package, summary) and instructs the user to review/prune/rename, which adds behavioral context beyond a simple 'draft' label. Missing details like error handling or prerequisites prevent a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main action, and every sentence adds value: purpose, return value, and side-effect/next-step. No filler or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter, no annotations, and an output schema, the description provides a solid overview of functionality, side effects, and next steps. It lacks a bit of context about what a 'HARD skill' is and assumes the agent knows the workflow, but overall it is complete enough for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the only parameter 'device'. The description mentions 'device's most recent chat conversation', which gives some context that the parameter identifies the device, but it does not explain the expected format (e.g., device ID vs name). Since the parameter name is self-explanatory, baseline would be 3; the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'distil' and clearly identifies the resource: the device's most recent chat conversation, output as draft replayable steps for a HARD skill. It distinguishes from sibling save_skill by stating 'Nothing is written' and pointing to save_skill as the subsequent step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the workflow: generate draft steps with this tool, then call save_skill(kind="hard", steps=...). This effectively tells the agent when to use it (before saving a skill) and implies the alternative (save_skill) is for the actual saving. However, it does not explicitly state when not to use it or mention edge cases like no conversation history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a solid job. It discloses the coordinate system ('device pixels'), the output format (JSON array of objects with fields), and that results are 'relative to the crop region.' It doesn't address potential side effects or edge cases, but for a read-only OCR operation this is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short sentences, each adding distinct value: purpose, advantage, and output format. There is no redundant or filler content, making it both concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the essential aspects: what it does, the coordinate system, a performance note, and the exact output structure. The output schema also exists to detail the return value. Missing are edge cases like coordinate bounds or error handling, but these are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no per-parameter descriptions (0% coverage), so the description must compensate. It adds 'Coordinates in device pixels,' which gives the unit but not the exact meaning of x1, y1, x2, y2 (e.g., bounding box corners). The 'device' parameter is left to the context of sibling tools. This is partially helpful, but not fully clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb-object pair: 'OCR a specific region of the screen.' It distinguishes itself from the sibling tool 'ocr_screen' by explicitly targeting a region, and the additional note 'More accurate than full-screen OCR' further clarifies its unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides usage guidance by stating it is 'More accurate than full-screen OCR for targeted text extraction,' which tells when to prefer this tool over an alternative (ocr_screen). However, it doesn't explicitly mention when not to use it or list other alternatives, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses platform-specific behavior, the fact that no package/bundle ID is required, and the self-timer snapping behavior (e.g., ASUS/Samsung values). This provides meaningful transparency beyond the schema, though it doesn't cover side effects like permissions or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, platform note, then Args list. Every part is useful and avoids redundancy. It is somewhat long but appropriate for the complexity of the parameters, and the formatting improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all three parameters and provides platform-specific implementation details. With an output schema present, return values need not be explained. Missing edge cases like permissions or error handling are minor gaps given the scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains the device format (ADB serial or ios:<udid>), enumerates all mode values with their meanings, and describes timer_s supported values and snapping behavior in detail. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open the platform camera app in a specific mode,' which identifies the exact verb and resource. It differentiates itself from sibling tools like launch_app by specifying the camera app and modes, and the details of Android vs. iOS behavior further distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implementation context (Android launcher/UI automation vs iOS Camera bundle/WDA) and notes that no package or bundle ID is required, which indirectly implies how this differs from launch_app. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the two modes (hard/soft), the auto-distillation behavior when steps are omitted, and how soft skills are surfaced to agents. This goes beyond simply saying 'save' and provides meaningful behavioral context, though it does not mention potential overwrites or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the core purpose, and the second sentence efficiently explains both modes and related tools without any redundant phrasing. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behaviors for both hard and soft skills, references related tools, and clarifies the significance of steps and guidance. Given that an output schema exists, return values need not be described. Minor gaps remain around prerequisites (e.g., an active conversation) and naming conflicts, but the overall context is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to key parameters: it explains that steps is a JSON array from draft_skill, kind distinguishes between hard and soft, and guidance is markdown. This is valuable given the 0% schema coverage. Other parameters like name and device are self-explanatory, and app_package/description are left for inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Save the device's current chat conversation as a reusable skill.' This clearly differentiates it from sibling tools like create_skill, which implies creating a skill from scratch, and draft_skill, which is mentioned as a source for steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance for using hard vs soft modes and references draft_skill and list_skills/run_workflow as related tools. However, it does not explicitly compare save_skill with alternatives like create_skill, nor does it state when not to use this tool, so the guidance is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It adds valuable behavioral context by revealing platform-specific implementations and the 'when configured' condition for Android, which is not evident from the schema. However, it does not explain what happens if ADBKeyboard is not configured or other potential failure modes, so it is not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and front-loaded. The first sentence states the core purpose, the second provides platform-specific context, and the third gives an explicit alternative. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior for a simple typing tool, including platform differences and the focused-field requirement. However, the 'device' parameter is not explained, and there is no mention of error conditions or prerequisites beyond field focus. Since an output schema exists, return values are covered, but the parameter gap and limited edge-case disclosure keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. While 'text' is implicitly defined by 'Type unicode text', the 'device' parameter is not explained at all. The description fails to add enough semantic value for the device parameter, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: it types unicode text into the focused field. It distinguishes itself from the sibling tool type_text by explicitly recommending type_text() for plain ASCII, making its scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool versus alternatives. It explicitly says to use type_text() for plain ASCII, and it explains platform-specific behavior (Android with ADBKeyboard, iOS with WDA), helping the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that only the most recent crash is returned, the platform limitation, and the source (crash buffer). It does not explicitly state behavior when no crash exists, but overall provides good transparency for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and every sentence earns its place: purpose, platform limitation, and usage hint. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the core purpose, platform constraints, and suggested usage pattern. An output schema exists, so return values are likely documented. Minor gaps like edge cases (no crash) are acceptable and do not detract much from overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions, so the description must compensate. It explains 'package' as an optional filter, but 'device' is left undefined. The description adds some meaning for package but fails to clarify the required device parameter, which is a significant gap given 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full stack trace of the most recent crash from the crash buffer. It uses a specific verb and resource, and explicitly distinguishes itself from sibling list_crashes by focusing on the most recent crash and providing a detailed trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: it is Android-only (iOS not supported), tells users to pair with list_crashes to see what crashes exist, and mentions the optional package filter. This clearly indicates when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the output format, readability, and that it reflects the current screen, but does not explicitly state read-only semantics or prerequisites. The detail is sufficient for a non-mutating query, falling just short of fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: function, output format, and usage guidance. There is no redundancy or fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only UI hierarchy tool, the description covers purpose, output format, and usage context. It lacks parameter details and error scenarios, but the output schema and low complexity reduce the need for more, so it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the device parameter. While the parameter name is self-explanatory, the agent receives no guidance on valid values or how to specify the device, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets an LLM-friendly indented UI hierarchy, with a specific verb and resource. It also distinguishes itself from raw XML and get_elements(), making its purpose unambiguous relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to understand screen layout and pick which element to tap' and 'prefer this over get_elements() for planning.' This gives direct when-to-use guidance and names an alternative, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure responsibility. It implies a read-only operation via 'Get' and lists the data fields returned, but it does not explicitly state whether the operation mutates anything or how unknown handles are handled. Some behavioral context is added, but not rich detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a purpose statement, a use-case clause, a list of included data, and a parameter definition. Every sentence adds value with no unnecessary fluff, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers purpose, usage, parameter semantics, and output contents. It does not mention error behavior or end-of-life edge cases, but given the simplicity and the presence of an output schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'handle' parameter, and the description fully compensates by specifying the format (TikTok username, with or without @) and providing concrete examples. This is critical for correct invocation and clearly adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full fact sheet for one influencer lead by handle' with a specific verb and resource. It enumerates the included fields, distinguishing it from list-style tools like list_unread_leads or CRM lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you need to know everything about an influencer to draft a personalised reply or decide next-step outreach,' providing clear context for when to use it. However, it does not mention alternatives or when not to use, so it misses the 'when-not/alternatives' part for a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the underlying engine (RapidOCR), the output shape (JSON array of {text, conf, x, y, w, h}), and the sorting order. It does not explicitly state side effects or permissions, but the read-only nature is implied sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: action, use-case, and output format. Each sentence delivers unique information without redundancy, front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the tool's purpose, usage context, and output format. However, it omits any explanation of the 'device' parameter, which is the sole input and is also undocumented in the schema. Despite having an output schema, the description redundantly details the return structure, which is acceptable but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a required 'device' string with no description, and the description never mentions this parameter. With 0% schema coverage, the description should explain how to populate 'device', but it is completely absent, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'OCR the entire device screen using RapidOCR.' It clarifies scope ('entire device screen') and distinguishes from siblings like ocr_region and get_elements by explicitly contrasting with get_elements in the usage sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly states when to use this tool—when UI elements are rendered as images/canvas where get_elements() returns no text—and provides concrete examples (dashboards, games, WebViews). This is a clear directive that also implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it modifies the clipboard and performs a paste action into the focused field. It also notes the immediate timing and focus requirement. However, it does not mention potential side effects like clipboard overwrite or failure scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action. The equivalent-composition hint is efficient and adds clarity without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema, the description covers purpose, usage prerequisite, and behavioral essence. It is complete enough for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. The 'text' parameter is implicitly described as 'clipboard text', but the 'device' parameter is not addressed at all. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set clipboard text and immediately paste it into the currently focused field.' It further distinguishes from siblings by noting equivalence to clipboard_set + press_key(PASTE), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: 'Tap the target input field first to focus it, then call this.' It also implies an alternative (the two-step clipboard_set + press_key) but does not explicitly state when not to use it or mention other alternatives like type_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the screenshot is half-resolution JPEG, explains why a raw full-res PNG would overflow the MCP tool-result token cap, and quantifies the payload reduction (4-8x). It even notes a lasting fix is tracked. This is outstanding transparency about behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and front-loaded: the first sentence states the action and return value, the second gives a quick use case, and the third explains the compression rationale. Each sentence earns its place, though the parenthetical reference to 'feature #8' is slightly internal. Structure is clear and logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single required parameter, the description covers the core behavior, output format, and important performance constraints. Since an output schema exists, it need not detail the JSON structure. The only shortcoming is the missing parameter guidance, but that is already accounted for in the parameter semantics dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'device' with a string type in the schema and no schema description. The description's coverage is 0%, and the description itself never mentions the 'device' parameter, its meaning, or accepted values. Since the description must compensate for the schema gap, this is a significant omission, leaving the agent without guidance on what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Take a screenshot of the device screen' – a specific verb and resource – and immediately states the return type (base64-encoded JPEG). It clearly distinguishes this plain screenshot tool from siblings like screenshot_annotated and screenshot_cropped via the phrase 'shared compressed screenshot path'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to SEE what's on screen before deciding what to tap', giving a direct use case. It also explains the trade-off with token limits, which helps in selecting this tool over potentially richer alternatives. However, it does not explicitly mention when not to use it or name alternative tools for comparison, leaving a slight gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must carry safety/behavior disclosure. It does disclose the TTS engine, routing through Ghost portal, and Android-only nature. However, it omits whether the call blocks until speech completes, whether audio is audible on phone vs PC, and what happens if TTS is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short focused sections; every line earns its place—action, execution context, and parameter guide. No fluff and front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple TTS tool, description covers purpose, platform, execution path, and all parameters. Output schema exists so return details aren't required, but it doesn't mention timing/asynchronous behavior or fallback if TTS is missing—minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% descriptions, but description covers all three params with meaningful semantics: device as ADB serial/Android-only, text as content, rate with concrete examples (0.5 slow, 1.0 normal, 1.5 fast). This exceeds schema's bare names/types/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a clear action: 'Make the phone speak text aloud using its built-in TTS engine.' The verb+resource ('speak text' / 'phone') is specific and distinguishes it from sibling text input tools like type_text and paste_text. It also adds platform scope (Android-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: works from phone or PC and routes via Ghost portal, and states Android-only constraint. Doesn't explicitly name alternatives or when-not-to-use, but its use case is self-evident from the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the internal search strategy ('Searches XML elements first (fast), falls back to OCR if not found') and the return behavior ('Returns JSON with {text, x, y, w, h, method} or null if not found'). This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: four sentences, each adding value. It starts with the main purpose, then implementation detail, usage guidance, and return format. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description is complete. It covers purpose, usage, search method, return format, and null behavior. The existence of an output schema reduces the need to describe return values, yet the description does anyway for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description implies the 'text' parameter ('Find specific text') but does not explain the 'device' parameter at all. The agent is left to infer what 'device' means, making invocation potentially ambiguous. The description should at least mention that device targets the device.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find specific text on the screen and return its location.' It identifies the resource (screen text) and the specific action (find and return location), distinguishing it from sibling tools like get_screen_tree or ocr_screen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this to check if a button, label, or message is visible.' This tells the agent when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (logcat crash buffer), the no-root requirement, platform limitation, substring package filtering behavior, and the return JSON structure. This covers the key behavioral traits for a read-only list tool, though it could mention the meaning of 'recent' or whether ANRs are separate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the core function. Each sentence earns its place: function + source, platform caveat, filtering behavior, return format, and sibling pointer. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple listing operation, but the description covers source, platform, privilege, filtering, return schema, and the relationship to a sibling tool. It is sufficiently complete for an agent to select and invoke correctly, though it omits details about limit behavior and 'recent' timeframe, which are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly explains the package parameter ('substring match on the crashing process'), adding valuable detail. However, limit and device are not described, though device is self-explanatory and limit defaults to 10. The description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'List recent app crashes and ANRs' with a specific data source and privilege level ('from the logcat crash buffer, no root'). It also distinguishes itself from the sibling tool get_crash, which is referenced for pulling a full stack trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly restricts usage to Android ('Android-only') and explains iOS logs are not exposed, providing a clear when-not-to-use scenario. It also points to get_crash() as an alternative when a full stack is needed, making the choice between list and detail tools explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses spaces support, non-ASCII transliteration, and the adb ASCII-only limitation. However, it does not state what happens if no input field is focused, which is a minor behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: main action first, then prerequisite, then limitation and alternative. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, usage prerequisite, limitation, and alternative for a simple tool with an output schema. It misses explaining the 'device' parameter and possible error conditions, but overall it provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'text' parameter is well explained (accepts text, spaces supported, non-ASCII transliterated), but the 'device' parameter is not described. Since schema description coverage is 0%, the description should compensate for both parameters; it covers text but not device, so it is partially adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Type text') and its target ('the currently focused input field'). It also distinguishes from sibling tools, particularly type_unicode for full-fidelity emoji/CJK, and implies focus is a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Tap an input field first to focus it' and directs users to type_unicode for non-ASCII input, providing both a clear when-to-use and an alternative. This is strong guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description carries the burden with an explicit 'Read-only' disclosure and a 'local CRM' scope. It also details the output structure, giving clarity on behavior beyond safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It states the function, safety, and output format without any redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers all necessary aspects: purpose, sorting, read-only nature, and output fields. It is complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds useful context about the return fields and sorting, which more than satisfies the minimal requirements for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('local CRM contacts with unread messages') and adds sorting ('by recency'). It clearly distinguishes from siblings like crm_lookup_contact or list_unread_leads by focusing on unread message conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose and context explicit: it lists unread contacts, implying use when such a list is needed. However, it does not explicitly mention alternative tools or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the output is raw, normalized, and platform-specific (Android uiautomator vs iOS Appium/WDA). It does not explicitly state whether the operation is read-only, but the 'Get' wording and dump semantics imply a non-mutating snapshot, and the platform-specific detail adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the primary purpose and followed by platform details and usage guidance. Every sentence adds useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema (which likely documents the exact return structure), the description provides sufficient context: raw vs. readable, platform normalization, and when to use it. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, 'device', and the schema has 0% description coverage, meaning the description never mentions or explains the parameter. However, the parameter is self-explanatory from its type/name, and the description's 'from the device' implicitly references it. Still, the description adds no explicit parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Get the raw normalized UI XML dump from the device.' It clearly distinguishes the tool's output from get_screen_tree by noting it returns raw XML rather than a readable summary, and it also differentiates Android vs. iOS behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use get_screen_tree() instead for a readable summary' and 'Use this only when you need exact attribute values or the full hierarchy.' This clearly states when to use the tool and when to prefer an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains that it lists only connected Android ADB devices and configured iOS Appium devices, and that the output contains device serials. The read-only nature is implied by 'List' but not explicitly stated; however, for a listing tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the verb 'List,' and every word earns its place. It states what it lists and why to call it first, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, output schema exists), the description is complete. It explains the tool's purpose, the scope of devices, and the key output detail (device serial) needed for subsequent operations. The presence of an output schema means return-value details are already documented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description need not explain parameters, and it doesn't, which is appropriate. The empty schema is fully covered, and the description adds no parameter-related confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists connected Android ADB devices and configured iOS Appium devices, with a clear verb and resource. It distinguishes itself from sibling tools by being the device-listing entry point, explicitly saying to call it first to get the device serial needed for other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: 'Call this first' indicates when to use it as a prerequisite for other tools. It does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5, but the 'call this first' instruction is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides meaningful detail: sorted by recency, one row per unread conversation, and includes the specific fields returned. The read-only nature is implied by 'List' and 'Returns,' and no side effects are suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The first sentence states the action, the second explains the return format and use case. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters), has an output schema, and the description fully covers the output fields and intended usage. It provides enough context for an agent to select and invoke the tool correctly without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything trivially. The baseline of 4 applies, and the description adds no contradictory or missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List every influencer with an unread reply in the inbox, sorted by recency.' It identifies a specific resource (influencer inbox leads) and a distinctive scope (unread replies), differentiating it from sibling tools like crm_list_unread_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Useful for daily prioritisation: which leads should I respond to right now?' This clearly indicates when to use the tool, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details cold/warm start semantics: fresh=True force-stops and clears in-memory state (back stack, drafts, etc.), while fresh=False resumes existing instance. This reveals important side effects and behavioral traits beyond a simple launch action, though it omits other potential side effects like permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear first sentence establishes purpose, followed by a concise Args block. The fresh parameter's detailed explanation earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, provides usage examples, and addresses the fresh/cold-start edge case. Since an output schema exists, the lack of return-value explanation is acceptable. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (device, package, fresh) receive thorough descriptions: device format ('ADB serial or ios:<udid>'), package examples, and fresh's behavioral impact. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Launch an app by Android package name or iOS bundle id,' using a specific verb and resource. It clearly differentiates from sibling tools like launch_intent (which launches intents) and force_stop (which stops apps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Use search_apps() to find it,' providing a prerequisite/alternative for locating the package. It also explains when to use fresh=True (benchmarks, fresh flow start, or when current state interferes), but does not explicitly contrast with launch_intent or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the browser fallback chain (Chrome → Firefox → ... → system default), explains that the query is not pre-escaped, and mentions the default engine and optional bundle_id override. This adds meaningful behavioral context beyond what structured fields could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose, a usage/speed note, the fallback chain, and a concise Args list. Every sentence adds value—no redundancy or filler. The length is appropriate for the four parameters and behavioral nuances.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's complexity: it covers all four parameters, explains browser selection behavior, gives usage context, and even includes an example for bundle_id. Since an output schema exists, no return-value explanation is required. There are no obvious gaps that would leave an agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the Args section compensates fully by explaining each parameter: device format ('ADB serial or ios:<udid>'), query semantics ('Free-text search terms'), engine values ('google', 'ddg', 'bing', 'brave'), and bundle_id purpose ('Optional iOS browser bundle id override'). This is exactly the kind of clarification an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Open a web search in whatever browser is on the device.' It goes beyond a generic verb by specifying the resource (web search) and the mechanism (browser on device). It also distinguishes itself from related tools like launch_app or open_url by focusing on search queries and the 'search for X' use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Useful when the user asks "search for X" or you need to look up info that's not on the current screen.' It also compares the tool to a slower manual sequence (launch Chrome → tap address bar → type → submit), which helps the agent choose this over manual UI steps. It doesn't explicitly name sibling tools as alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals execution order, stop-on-first-error behavior, the single final screenshot return, the lack of auto-settling, the fail-closed allow-list security model, and the 50-step maximum. This goes far beyond a basic tool summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then efficiently details behavior, security, and limitations. The example is compact and illustrative. Every sentence adds meaningful information, and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers invocation format, return value shape, exception handling, concurrency concerns, security restrictions, and step limits. An output schema is present, so return-value details need not be repeated. It is complete enough for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type 'string' for both params with 0% description coverage, so the description must compensate. It thoroughly explains the `steps` parameter with format, allowed tool names, and a full example. However, the `device` parameter is only shown in the example ('SERIAL') without explicit explanation, leaving one parameter semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run an ordered batch of tool calls server-side in ONE round-trip.' This clearly distinguishes it from sibling tools like run_workflow or individual action tools, and the example reinforces its batch execution purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('far fewer tokens/round-trips than calling each tool separately'), provides a concrete example, and explains when to insert wait steps because 'Steps do NOT auto-settle between UI actions.' It also clarifies which tools are allowed and that unvetted tools cause refusal, giving strong usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ghost-in-the-droid/android-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server