Metro Logs MCP

Server Quality Checklist

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

Latest release: v1.0.32
Disambiguation3/5
The tool set has clear groupings (Android, iOS, React Native debugging, Metro connection, etc.) with distinct purposes within each group, but there is significant overlap between similar tools across platforms (e.g., android_describe_all and ios_describe_all) and between alternative methods (e.g., ocr_screenshot vs. accessibility-based tools). Descriptions help clarify, but agents may struggle to choose between overlapping options without deep domain knowledge.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern throughout, with clear verb_noun structures (e.g., android_tap, get_logs, scan_metro). Minor deviations exist, such as ocr_screenshot using an acronym prefix and some tools having longer names (e.g., toggle_element_inspector), but the overall naming is predictable and readable.
Tool Count2/5
With 64 tools, the count is excessive for a single server, making it overwhelming and difficult to navigate. While the domain (React Native debugging with Android/iOS support) is broad, many tools are redundant or highly specialized, leading to a bloated interface that could be streamlined without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for React Native debugging, including connection management, log retrieval, network monitoring, component inspection, and device interaction for both Android and iOS. It supports full CRUD-like operations (e.g., install/launch/terminate apps, input text, swipe/tap) and handles edge cases like error recovery and OCR alternatives, leaving no obvious gaps for the intended purpose.
Average 3.8/5 across 64 of 64 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 353 commits in the last 12 weeks
- Last stable release on August 25, 2026
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Install an APK' which implies a write/mutation operation, but doesn't mention critical behaviors like whether it requires specific permissions, if it's idempotent, potential side effects on the device, or error handling. The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's perfectly front-loaded and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, what the return value might be, or important behavioral aspects. The 100% schema coverage helps with parameters, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so all parameters are documented in the schema itself. The description doesn't add any additional parameter context beyond what's already in the schema descriptions, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and resource ('an APK on an Android device/emulator'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ios_install_app' or 'get_apps', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'ios_install_app' for iOS or 'get_apps' for listing installed apps. It also doesn't mention prerequisites such as having an Android device connected or the APK file available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't mention permissions needed, whether it requires an active device connection, what the output format looks like, or any rate limits. This leaves significant gaps for a tool that interacts with external devices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that interacts with Android devices/emulators with no annotations and no output schema, the description is insufficient. It doesn't explain what the output contains (package names, versions, etc.), doesn't mention connection requirements, and provides minimal behavioral context despite the complexity of device interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter information beyond what's in the schema, resulting in the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('installed packages on an Android device/emulator'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_apps' which might serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_apps' or 'android_describe_all'. It lacks any mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action but fails to describe key behavioral traits: it doesn't specify if this is a read-only or mutating operation (likely mutating as it interacts with the device), what happens if coordinates are invalid, whether it requires specific permissions, or any error conditions. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key information ('Long press at specific coordinates'), making it easy to parse quickly. Every part of the sentence serves a purpose, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a device interaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success/failure status, error messages), behavioral nuances like coordinate system origin or screen bounds, or how it integrates with sibling tools. For a mutating operation in a testing/automation context, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (x, y, durationMs, deviceId) with clear descriptions. The description adds no additional semantic meaning beyond implying coordinate-based input, which is already covered by the schema. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('long press') and target ('at specific coordinates on an Android device/emulator screen'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'android_tap' or 'android_swipe' beyond the 'long press' action, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'android_tap' (for quick taps) or 'android_swipe' (for gestures). It lacks context about typical use cases (e.g., opening context menus, dragging elements) or prerequisites (e.g., requiring an active device connection), leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the swipe action but fails to describe side effects (e.g., potential UI changes), error conditions (e.g., invalid coordinates), or performance characteristics (e.g., execution time). This leaves significant gaps for a tool that performs screen interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after the swipe (e.g., whether it waits for UI updates), error handling, or coordination requirements with other tools like ensure_connection. Given the complexity of device interaction, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('swipe') and target ('Android device/emulator screen'), specifying it moves from one point to another. It distinguishes itself from sibling tools like android_tap or android_long_press by focusing on swiping motion, though it doesn't explicitly differentiate from ios_swipe which serves a similar function on iOS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like android_tap or android_long_press, nor does it mention prerequisites such as needing an active device connection. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists simulators but doesn't describe what information is returned (e.g., names, UDIDs, states), whether it requires specific permissions or environment setup, or if there are rate limits or side effects. This leaves significant gaps for a tool that likely interacts with system resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('List available iOS simulators') without unnecessary elaboration, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns structured data about simulators. It doesn't explain the return format (e.g., list of objects with properties), error conditions, or dependencies, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'onlyBooted' parameter fully documented in the schema itself. The description adds no additional parameter semantics beyond implying a listing action, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available iOS simulators'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'list_android_devices' by specifying iOS simulators, but doesn't explicitly differentiate from other iOS tools like 'ios_boot_simulator' or 'ios_describe_all' beyond the listing function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing Xcode or a running simulator service), compare it to 'list_android_devices' for cross-platform scenarios, or indicate when filtering with 'onlyBooted' is appropriate versus other listing methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions case-insensitive matching, which is useful, but omits critical details: whether this is a read-only operation, how results are ordered or limited, potential performance impacts, or what the output looks like. For a search tool with 5 parameters and no output schema, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes a useful behavioral note (case-insensitivity). Every element earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is insufficient. It lacks details on output format, result structure, error conditions, or operational constraints. While concise, it doesn't provide enough context for an agent to confidently invoke the tool without guessing about its behavior or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond implying text search functionality. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance understanding of parameter interactions or use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search console logs for text (case-insensitive)'. It specifies the verb ('search'), resource ('console logs'), and a key behavioral trait (case-insensitive matching). However, it doesn't explicitly differentiate from sibling tools like 'get_logs' or 'clear_logs', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_logs' (which likely retrieves logs without filtering) and 'clear_logs' (which modifies logs), the agent receives no explicit or implied direction about appropriate contexts, prerequisites, or trade-offs for choosing this search function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'case-insensitive' searching, which adds some context, but fails to describe critical behaviors: whether this is a read-only operation, what the output format entails (especially 'tonl'), potential rate limits, or error conditions. For a search tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. There is no wasted verbiage, and it directly communicates the tool's purpose without redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of requests, details), how results are structured, or behavioral aspects like pagination or limitations. For a search tool with three parameters and no structured output documentation, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by implying the search is 'case-insensitive', which relates to 'urlPattern' behavior. However, it doesn't explain parameter interactions or provide additional semantic context, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search network requests by URL pattern (case-insensitive)'. It specifies the verb ('Search'), resource ('network requests'), and key constraint ('by URL pattern, case-insensitive'). However, it doesn't explicitly differentiate from siblings like 'get_network_requests' or 'get_request_details', which may offer similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_network_requests' or 'search_logs', nor does it specify prerequisites, exclusions, or appropriate contexts. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Clear' implies a destructive operation, but the description doesn't specify whether this is permanent, reversible, requires special permissions, or affects system performance. No rate limits, side effects, or response format information is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 3 words ('Clear the log buffer'), front-loaded with the core action, and contains zero wasted words. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'clear' means operationally, what happens to the cleared logs, whether the action is reversible, or what confirmation/response the tool provides. The context signals show this is a mutation tool in a system with many read-oriented siblings, making behavioral transparency particularly important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters, and it doesn't attempt to add parameter information beyond what's already covered by the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear the log buffer' clearly states the action (clear) and target resource (log buffer), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_logs' or 'search_logs' beyond the obvious action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get_logs' or 'search_logs'. The description doesn't mention prerequisites, timing considerations, or any context for when clearing logs is appropriate versus reading them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the mechanism ('via ADB') but doesn't disclose behavioral traits like output format (e.g., list of device IDs), potential errors (e.g., no devices found), side effects (e.g., none), or dependencies (e.g., ADB server running). This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('List connected Android devices and emulators via ADB') earns its place by specifying scope and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is minimal. It states what the tool does but lacks completeness for effective use: no output details, error handling, or integration context with siblings. For a tool in a complex Android/iOS testing environment, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate. Baseline is 4 for zero parameters, as no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resources ('connected Android devices and emulators') with the mechanism 'via ADB'. It distinguishes from siblings by focusing on device enumeration rather than interaction or inspection. However, it doesn't explicitly differentiate from 'list_ios_simulators' or other listing tools, keeping it at 4 rather than 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., ADB setup), timing (e.g., before device-specific operations), or exclusions (e.g., iOS devices). With many sibling tools for Android operations, this lack of context leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Send a key event' implies a write/mutation operation, it doesn't clarify if this requires specific permissions, whether it's reversible, potential side effects (e.g., app navigation), or error handling (e.g., invalid deviceId). The description lacks critical behavioral context for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a helpful list of common keys. Every sentence earns its place—no redundant or vague language. It efficiently conveys essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is minimally adequate. It covers the basic purpose and parameters but lacks details on behavioral traits, error handling, or return values. For a tool that interacts with devices, more context on prerequisites and outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by listing common key names (e.g., HOME, BACK) beyond the schema's generic 'Key name' description, providing practical examples. However, it doesn't explain the semantics of numeric keycodes or deviceId selection in depth, keeping it at a 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a key event') and target ('to an Android device/emulator'), providing a specific verb+resource combination. It distinguishes itself from sibling tools like android_input_text (for text input) and android_tap (for touch interactions) by focusing on key events. However, it doesn't explicitly differentiate from ios_key_event (its iOS counterpart), which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when key events are preferred over other input methods (like android_input_text for text or android_tap for touch), nor does it specify prerequisites (e.g., device must be connected). The list of common keys is helpful but doesn't constitute usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Clear' implies a destructive write operation that likely removes error data, but the description doesn't specify if this requires specific permissions, is irreversible, affects system state, or has side effects (e.g., resetting counters). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words—'Clear the bundle error buffer' directly conveys the core action and target. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete for its basic function. However, as a mutation tool with potential side effects, it lacks details on behavioral traits (e.g., what 'clear' entails operationally) and usage context, which could hinder agent effectiveness in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly avoids mentioning any. This meets the baseline for tools with no parameters, where minimal description is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear the bundle error buffer' clearly states the action (clear) and the resource (bundle error buffer), making the purpose unambiguous. It distinguishes from siblings like 'clear_logs' and 'clear_network' by specifying the target resource, though it doesn't explicitly contrast with them. The purpose is specific but lacks explicit sibling differentiation, warranting a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after detecting errors with 'get_bundle_errors'), exclusions, or contextual cues. Without any usage instructions, the agent must infer context from tool names alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Clear' implies a destructive operation, but it doesn't specify whether this is reversible, what permissions are needed, or what happens to the cleared data. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate but lacks context. It doesn't explain what 'network request buffer' refers to, what clearing entails, or how this interacts with other network-related tools, leaving gaps in understanding for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the lack of parameters, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clear the network request buffer' clearly states the action (clear) and resource (network request buffer), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like clear_bundle_errors or clear_logs, which perform similar clearing operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or relationships with sibling tools like get_network_requests or search_network, leaving the agent without context for appropriate 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 full burden for behavioral disclosure. It states the action ('Install') but doesn't mention potential side effects (e.g., overwriting existing apps), permissions needed, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. Every part of the sentence ('Install an app bundle (.app) on an iOS simulator') directly contributes to understanding the tool's function, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., what 'Install' entails operationally), error handling, or return values. While concise, it lacks the depth needed for an agent to fully understand the tool's context and implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('appPath' and 'udid') thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., file format requirements for .app bundles or UDID sourcing). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Install') and target resource ('an app bundle (.app) on an iOS simulator'), distinguishing it from sibling tools like 'android_install_app' (different platform) and 'ios_launch_app' (different action). It precisely communicates what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), exclusions (e.g., not for physical devices), or related tools like 'ios_boot_simulator' or 'get_apps'. Usage is implied by the action but not explicitly contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the IDB installation requirement, which is useful context about dependencies. However, it fails to describe critical behavioral aspects such as whether this operation is safe/read-only or destructive, what happens if the simulator isn't running, error conditions, or the expected response format. For a tool that interacts with simulators, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each serve a distinct purpose: the first states the core functionality, and the second provides a critical prerequisite. There's no wasted language, and the information is front-loaded with the primary action. This is an excellent example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with iOS simulators and the absence of both annotations and an output schema, the description is insufficiently complete. It mentions the IDB requirement but omits other critical context such as error handling, what constitutes valid keycodes, whether the tool waits for completion, or what the return value looks like. For a tool with no structured safety or output information, the description should provide more operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters ('keycodes' and 'udid') clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a sequence of key events') and target resource ('to an iOS simulator'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ios_key_event' (which likely sends single key events rather than sequences), leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning the prerequisite ('Requires IDB to be installed'), which is helpful for setup. However, it offers no guidance on when to use this tool versus alternatives like 'ios_key_event' or 'ios_input_text', nor does it specify scenarios where key sequences are preferred over other input methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('Launch') but doesn't disclose behavioral traits like whether it waits for app launch completion, handles errors if the app isn't installed, requires specific simulator states, or returns any output. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior (e.g., success/failure handling), prerequisites, and output expectations. Given the complexity of launching an app in a simulator environment, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (bundleId, udid) well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch') and target resource ('an app on an iOS simulator by bundle ID'), distinguishing it from sibling tools like ios_terminate_app or android_launch_app. It specifies the platform (iOS simulator) and mechanism (bundle ID), 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator or installed app), exclusions (e.g., not for real devices), or comparisons to siblings like ios_open_url. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return value ('Returns the image data that can be displayed') but doesn't address important behavioral aspects like whether this requires a running simulator, what happens if no simulator is available, error conditions, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that each serve a clear purpose: stating the action and describing the return value. There's no wasted text, though it could be slightly more comprehensive given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides basic purpose and return information but lacks important context about behavioral characteristics, error handling, and usage guidelines relative to sibling tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema. Baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and target resource ('from an iOS simulator'), distinguishing it from sibling tools like 'android_screenshot' and 'ocr_screenshot'. It provides a complete purpose statement with verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'android_screenshot' or 'ocr_screenshot'. It mentions the return value but gives no context about prerequisites, timing, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a prerequisite (IDB installation) which is useful context, but fails to describe what the tool actually does behaviorally—e.g., whether it simulates a swipe, returns success/failure, or has side effects like screen changes. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences: one stating the core purpose and another providing a critical prerequisite. Every word earns its place, and the information is front-loaded with no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive gesture simulation with 7 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on what the tool returns, error conditions, or behavioral outcomes, which are essential for an agent to use it effectively in a testing or automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as explaining coordinate systems or typical duration values. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Swipe gesture') and target ('iOS simulator screen'), which is specific and unambiguous. However, it doesn't explicitly differentiate from its sibling 'android_swipe' or other iOS gesture tools like 'ios_tap', missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning the prerequisite 'Requires IDB to be installed', which helps determine when this tool is applicable. However, it provides no guidance on when to choose this over alternatives like 'android_swipe' or other iOS interaction tools, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether termination is graceful or forceful, if it requires specific permissions, what happens to app state/data, error conditions, or side effects. 'Terminate' implies a destructive operation, but behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'terminate' entails behaviorally, what happens on success/failure, or return values. Given the complexity of app termination and lack of structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (bundleId and udid). The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('terminate') and target resource ('a running app on an iOS simulator'), distinguishing it from sibling tools like ios_launch_app or ios_install_app. It uses precise technical terminology (iOS simulator) that differentiates it from Android tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the app must be running), when termination is appropriate versus other actions like relaunching, or what happens after termination. No exclusions or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns image data, but doesn't describe important behavioral aspects: whether this requires device permissions, if it interrupts device operation, potential side effects, error conditions, or how the image data is formatted. The description is minimal and misses key operational context needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences. The first sentence states the core functionality, and the second explains the return value. No wasted words, though it could be slightly more structured by separating functional description from behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a device interaction tool with no annotations and no output schema, the description is incomplete. It doesn't address important contextual aspects: permission requirements, error handling, side effects on the device, image format details, or how the returned data should be handled. For a tool that interacts with physical/virtual devices, more operational context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (outputPath and deviceId). The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, default behaviors beyond what's in schema descriptions, or usage examples. Baseline score of 3 is appropriate when schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and target resource ('from an Android device/emulator'), distinguishing it from sibling tools like ios_screenshot (for iOS) and ocr_screenshot (which performs OCR). It explicitly mentions the return value ('Returns the image data that can be displayed'), 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a screenshot from Android devices, but doesn't explicitly state when to use this tool versus alternatives like ios_screenshot or ocr_screenshot. It mentions the deviceId parameter can come from list_android_devices, providing some contextual guidance, but lacks explicit when/when-not instructions or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention permissions required, error conditions (e.g., if app isn't installed), side effects, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the key action and method. It's appropriately sized for the tool's complexity, earning its place clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It lacks behavioral context, error handling, and output details, making it insufficient for an agent to understand the full implications of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying packageName is required, which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch') and target ('an app on an Android device/emulator'), specifying the method ('by package name'). It distinguishes from siblings like android_install_app (installs) or android_tap (interacts), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to start an app, but provides no explicit guidance on when to use this tool versus alternatives like android_install_app (for installation) or ios_launch_app (for iOS). It lacks context on prerequisites or exclusions, leaving usage somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool returns (statistics) but does not mention behavioral traits such as whether it requires specific permissions, if it's read-only (implied by 'Get'), how data is sourced (e.g., from a capture session), performance considerations, or error handling. This leaves gaps in understanding the tool's operation and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get statistics') and specifies the resource and details without unnecessary words. Every part of the sentence adds value, making it well-structured and concise for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is low (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects like data freshness, scope (e.g., time range), or format of returned statistics. Without annotations or output schema, more context on the return value would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose. This aligns with the baseline expectation for tools without parameters, where the description need not compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'statistics about captured network requests', with specific details about what statistics are included (counts by method, status code, and domain). It distinguishes itself from siblings like 'get_network_requests' (which likely lists individual requests) and 'search_network' (which likely filters requests) by focusing on aggregated statistics rather than individual records or search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when aggregated statistics about network requests are needed, but it does not explicitly state when to use this tool versus alternatives like 'get_network_requests' or 'search_network'. There is no guidance on prerequisites (e.g., whether network capturing must be active) or exclusions, leaving the context somewhat open-ended.
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 burden. It discloses that URLs open in 'default handler or Safari', which adds useful behavioral context beyond basic functionality. However, it doesn't cover potential errors, permissions, or simulator state requirements, leaving gaps for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Open a URL in the iOS simulator') and adds clarifying detail ('opens in default handler or Safari') without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is adequate but minimal. It covers the basic action and some behavioral context, but lacks details on return values, error conditions, or integration with sibling tools, making it functional but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., URL examples or UDID usage), meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a URL') and target ('in the iOS simulator'), specifying the verb and resource. It distinguishes from sibling tools by focusing on URL opening rather than app control or UI interaction, though it doesn't explicitly contrast with specific alternatives like 'ios_launch_app'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for opening URLs in the iOS simulator, but doesn't provide explicit guidance on when to use this versus alternatives like 'ios_launch_app' for deep links or other URL-handling methods. It mentions 'default handler or Safari' which gives some context but lacks clear when/when-not rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get') but doesn't disclose behavioral traits like whether it requires an active device connection, if it works on emulators vs. physical devices, potential errors, or return format. The description is minimal and misses key operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero redundant words. It's appropriately sized for a simple tool and front-loads the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., dimensions in pixels), error conditions, or dependencies like device connectivity. For a tool with potential operational nuances, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'deviceId' well-documented in the schema. The description adds no parameter-specific information beyond implying the tool targets Android devices/emulators, which is already clear from the tool name. With 0 parameters needing semantic clarification, a baseline of 4 is appropriate as the schema suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('screen size (resolution) of an Android device/emulator'), distinguishing it from siblings like android_screenshot (captures image) or get_screen_layout (likely returns layout structure). It precisely defines what the tool retrieves 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when screen resolution information is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., android_describe_all might include screen size, or get_screen_layout could be related). It lacks any 'when not to use' statements or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions a prerequisite (IDB installation) but lacks critical behavioral details such as whether this is a read/write operation, error handling, performance implications, or what happens if the simulator is not booted. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds a crucial prerequisite in the second. Both sentences earn their place with no wasted words, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, error conditions, return values, and how it interacts with sibling tools, leaving significant gaps for an AI agent to understand its full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (keycode, duration, udid). The description does not add any additional meaning beyond what the schema provides, such as examples of keycodes or typical duration values, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Send a key event'), target resource ('iOS simulator'), and mechanism ('by keycode'), distinguishing it from sibling tools like ios_key_sequence (which sends sequences) and android_key_event (which targets Android).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool ('Requires IDB to be installed') and implies usage for iOS simulators, but does not specify when to choose it over alternatives like ios_key_sequence or when not to use it (e.g., for physical devices).
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 discloses the return data (text, content-description, etc.), which is useful behavioral context. However, it doesn't mention potential errors (e.g., if coordinates are out of bounds), performance implications, or whether this requires specific device states (e.g., unlocked screen). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by return value details. Every word earns its place—no redundancy or fluff. It efficiently communicates essential information without waste, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and return values well, but lacks details on error handling, performance, or device prerequisites. Without annotations or an output schema, more behavioral context would improve completeness, but it's adequate for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for x, y, and deviceId parameters in the input schema. The description adds no additional parameter semantics beyond what the schema provides, such as coordinate system details (e.g., origin point) or deviceId usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get UI element info at specific coordinates'), the resource ('on an Android device'), and distinguishes it from siblings like android_describe_all (which describes all elements) and android_find_element (which finds elements by properties rather than coordinates). The verb 'Get' combined with the coordinate-based approach makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'at specific coordinates on an Android device,' which suggests this tool is for inspecting UI elements at precise screen locations. However, it doesn't explicitly state when to use this versus alternatives like android_describe_all (for all elements) or android_find_element (for searching by properties), nor does it mention prerequisites like device connectivity. The guidance is clear but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the tool as a read operation ('Get', 'check') and implies it returns status information, which is adequate. However, it lacks details on potential side effects, error handling, or response format, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence adds value without redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete for a status-checking tool. However, it could be more comprehensive by detailing the return format or error conditions, which would help an agent better anticipate the output, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied since it avoids unnecessary repetition of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'check') and resources ('Metro bundler status', 'build state', 'recent bundling errors'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_bundle_errors' or 'clear_bundle_errors', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to check if there are compilation/bundling errors that prevent the app from loading'), which helps guide usage. However, it doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'get_bundle_errors' for error details only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior (returns a hierarchical view with specific element attributes) and method (using uiautomator), but does not cover potential side effects, permissions needed, rate limits, or error conditions. It adds value beyond the schema but is incomplete for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently details the return format in the second. Every sentence adds essential information without redundancy, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving a full UI tree), no annotations, and no output schema, the description is partially complete. It explains the return content but lacks details on output structure, potential errors, or operational constraints. It is adequate but has clear gaps that could hinder effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'deviceId' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating with extra details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the full UI accessibility tree') and resource ('from the Android device using uiautomator'), distinguishing it from siblings like android_describe_point (point-specific) and android_find_element (targeted search). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a comprehensive hierarchical view of all UI elements, which differentiates it from more targeted siblings (e.g., android_describe_point for a specific point). However, it lacks explicit guidance on when not to use it or direct alternatives, such as preferring android_describe_point for focused queries.
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 full burden. It discloses that text is input at the current focus point and implies a prerequisite (tapping first), which adds useful context. But it doesn't cover potential errors (e.g., no focus), rate limits, or device connectivity needs, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the core action and target, the second adds crucial usage note. It's front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the essential action and a key prerequisite. However, it lacks details on error handling, performance, or return values, making it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description doesn't add meaning beyond the schema (e.g., it doesn't clarify text encoding or deviceId selection nuances), meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Type text') and target ('on an Android device/emulator'), specifying it inputs text at the current focus point. It distinguishes from siblings like android_tap (which taps) or android_key_event (which sends key presses), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use: 'tap an input field first' to set focus. However, it doesn't explicitly mention when NOT to use it or name alternatives like android_key_event for non-text input, so it lacks full exclusion 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves health status and identifies potential data gaps, which is useful behavioral context. However, it does not mention performance characteristics (e.g., latency), error handling, or whether it requires active connections, leaving gaps in transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key details (uptime, disconnects/reconnects, gaps). It is front-loaded with the main action and avoids unnecessary elaboration, making every word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides a clear purpose but lacks details on return format, error conditions, or dependencies. For a health-check tool with zero parameters, it is minimally adequate but could benefit from mentioning output structure or usage constraints to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description does not need to add parameter details, as there are none to document. It appropriately focuses on the tool's purpose without redundant parameter explanations, meeting the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed connection health status'), specifying what information is retrieved (uptime, recent disconnects/reconnects, connection gaps). It distinguishes from sibling tools like 'ensure_connection' (which likely establishes connections) and 'get_network_stats' (which focuses on network metrics rather than connection health).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monitoring connection health and identifying data gaps, but does not explicitly state when to use this tool versus alternatives like 'get_network_stats' or 'ensure_connection'. It provides context about what the tool does, but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'boot' implies a state-changing operation, the description lacks details on permissions required, whether this is destructive to existing simulator states, timeouts, or what happens if the simulator is already booted. It mentions using 'list_ios_simulators' but doesn't explain the boot process itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides essential usage guidance. It's front-loaded with the core action and efficiently includes only necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter (fully documented in schema) and no annotations or output schema, the description is adequate but incomplete. It covers purpose and basic usage but lacks behavioral details (e.g., side effects, error handling) that would be important for a boot operation. Given the simplicity, it's minimally viable but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'udid' parameter fully documented in the schema. The description adds minimal value by referencing 'list_ios_simulators' as the source for UDIDs, but doesn't provide additional semantics beyond what the schema already states. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Boot') and target resource ('iOS simulator by UDID'), distinguishing it from sibling tools like 'list_ios_simulators' (which finds simulators) and other iOS tools that perform different operations (e.g., 'ios_install_app', 'ios_launch_app'). The verb 'boot' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool ('Boot an iOS simulator by UDID') and directs users to an alternative tool for prerequisite information ('Use list_ios_simulators to find available simulators'). This gives clear context and distinguishes it from other iOS tools that might require a booted simulator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a prerequisite (IDB installation requirement) which is valuable context, but doesn't describe what the tool returns, error conditions, or performance characteristics. It adequately covers the basic operation but lacks depth on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core functionality, the second provides critical prerequisite information. No wasted words, front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate basic information but lacks details about return values, error handling, or performance considerations. It covers the essential 'what' and 'prerequisite' but doesn't fully address the complexity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear documentation for all 3 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get accessibility information') and resource ('UI element at a specific point on the iOS simulator screen'). It distinguishes itself from sibling tools like 'ios_describe_all' by specifying point-based inspection rather than comprehensive description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for iOS simulator accessibility inspection at a specific point) and mentions a prerequisite (IDB installation). However, it doesn't explicitly state when NOT to use it or name alternatives like 'ios_describe_all' for broader inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates that this is a write/mutation operation ('Type text') and mentions a prerequisite dependency (IDB installation). However, it doesn't describe what happens if no input field is active, whether text is appended or replaces existing content, error conditions, or what the response looks like. The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core functionality, the second provides a critical prerequisite. No wasted words, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and a critical prerequisite, but doesn't address behavioral details like error conditions, what constitutes 'active input field', or what happens after typing. Given the complexity of interacting with a simulator and the lack of structured safety/behavior annotations, the description should do more to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (text and udid). The description doesn't add any parameter-specific information beyond what's in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Type text into the active input field') and target resource ('iOS simulator'), distinguishing it from sibling tools like android_input_text by specifying the iOS platform. It provides a complete verb+resource+platform combination that leaves no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('on an iOS simulator') and includes an important prerequisite ('Requires IDB to be installed'). However, it doesn't explicitly mention when NOT to use it or name alternative tools (like android_input_text for Android), though the iOS context strongly implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the IDB installation requirement, which is useful context about dependencies. However, it lacks details on potential side effects (e.g., simulator state changes), error conditions, or what happens if the simulator is not booted, leaving behavioral traits partially described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the core purpose, and the second adds a critical prerequisite. It is front-loaded with the main action and efficiently structured, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose and a key prerequisite, but could improve by mentioning expected outcomes (e.g., simulator response) or error handling, especially since there's no output schema to clarify returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain what 'SIRI' or 'APPLE_PAY' buttons do in practice). Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Press a hardware button') and target resource ('on an iOS simulator'), distinguishing it from sibling tools like ios_tap or ios_key_event that perform different interactions. It precisely identifies the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('Requires IDB to be installed') which provides clear context for when the tool can be used. However, it does not specify when to use this tool versus alternatives like ios_key_event for software-based key presses or other iOS interaction tools, leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what information is returned (headers, body, timing) but doesn't mention authentication requirements, rate limits, error conditions, or response format. The description is accurate about the tool's purpose but lacks operational context that would help an agent use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two focused sentences that efficiently communicate purpose and usage guidance. The first sentence states what the tool does, and the second provides critical workflow context. There's no wasted verbiage or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate purpose and usage guidance but lacks information about the return format, error handling, or operational constraints. The description is complete enough for basic understanding but would benefit from additional context about what the detailed response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get full details') and resource ('a specific network request'), explicitly listing the included information (headers, body, timing). It distinguishes from its sibling 'get_network_requests' by specifying this tool is for detailed inspection of individual requests rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use get_network_requests first to find the request ID'), creating a clear workflow dependency. It distinguishes this tool from its sibling by positioning it as the second step in a two-step process for network request inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what information is returned (props, style, state, children tree) and mentions parameter-controlled behavior (childrenDepth controls nesting depth). However, it doesn't address important behavioral aspects like whether this is a read-only operation, potential performance implications, or error conditions when componentName doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured: three sentences that each earn their place. The first states the core purpose, the second provides crucial workflow guidance, and the third explains key return values and parameter usage. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is adequate but has gaps. It explains the purpose and workflow relationship well, but doesn't describe the return format (what does 'Returns props, style, state' actually look like?) or address error conditions. Given the complexity and lack of output schema, more detail about the return structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 7 parameters. The description adds minimal value beyond the schema - it mentions 'childrenDepth to control how deep nested children go' which is already covered in the schema description. No additional parameter semantics are provided beyond what's in the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inspect a specific React component by name' with specific details about what it returns (props, style, state, children tree). It distinguishes itself from sibling tools like 'get_component_tree' by being a drill-down tool for specific components rather than a tree overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use after get_component_tree(structureOnly=true) to inspect specific components.' This clearly indicates when to use this tool versus its sibling, establishing a workflow relationship and preventing misuse.
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 full burden. It discloses key behavioral traits: polling mechanism, timeout behavior, and external dependency ('Requires IDB'). However, it doesn't mention error handling, what happens on timeout, or the return format/value when element is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded and concise. Three sentences cover purpose, mechanism, dependency, and usage sequence with zero wasted words. Every sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no annotations and no output schema, the description provides good purpose and usage context but lacks details about return values, error conditions, and timeout behavior. It's adequate but has clear gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Wait for') and resource ('UI element on iOS simulator'), including the polling mechanism. It distinguishes from sibling tools like 'ios_find_element' by emphasizing the waiting behavior and positioning it as a prerequisite step for element interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this FIRST after navigation to ensure screen is ready, then use find_element + tap.' It names the alternative tool ('find_element') and specifies the temporal sequence, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a discovery/listing operation, implying it's read-only and non-destructive, but doesn't specify behavioral details like whether it requires an active app connection, what format the output returns, or if there are any rate limits. It adds some context but lacks operational specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the purpose with specific details, and the second provides usage guidance. Every word earns its place, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (discovery operation in a debugging context), no annotations, and no output schema, the description is adequate but incomplete. It explains what the tool does and why to use it, but lacks details on output format, connection requirements, or error handling, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('globally available debugging objects'), specifying the target environment ('connected React Native app') and providing concrete examples ('Apollo Client, Redux store, React DevTools, etc.'). It distinguishes from siblings by focusing on debugging objects rather than UI elements, logs, or network requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to discover what state management and debugging tools are available'), but does not explicitly mention when not to use it or name specific alternatives among the many sibling tools. The guidance is helpful but could be more comparative.
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 HTTP server runs in-process to share state and that restarting is needed for code changes, which adds useful context about the tool's effect and prerequisites. However, it doesn't mention potential side effects (e.g., temporary downtime, impact on other tools), rate limits, or error handling, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key information (server runs in-process, restart for changes). Every sentence earns its place by providing essential context and usage guidance, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple restart with no parameters), lack of annotations, and no output schema, the description is reasonably complete. It explains the purpose, when to use it, and the underlying reason (in-process server). However, it could benefit from mentioning what 'restart' entails (e.g., stops and starts the server) or confirmation of success, slightly reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't discuss parameters, which is appropriate, but it could briefly note the lack of inputs for clarity. Baseline for 0 params is 4, as it adequately handles the absence of parameters without adding unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to restart the HTTP server, which is necessary to apply code changes due to the server running in-process. It specifies the verb ('restart') and resource ('HTTP server'), though it doesn't explicitly differentiate from sibling tools like 'reload_app' or 'connect_metro', which is why it's not 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'To apply code changes, restart the MCP session.' It directly states the trigger condition (code changes) and implies an alternative (not using it when changes aren't needed), making it clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the workflow dependency on ocr_screenshot but doesn't disclose behavioral traits like whether this requires device connection, what happens if coordinates are invalid, or if there are rate limits. The description adds some context but leaves important behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the purpose, the second provides crucial workflow guidance. Every word earns its place, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides good context about the workflow and relationship to ocr_screenshot. However, it doesn't explain what happens after the tap (success/failure indicators) or error conditions, which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (x, y, deviceId). The description mentions using 'tapX/tapY values' from ocr_screenshot, which reinforces the coordinate parameters but doesn't add significant meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Tap at specific coordinates') and resource ('Android device/emulator screen'). It distinguishes from sibling tools like android_tap_element (which likely taps UI elements rather than coordinates) and android_long_press (different gesture).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'Use ocr_screenshot first to get tap coordinates, then use this tool with the returned tapX/tapY values.' This clearly indicates when to use this tool versus alternatives like android_tap_element or android_find_element.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the underlying technology (uiautomator) and reliability considerations compared to ocr_screenshot, but doesn't address important behavioral aspects like error conditions (what happens if element isn't found), timing considerations, or what constitutes a successful tap. The description adds some context but leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized with two sentences: the first states the core functionality, the second provides valuable usage guidance. Every word earns its place, and the information is front-loaded with the primary purpose stated immediately. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a UI automation tool with 7 parameters and no output schema, the description provides good context about the tool's purpose and when to use alternatives. However, it doesn't explain what happens after tapping (success indicators, return values, or error behavior), which would be helpful given the lack of output schema. The reliability comparison with ocr_screenshot is valuable context that compensates somewhat for other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the three identification approaches (text, content-description, resource-id) which correspond to parameter groups, but provides no additional syntax, format, or usage details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tap') and target ('an element'), specifies the identification methods ('by its text, content-description, or resource-id'), and mentions the underlying technology ('using uiautomator'). This provides a specific verb+resource combination that distinguishes it from generic 'android_tap' and other UI interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool recommendation ('Consider using ocr_screenshot first') with justification ('it returns ready-to-use tap coordinates... and works more reliably across different apps'). This gives clear guidance on when to prefer an alternative approach, which is exactly what strong usage guidelines should provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'establishes the WebSocket connection needed for debugging tools,' which explains the outcome and purpose. However, it doesn't cover potential failure modes, authentication requirements, timeout behavior, or what happens if the connection fails—leaving gaps for a mutation tool (connection establishment).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste—front-loaded with the core purpose, followed by usage guidance. Every word contributes value, making it highly efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (establishing a connection), no annotations, and no output schema, the description does well by covering purpose, usage guidelines, and behavioral outcome. However, it lacks details on error handling or connection state management, which would be helpful for a tool that mutates system state (establishes connections).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'port' parameter fully documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (e.g., no details about valid port ranges or connection protocols). This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Connect to a Metro server') and resource ('on a specific port'), distinguishing it from sibling tools like 'scan_metro' which auto-detects ports. It explicitly mentions establishing a WebSocket connection for debugging tools, providing a complete purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you know the exact port') and when to use an alternative ('otherwise use scan_metro which auto-detects'). This directly addresses the comparison with the sibling tool, offering clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by describing the fallback behavior (screenshot+OCR when no errors captured), which is a key behavioral trait not evident from the schema. It also implies this is a read operation (retrieving errors) rather than a mutation. However, it doesn't mention rate limits, authentication needs, or what happens when Metro isn't running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly sized at two sentences, front-loaded with the primary purpose, followed by important behavioral context about the fallback mechanism. Every sentence earns its place with zero wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieval with conditional fallback), no annotations, and no output schema, the description does well by explaining both the primary retrieval behavior and the fallback mechanism. However, it doesn't describe the return format (what the errors look like) or error conditions, which would be helpful since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by mentioning the screenshot fallback context for the 'platform' and 'deviceId' parameters, but doesn't provide additional semantic meaning beyond what the schema descriptions already state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('retrieve captured Metro bundling/compilation errors') and resources ('errors during bundle build process'). It distinguishes from sibling tools like 'clear_bundle_errors' (which clears rather than retrieves) and 'get_bundle_status' (which checks status rather than errors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve bundling errors that prevent app loading. It implicitly distinguishes from tools like 'get_logs' or 'search_logs' by focusing specifically on Metro bundling errors. However, it doesn't explicitly state when NOT to use it or name specific 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 burden of behavioral disclosure. It effectively describes key behaviors: auto-enables inspector when coordinates are given, taps at coordinates, returns component hierarchy, and works across React Native versions including Fabric. It lacks details on permissions, rate limits, or error handling, but covers essential operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey the tool's functionality and scope. Every sentence earns its place by providing critical information without redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (conditional behavior based on parameters), no annotations, and no output schema, the description is mostly complete. It explains the tool's behavior and compatibility but could benefit from details on return values or error cases. However, it adequately covers the core functionality for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters (x and y as numbers with descriptions). The description adds some semantic context by explaining that if x/y are provided, it auto-taps at that location, but this is largely implied by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get', 'read') and resources ('React component', 'Element Inspector selection'). It distinguishes itself from siblings like 'inspect_at_point' or 'inspect_component' by specifying it works with coordinates or current selection and supports all React Native versions including Fabric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool based on whether coordinates are provided (x/y for auto-tap at location, no coordinates for current selection). However, it does not explicitly mention when not to use it or name specific alternatives among the many sibling tools, such as 'inspect_at_point' for similar functionality.
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 describes what data is returned (URL, method, status, timing) and suggests a usage tip, but lacks details on permissions, rate limits, or error handling. For a tool with no annotations, this is a moderate level of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the purpose and data fields, the second provides a practical tip. It's front-loaded with essential information and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description adequately covers the tool's purpose and usage, but lacks details on return format or error cases. It's complete enough for basic use but could benefit from more behavioral context for a tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'summary=true' in the tip, but doesn't explain parameter interactions or provide additional context. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('captured network requests from connected React Native app'), specifying what data is shown (URL, method, status, timing). It distinguishes from siblings like 'get_network_stats' (statistics) and 'search_network' (search-focused) by emphasizing retrieval of captured requests with specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool: 'Use summary=true first for stats overview (counts by method, status, domain), then fetch specific requests as needed.' This offers a clear workflow and distinguishes it from using 'get_network_stats' for summary-only purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only inspection tool (implied by 'inspect' and 'see') and provides the safety rationale ('avoid errors'). However, it doesn't describe what the output looks like, potential error conditions, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides crucial usage guidance. No wasted words, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter inspection tool with no output schema, the description provides excellent purpose clarity and usage guidance. The main gap is the lack of output format description, which would be helpful given the absence of an output schema. However, the description compensates well with strong behavioral context about when and why to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'objectName' well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, but the schema already provides complete documentation including examples. This meets the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('inspect', 'see') and resources ('global object', 'properties, types, callable functions'). It distinguishes itself from siblings like 'list_debug_globals' (which lists objects) by focusing on detailed inspection of a single object's internal structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'BEFORE calling methods on unfamiliar objects to avoid errors.' This creates a clear usage context and distinguishes it from other inspection tools like 'inspect_component' or 'inspect_at_point' that target different resources.
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 effectively describes key traits: it's a read operation (implied by 'Get'), requires external setup ('Requires IDB to be installed'), and specifies the output format. It does not mention potential errors, performance implications, or authentication needs, but covers essential operational context adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral and setup details. Every sentence adds value: the first defines the action and output, the second specifies prerequisites. There is no wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read operation with one optional parameter) and no annotations or output schema, the description provides sufficient context: it explains what the tool does, the return format, and prerequisites. It could improve by mentioning error handling or limitations, but it covers the essentials well for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'udid' fully documented in the schema. The description does not add any additional meaning or details about parameters beyond what the schema provides, so it meets the baseline score of 3 without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get accessibility information') and resource ('entire iOS simulator screen'), and distinguishes it from sibling tools like 'ios_describe_point' by specifying the scope ('entire screen'). It explicitly mentions the return format ('nested tree of UI elements with labels, values, and frames'), which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it's for iOS simulators and requires IDB installation, which helps determine when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., 'ios_describe_point' for specific points), which prevents a perfect 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite (IDB installation) and the workflow context, which adds value. However, it lacks details on error handling, performance characteristics (e.g., timeouts), or what happens if no element is found. For a tool with 7 parameters and no annotations, more behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences, each adding distinct value: purpose, prerequisite, workflow, and comparison. There is no redundant information, and it's front-loaded with the core functionality. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is reasonably complete. It covers purpose, prerequisites, workflow, and alternatives. However, without an output schema, it could benefit from more details on the return format (e.g., structure of 'element details'), but the mention of 'tap coordinates' provides some context. The description compensates well for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter-specific information beyond what's in the schema (e.g., it doesn't clarify parameter interactions or precedence). The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find a UI element on iOS simulator'), the mechanism ('by accessibility label or value'), and the outcome ('Returns element details including tap coordinates'). It distinguishes from sibling tools like 'ios_screenshot' by explicitly stating 'Prefer this over screenshots for button taps.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Prefer this over screenshots for button taps'), includes a workflow context ('Workflow: 1) wait_for_element, 2) find_element, 3) tap with returned coordinates'), and mentions prerequisites ('Requires IDB (brew install idb-companion)'). It effectively distinguishes from alternatives like 'ios_screenshot' and 'ios_tap_element'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the scanning behavior and connection establishment, but doesn't disclose important behavioral traits like error handling, timeout behavior, what happens if no servers are found, or whether this tool modifies system state. The description implies it's a setup/connection tool but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with two sentences: the first states the core functionality, the second provides crucial usage context. Every word earns its place, and the most important information (purpose and when to use) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does well by explaining the tool's role in the debugging workflow and its relationship to other tools. However, it doesn't describe what the tool returns (e.g., connection status, found servers list) or error conditions, leaving some gaps for a tool that establishes critical debugging connections.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (startPort, endPort) with defaults and descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('scan for running Metro bundler servers', 'automatically connect to any found React Native apps'), identifies the resource (Metro servers, React Native apps), and distinguishes it from siblings by establishing connections needed for other tools like get_logs, execute_in_app, and reload_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('typically the FIRST tool to call when starting a debugging session') and why ('establishes the connection needed for other tools'), clearly positioning it as an initialization step before using sibling tools for debugging operations.
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 tool toggles the inspector programmatically and mimics a manual action, which is helpful context. However, it lacks details on behavioral traits like side effects (e.g., whether it affects app state), permissions needed, or error conditions. The description does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a practical analogy and use case. Both sentences earn their place by clarifying functionality and utility, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. It explains what the tool does and why to use it. However, it could be more complete by addressing potential behavioral nuances like toggle state persistence or compatibility issues, which are relevant for a debugging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose. Baseline is 4 for 0 parameters, as the description adds value without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Toggle React Native's Element Inspector overlay programmatically') and the resource involved ('Element Inspector overlay'). It distinguishes from siblings by focusing on toggling the inspector rather than other debugging or interaction tools like 'get_inspector_selection' or 'inspect_component'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('Useful for enabling inspector features without user interaction') and references manual alternative ('same as manually doing: Dev Menu > Toggle Element Inspector'). However, it does not explicitly state when NOT to use this tool or name specific alternative tools from the sibling list.
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 effectively describes key behavioral traits: it works like React Native's Element Inspector, mentions API availability issues ('getInspectorDataForViewAtPoint' may not be available in newer versions), and outlines fallback strategies. However, it doesn't specify error handling, performance implications, or output format details, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. It uses two sentences efficiently, with the second providing crucial context and alternatives. While concise, the second sentence is slightly dense but still earns its place by adding necessary guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, usage guidelines, and behavioral context well. However, it lacks details on output format or error handling, which would be helpful since there's no output schema, leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any additional meaning or context about the parameters beyond what the schema provides (e.g., it doesn't explain coordinate systems further or usage of includeProps/includeFrame). The baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('inspect') and resources ('React component'), and distinguishes it from siblings by mentioning alternatives like 'ios_describe_point/android_describe_point' and 'find_components'. It explicitly identifies what it inspects and how it differs from 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for React component inspection) and when not to use it (if unavailable in newer React Native versions with Fabric), naming specific alternatives ('ios_describe_point/android_describe_point' then 'find_components'). This covers both usage context and exclusions clearly.
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 effectively describes key traits: it's a read-only operation (implied by 'takes a screenshot'), returns coordinates ('tapX/tapY'), and has performance and compatibility advantages ('Faster than parsing accessibility hierarchies', 'Works consistently across iOS and Android'). However, it doesn't mention potential limitations like OCR accuracy, screen resolution dependencies, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose and recommendation. It uses bullet-like advantages and clear usage instructions. However, it could be slightly more concise by integrating the advantages into a smoother narrative, and some phrasing is repetitive (e.g., 'tap-ready coordinates' mentioned multiple times).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (OCR-based UI interaction) and lack of annotations or output schema, the description does a good job of explaining what the tool does, when to use it, and its benefits. It covers the core functionality and differentiation from siblings. However, it doesn't detail the output format (e.g., structure of extracted text and coordinates) or error cases, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (platform and deviceId) with descriptions. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain how these parameters affect OCR processing or coordinate extraction. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Takes a screenshot and extracts all visible text with tap-ready coordinates using OCR.' It specifies the verb ('takes', 'extracts'), resource ('screenshot', 'visible text'), and output ('tap-ready coordinates'). It clearly distinguishes from sibling tools like android_describe_all or ios_describe_point by emphasizing OCR-based text extraction with coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'RECOMMENDED: Use this tool FIRST when you need to find and tap UI elements' and 'USE THIS FOR: Finding buttons, labels, menu items, tab bars, or any text you need to tap.' It contrasts with alternatives by listing advantages over accessibility trees (e.g., 'Works on ANY visible text regardless of accessibility labels'), guiding the agent on when to prefer this tool over others like android_find_element or ios_find_element.
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 effectively describes the tool's behavior: it's a read-only operation that returns element details without performing actions, specifies it's for checking existence, and outlines a typical workflow. However, it doesn't mention potential errors (e.g., if no element is found) or performance considerations, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidelines and workflow, with every sentence adding value. It avoids redundancy and is efficiently structured in four concise sentences, making it easy to parse without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and behavior well, but lacks details on error handling or output format specifics, which could be helpful for an agent. The absence of an output schema means the description doesn't fully compensate for missing return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters (e.g., precedence rules) or usage examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find a UI element on Android screen') and resources involved ('by text, content description, or resource ID'), distinguishing it from siblings like android_tap_element or android_wait_for_element. It explicitly mentions the return value ('Returns element details including tap coordinates'), 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this to check if an element exists without tapping it') and when not to ('Prefer this over screenshots for button taps'). It also outlines a workflow ('Workflow: 1) wait_for_element, 2) find_element, 3) tap with returned coordinates') and distinguishes it from alternatives like screenshots, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the polling mechanism, timeout behavior, and accessibility tree scanning. It mentions the tool will wait 'until the element is found or timeout is reached' which clarifies the success/failure conditions. However, it doesn't specify what happens on timeout (error? null return?) or whether this blocks other operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured in two sentences: first explains what the tool does and how it works, second provides clear usage guidance. Every word earns its place with zero redundancy or fluff. It's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does an excellent job explaining the core behavior and usage context. It covers the polling mechanism, timeout, and workflow positioning. The main gap is the lack of information about return values or timeout handling, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 9 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3. The description's focus is on tool behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Wait for a UI element to appear on Android screen') and the mechanism ('Polls the accessibility tree until the element is found or timeout is reached'). It distinguishes this tool from siblings like android_find_element by emphasizing the waiting/polling behavior rather than immediate lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this FIRST after navigation to ensure screen is ready') and what to do next ('then use find_element + tap'). It clearly positions this as a prerequisite step before other interaction tools, offering practical workflow advice.
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 effectively describes key behaviors: it 'runs a health check' and 'will auto-reconnect if needed.' However, it doesn't specify error handling, timeout behavior, or what constitutes a 'healthy connection,' leaving some operational details unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states purpose and usage guidelines, the second explains behavioral traits. Every sentence adds value with zero redundant information, making it appropriately sized and front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (connection management with health checks), no annotations, and no output schema, the description does a good job covering purpose, usage, and key behaviors. However, it lacks details on return values or error conditions, which would be helpful since there's no output schema to provide that information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('verify or establish a healthy connection') and identifies the target resource ('React Native app'). It distinguishes itself from siblings like 'connect_metro' by emphasizing health verification and auto-reconnection capabilities, not just connection establishment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'before running commands if connection may be stale, or after navigation/reload.' It also implicitly suggests alternatives by indicating this is for health verification and reconnection, distinguishing it from initial connection tools like 'connect_metro' or status-checking tools like 'get_connection_status'.
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 effectively describes key behaviors: it executes JavaScript in the app context, returns results, handles Hermes compatibility with global polyfilling, and warns about result truncation for large objects. However, it doesn't mention potential side effects, error handling, or security implications of arbitrary code execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with two sentences that each serve distinct purposes: the first states the core functionality, the second provides technical details about Hermes compatibility. There's no wasted language, and important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, but no annotations or output schema, the description provides good contextual completeness. It covers the tool's purpose, usage scenarios, technical compatibility details, and references alternatives. The main gap is the lack of output format description, but given the tool's REPL nature, this is somewhat mitigated by the parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific information beyond the schema - it mentions Hermes compatibility for global/globalThis but doesn't provide additional semantic context for the parameters themselves. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute JavaScript code in the connected React Native app and return the result.' It specifies the verb ('Execute'), resource ('JavaScript code'), and context ('React Native app'), distinguishing it from sibling tools like inspect_global or get_component_tree which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use this for REPL-style interactions, inspecting app state, or running diagnostic code.' It also mentions alternatives: 'Tip: For large objects like Redux stores, use inspect_global instead or set higher limit.' This clearly indicates when to use this tool versus other options.
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 effectively describes key behavioral traits: it's a search operation (implied by 'Find'), mentions efficiency compared to get_screen_layout, and provides guidance on using includeLayout parameter for additional style information. However, it doesn't cover potential limitations like performance impacts with complex patterns or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences, each serving a distinct purpose: stating the core function, providing usage context, and offering parameter guidance. There's no wasted text, and information is front-loaded with the primary purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, regex pattern matching) and lack of output schema, the description provides good contextual completeness. It explains the tool's role in the workflow, efficiency benefits, and key parameter usage. However, without an output schema, it could benefit from more detail about return format expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only mentioning includeLayout=true to get padding/margin/flex styles. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find components matching a name pattern.' It specifies the verb ('Find'), resource ('components'), and scope ('matching a name pattern'), and distinguishes it from sibling tools like get_component_tree and get_screen_layout by explaining its targeted search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use after get_component_tree(structureOnly=true) to find specific components by pattern and get their layout info.' It also states when to use this tool versus alternatives: 'More efficient than get_screen_layout for targeted queries.' This gives clear context for when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation (listing apps) and mentions a prerequisite action ('run scan_metro first') for when no apps are connected, adding useful behavioral context. However, it lacks details on output format, error handling, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides usage guidance. It is front-loaded with the core functionality and efficiently includes necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is reasonably complete for a simple listing tool. It covers purpose, usage guidelines, and behavioral context (prerequisite action). However, it could be more complete by specifying the return format or handling of edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate, and it adds value by explaining the tool's behavior and prerequisites, compensating for the lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('currently connected React Native apps and their connection status'), making the purpose specific and unambiguous. It distinguishes itself from siblings like 'scan_metro' by focusing on listing rather than establishing connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when to use this tool ('List currently connected React Native apps') and when to use an alternative ('If no apps are connected, run scan_metro first to establish a connection'), naming the sibling tool 'scan_metro' as the alternative for establishing connections.
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 tool retrieves a URL for accessing debug data, implying it's a read-only operation without side effects. However, it lacks details on potential errors, authentication needs, or rate limits, which are important for a tool interacting with a debug server.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place without redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is complete enough for its simple purpose. It explains what the tool does and when to use it, though it could benefit from mentioning the format of the returned URL or any prerequisites. For a low-complexity tool, this is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the tool's purpose and usage, which compensates for the lack of parameters. A baseline of 4 is appropriate as it provides meaningful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('debug HTTP server URL'), distinguishing it from sibling tools that focus on Android/iOS operations, logs, network requests, or other debugging aspects. It explicitly identifies what the tool retrieves without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to find where you can access logs, network requests, and other debug data via HTTP.' This clearly indicates its purpose for locating a debug HTTP endpoint, differentiating it from tools like 'get_logs' or 'get_network_requests' that fetch data directly.
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 effectively describes the tool's behavior by explaining the summary mode functionality and providing practical tips about token management and output formats. However, it doesn't mention potential limitations like connection requirements, performance implications, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with two sentences: the first states the core purpose, the second provides actionable usage guidance. Every word earns its place, and the information is front-loaded with the most important guidance immediately following the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description does well by providing workflow guidance and practical tips. However, it could be more complete by mentioning what the tool returns (log format/structure) or any prerequisites (requires connected app). The absence of output schema means the description should ideally cover return values more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds some value by explaining the strategic use of 'summary=true' and providing context about when to use certain parameter combinations, but doesn't add significant semantic information beyond what's already documented in the comprehensive parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Retrieve') and resource ('console logs from connected React Native app'), distinguishing it from sibling tools like 'search_logs' or 'clear_logs'. It provides a complete functional statement that leaves no ambiguity about 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with the tip to 'Use summary=true first for a quick overview... then fetch specific logs as needed.' This gives clear direction on when to use this tool and how to sequence operations, addressing the common workflow of first getting an overview before detailed inspection.
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 full burden and does well by disclosing important behavioral traits: the prerequisite relationship with get_component_tree, performance characteristics ('data which can be large for complex screens'), and alternative approaches. It doesn't cover all possible behavioral aspects like error conditions or authentication needs, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences that each serve distinct purposes: stating the core function, providing usage guidance, and warning about data size. There's no wasted text, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 5 well-documented parameters and no output schema, the description provides excellent context about when and how to use it, performance considerations, and alternatives. The main gap is the lack of output format details, but given the tool's relatively straightforward purpose and good parameter documentation, this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('layout information for all components on screen'). It distinguishes from sibling tools by specifying it returns 'full layout data' and contrasts with 'find_components with includeLayout=true' for specific areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'USE AFTER get_component_tree' with specific parameter recommendation, and offers a clear alternative ('find_components with includeLayout=true'). It also warns about data size for complex screens, helping the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effectively describes the tool's behavior: tapping at coordinates, with optional duration for long press, and using a booted simulator by default unless UDID is specified. It also mentions the IDB dependency requirement. However, it doesn't cover error conditions or what happens if coordinates are out of bounds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise: three sentences that each earn their place. The first states the purpose, the second provides workflow guidance, and the third specifies prerequisites. There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does an excellent job covering the essential context: purpose, workflow, prerequisites, and behavioral aspects. The main gap is the lack of information about return values or error conditions, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions using tapX/tapY values from ocr_screenshot, which provides context for the x and y parameters, but doesn't add significant value beyond what's already in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Tap at specific coordinates on an iOS simulator screen.' This is a specific verb+resource combination that clearly distinguishes it from sibling tools like 'ios_tap_element' (which taps elements rather than coordinates) and 'android_tap' (which targets Android instead of iOS).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'Use ocr_screenshot first to get tap coordinates, then use this tool with the returned tapX/tapY values.' It also specifies prerequisites: 'Requires IDB (brew install idb-companion).' This gives clear when-to-use instructions and mentions a required dependency.
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 full burden and does well by disclosing key behavioral requirements: it states the prerequisite 'Requires IDB (brew install idb-companion)' and explains the alternative approach's advantage. However, it doesn't mention error conditions, timeout behavior, or what happens if no matching element is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose, followed by prerequisite information, then alternative usage guidance. Every sentence earns its place: the first states what the tool does, the second provides essential setup information, and the third offers valuable comparative guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description does well by covering purpose, prerequisites, and alternatives. However, it doesn't describe what happens on success/failure or the return format. Given the 5 parameters and mutation nature (tapping implies interaction), more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already documented in the schema (which thoroughly describes all 5 parameters). No additional syntax, format, or constraint details are provided in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Tap an element') and target ('by its accessibility label'), distinguishing it from sibling tools like ios_tap (which likely taps by coordinates) and ios_find_element (which finds but doesn't tap). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: it directly recommends 'Consider using ocr_screenshot first' as an alternative approach that 'works without requiring accessibility labels.' This creates clear decision criteria between two different interaction methods.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior regarding output size reduction, what gets skipped (navigation wrappers and global overlays), and token efficiency considerations. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with just two sentences, both of which earn their place. The first sentence states the core purpose, and the second provides crucial usage guidance with specific recommendations and quantitative benefits. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 100% schema coverage, and no output schema, the description provides excellent context about usage patterns and practical considerations. It could potentially mention return format details or error cases, but given the comprehensive schema and clear behavioral guidance, it's nearly complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline would be 3, but the description adds significant value by explaining the interaction between parameters (focusedOnly=true with structureOnly=true) and the practical impact on output size (~1-2KB), which goes beyond the schema's technical documentation of individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('React component tree from the running app'), distinguishing it from sibling tools like inspect_component or find_components by focusing on the entire tree structure rather than individual components or search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool, recommending specific parameter combinations (focusedOnly=true with structureOnly=true) for token-efficient overviews, and mentions an alternative (drill down with inspect_component) for detailed inspection after getting the overview.
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 effectively describes key behaviors: it triggers a JavaScript bundle reload, auto-connects to Metro if needed, and explains the impact (resets app state like navigation stack). However, it doesn't mention potential side effects like app downtime or error handling, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it starts with the core action, adds important behavioral context (auto-connect, Fast Refresh note), and ends with specific usage guidelines. Every sentence adds value without redundancy, making it easy to parse and apply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with side effects) and lack of annotations/output schema, the description does well by covering purpose, behavior, and usage guidelines. However, it doesn't detail the return value or error responses, which could be useful for an agent handling edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on usage context rather than parameters, earning a baseline score of 4 since it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reload the React Native app') and the mechanism ('triggers JavaScript bundle reload like pressing 'r' in Metro'). It distinguishes this tool from siblings like 'connect_metro' or 'restart_http_server' by focusing on app reloading rather than connection management or server operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. relying on Fast Refresh: it lists three specific scenarios (logs/behavior not reflecting changes, broken app state, need to reset app state). It also clarifies when NOT to use it (since Fast Refresh handles most code changes automatically), offering clear alternatives to avoid unnecessary reloads.
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:

[![execbro MCP server](https://glama.ai/mcp/servers/igorzheludkov/execbro/badges/card.svg)](https://glama.ai/mcp/servers/igorzheludkov/execbro)

Score Badge

Copy to your README.md:

[![execbro MCP server](https://glama.ai/mcp/servers/igorzheludkov/execbro/badges/score.svg)](https://glama.ai/mcp/servers/igorzheludkov/execbro)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/igorzheludkov/execbro'

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