Manos MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation5/5
Each tool targets a distinct action or resource with clear boundaries (assert vs wait_for, find_elements vs find_text vs inspect_screen, network_start vs network_mock). Overlapping purposes are differentiated by polling vs non-polling, OCR vs accessibility tree, and capture vs mock.
Naming Consistency3/5Most tools follow a verb_noun pattern, but the network_* group reverses it (network_start, network_stop, network_mock, network_clear), and several noun-style names (device_capabilities, cheat_sheet, a11y_audit) break the convention. This mix is readable but not uniform.
Tool Count2/5With 40 tools, the server is well above the 25+ 'too many' threshold. While each tool has a distinct testing purpose, the count is unwieldy for a single server and could be split into focused subdomains (device, network, recording, etc.).
Completeness4/5The tool set covers the core mobile testing lifecycle: app launch/stop, UI interaction and inspection, assertions/waits, device conditions, network capture/mocking, flow recording/export, logs, and accessibility. Minor gaps like missing install/uninstall and explicit device selection are workarounds, not dead ends.
Average 4/5 across 40 of 40 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Force-stop' implies abrupt termination, but it does not mention effects on app data, unsaved state, or required permissions. No return value or side effects are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused phrase with no filler. It front-loads the core action, though it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal, covering only the basic action. Without usage guidance or annotations, an agent cannot confidently choose this tool over siblings like clear_app_state or launch_app. The simple nature of the tool slightly mitigates but does not resolve the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: device_id has a helpful description, but app_id is undocumented. The description adds no parameter-level helpfulness beyond implying that app_id identifies the app to stop.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Force-stop/terminate' and identifies resource 'an app', making the action unambiguous. It does not explicitly distinguish from siblings like clear_app_state or launch_app, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or related operations such as clearing app state or launching an app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without conveying side effects, such as launching an app, requiring an installed app, or what happens for invalid URLs. The description adds no behavioral context beyond the title, making it inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or extraneous information. It efficiently communicates the core function, making it appropriately concise for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description only covers the basic action. It omits important context such as return value behavior (partially covered by observe but not explained in description), prerequisites like having the app installed, and when to prefer this tool over launch_app. This makes it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with device_id and observe having descriptions, but url lacks one. The description's mention of 'deep link / universal link URL' marginally clarifies the url parameter's purpose, but it does not add meaningful information beyond the schema. The observe parameter's options are already well-documented, so the description adds limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Open a deep link / universal link URL on the device.' It distinguishes itself from siblings like launch_app (which opens an app) and tap/input_text (which interact with UI), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like launch_app or input_text. The description lacks any mention of prerequisites, exclusions, or preferred scenarios. The only implication is through the tool's name, which is insufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It discloses polling and timeout, but omits critical details such as what happens on timeout (throws? returns false?), the return value, matching semantics (e.g., first element vs all), and how selectors interact. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by the benefit. Every word earns its place; it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 9 parameters, no output schema, and no annotations. The description is far too minimal: it does not explain element selectors, timeout behavior, or return values. The tool cannot be used correctly based solely on the description, making it contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 11% (only device_id has a description), and the description does not explain any of the 8 undocumented parameters (id, text, index, resource_id, accessibility, condition, timeout_ms, interval_ms). The description's mention of 'element' and visibility is vague and does not clarify how to specify targets or configure polling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'poll' and states the resource 'screen' with clear conditions (visible or not_visible) and timeout. It also contrasts with sibling tools like 'assert' and 'find_elements' by focusing on waiting rather than immediate verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Replaces fixed sleeps', giving a clear use case for when to prefer this tool. However, it does not mention when NOT to use it (e.g., if an immediate assertion is needed) or list alternatives like 'assert'.
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. It discloses a state change ('switch') but does not mention side effects, permission requirements, reversibility, error behavior, or return values. It is a minimal statement typical of a simple setter but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, front-loaded with the verb and resource. It contains no fluff or redundant information, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, one with enum), and the description plus schema provide enough to select and invoke it correctly. It lacks usage guidance and behavioral caveats, but given the simplicity, it is adequately complete for a basic setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: device_id is described, appearance has only an enum. The description adds some context by clarifying that 'appearance' refers to light/dark system mode, but it largely duplicates the enum values. It does not add detail for device_id, so the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch'), the resource ('system appearance'), and the scope ('between light and dark mode'). It unambiguously distinguishes this tool from sibling set_* tools (e.g., set_orientation, set_locale) by focusing on appearance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., using list_devices to obtain device_id) or any context about device state. The agent is left to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it 'Returns matching elements' but does not describe how query parameters are combined (AND/OR), whether it waits for elements to appear, what happens on no match (empty list vs error), or any side effects. This is a significant gap for a search tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action. The additional clause about return values and use case adds value without redundancy. Every word contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is too brief. It does not explain the output structure beyond 'id, bounds, text, etc.', nor does it cover matching behavior or edge cases. The lack of a return schema and the minimal description leave the agent with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only device_id is described), and the description does not compensate. The term 'query' vaguely suggests the parameters are filters, but no explanation is given for id, text, index, resource_id, accessibility, or clickable_only. The parameter names are somewhat self-explanatory, but the matching semantics remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the current screen for elements matching a query.' It specifies the resource (current screen) and the verb (search), and indicates the return value (matching elements with attributes). This distinguishes it from siblings like find_text, which is specifically text-based, and inspect_screen, which likely returns the full hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'handy to disambiguate before acting.' This tells the agent when to use the tool (before taking an action to verify element details). However, it does not explicitly mention alternatives or when not to use it, so it lacks a full exclusionary guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only mentions the optional clear state side effect, but does not disclose what happens if the app is already running, whether the tool waits for launch, or any error behavior. The return behavior is only indirectly addressed via the 'observe' parameter in the schema, leaving a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, directly front-loaded with the action and platform specifics. There is no filler or repetition, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool with no output schema, the description and schema together provide enough to invoke the tool. However, the description lacks information about error conditions, installation prerequisites, or timeouts. The observe parameter in schema covers return values, but the overall picture is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining app_id as 'bundle id (iOS) / package name (Android)', which is not in the schema, and clarifies clear_state. However, with schema coverage at 50%, the description only partially compensates; device_id and observe are already well-described in the schema, so the net contribution is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Launch an app by bundle id (iOS) / package name (Android).' This specific verb+resource distinguishes it from sibling tools like stop_app and open_deeplink, and the 'Optionally clear state first' clause adds further scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to launch a mobile app on a device, which is useful context. However, it does not explicitly mention when to prefer this over alternatives such as open_deeplink or stop_app, nor any exclusions. The 'optionally clear state first' gives some guidance but lacks explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Capture a PNG screenshot' without disclosing how the screenshot is returned (e.g., base64, file path), whether it is saved, or any device state requirements. This is a significant transparency gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the essential action and output format efficiently, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description lacks important context about what the agent will receive after invoking the tool. Without an output schema, the description should mention the return format or behavior. The description is adequate but incomplete for an agent to fully understand the tool's outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (device_id) with a detailed description including examples. The tool description does not add parameter-level meaning, but the schema already provides sufficient semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Capture a PNG screenshot of the current device screen.' It uses a specific verb ('Capture'), defines the resource ('current device screen'), and specifies the output format (PNG). This differentiates it from sibling tools like inspect_screen (UI hierarchy) and start_recording (video).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing a screenshot, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like inspect_screen or note any prerequisites. The context is clear but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the high-level action. It does not mention side effects, prerequisites, or consequences of granting/revoking permissions, nor does it address potential platform differences. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one sentence stating the purpose followed by a list of examples. Every word earns its place, and it is front-loaded with the action. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema, yet the description is minimal. It lacks essential context such as the format for app_id, whether permissions are platform-specific, expected error behavior, or any prerequisite conditions. The aliases help but are not sufficient for complete understanding of the tool's usage and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only device_id is described). The description compensates by listing common permission aliases (camera, microphone, location, etc.), which gives the agent a concrete idea of valid values for the 'permission' parameter. It also implies the role of the 'grant' boolean through 'grant or revoke,' though it could be more explicit about syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Grant or revoke a runtime permission for an app.' It uses a specific verb and identifies the resource (runtime permission), making the purpose unambiguous. It also lists example aliases (camera, microphone, etc.), which further clarifies the domain and distinguishes it from other 'set_*' sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever a runtime permission needs to be granted or revoked) but does not explicitly state alternatives or when not to use it. There is no mention of comparing to other permission-related tools, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds one useful behavioral detail: 'Direction swipes are centered on the screen.' However, it omits other critical behavioral traits such as coordinate system, interaction with UI elements, or what observe returns. The disclosure is minimal for a gesture tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the action and modes. Every sentence earns its place: the first states the core functionality, and the second adds a practical nuance. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, this two-sentence description is insufficient. It does not explain absolute vs relative coordinates, duration semantics, or what the tool returns. The centered-screen detail is helpful, but the overall description leaves significant gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the mode selection: direction enum for directional swipes and x1/y1/x2/y2 for coordinate-based swipes, which is not fully evident from the schema given only 25% schema description coverage. It also implies mutual exclusivity by saying 'or between two coordinate points.' This adds meaningful context beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: performing a swipe gesture either via direction (up/down/left/right) or via coordinate points. This unambiguous verb+resource pairing distinguishes it from sibling gesture tools like tap and long_press.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a swipe gesture is needed, but it does not explicitly state when to choose this tool over alternatives like tap or long_press, nor does it mention exclusions or prerequisites. The mention of two modes (direction vs coordinates) provides some internal guidance, but no external comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the output artifacts (YAML flow and report) and does not disclose side effects (e.g., file creation or overwriting), prerequisites (e.g., needing an active recording), or error conditions. This is a significant transparency gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences and 19 words, with the main verb and object front-loaded. Every word earns its place: it clarifies the output types and gives a direct pointer to the next step (run_flow). No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description covers the core purpose and outputs, but it is not fully complete. It does not mention prerequisites (e.g., whether the recording must be stopped), output location or file naming, or how it differs from export_report. The pointer to run_flow mitigates some ambiguity, but additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds contextual meaning by referencing the implicit input ('the recorded session') and the output format, which aligns with the schema's emptiness. No parameter documentation is needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Export the recorded session as a replayable Maestro flow (YAML) plus a human-readable report.' It uses a specific verb ('Export') with a specific resource ('recorded session') and specifies the output formats. This distinguishes it from siblings like export_report (which likely only produces a report) and run_flow (which consumes the exported flow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after recording a session ('Export the recorded session') and provides a pointer to run_flow ('Run it later with run_flow'), but does not explicitly state when to use this tool over alternatives like export_report or whether prerequisites exist (e.g., recording must be stopped). The guidance is implied rather than explicit, earning a mid-range score.
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 basic action (long-press) and that it can target an element or coordinates, but it does not mention side effects, return behavior, or any consequences such as triggering a context menu. This is a significant gap for a mutating gesture tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb. It is concise and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is well-documented (91% coverage), so the description does not need to explain individual parameters. However, it lacks guidance on when to choose element targeting vs coordinates, and there is no mention of the observe parameter's role in controlling return output. For a tool with 11 parameters and no output schema, a bit more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 91%, so most parameters are already documented. The description adds value by clarifying that duration is in milliseconds (matching the duration_ms parameter) and by summarizing the targeting modes ('element or coordinates'), which helps disambiguate selector vs coordinate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('long-press') and clearly identifies the resource ('element or coordinates') and parameter ('duration (ms)'). It distinguishes itself from sibling tools like tap or press_key by naming the long-press action explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: any situation requiring a long press. However, it does not explicitly contrast with alternatives such as tap or swipe, nor does it provide exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that iOS changes apply only after relaunching and Android requires API 33+, which are useful behavioral traits. However, it does not mention side effects, error conditions, or whether the change is reversible, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loaded with the purpose and then providing platform-specific details. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core behavior and platform nuances. It omits details about required device_id (though schema covers it) and possible return/error behavior, but for a straightforward setter, this is adequately complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only device_id having a description. The description provides an example for locale ('fr-FR') but does not explain app_id or its optionality, which is confusing given the instruction 'Provide app_id.' It fails to fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Set app locale' which is a specific verb+resource, and provides a BCP-47 example. It clearly distinguishes itself from sibling tools like set_location or set_orientation by focusing on locale configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides platform-specific usage guidance: Android requires API 33+ and is per-app, while iOS requires relaunching the app. It also instructs to provide app_id. It does not explicitly mention alternatives or when not to use, but the context is clear enough.
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 does disclose platform-specific mechanisms (simctl, SystemUI demo mode) and what gets overridden (time, battery, signal). However, it does not mention side effects, persistence, or whether partial settings reset other values, which are important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes useful platform details without unnecessary fluff. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description is under-specified. It fails to address important context such as what happens when optional parameters are omitted, whether changes are temporary or persistent, and which parameters apply to which platforms. The description gives a high-level overview but leaves a lot of ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description needed to compensate. It groups parameters conceptually (time, battery, signal) which adds meaning beyond the schema, but it does not elaborate on individual parameters like operator_name or the battery_state enum. The platform hints help infer usage but are not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Override the status bar (time, battery, signal) for clean screenshots.' It uses a specific verb ('override') and resource ('status bar'), and the purpose (clean screenshots) is explicit. This distinguishes it from sibling tools like set_appearance or take_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this is for clean screenshots, implying when it should be used. It does not explicitly mention alternatives or exclusions, but the platform-specific hints (iOS vs Android) give additional usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool 'delegates to the maestro CLI,' which is a useful implementation detail, but it does not disclose side effects (running flows may mutate app state), device requirements, or failure modes. This leaves the agent underinformed about behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and has no filler. Every phrase adds functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input modes and tag behavior, and the schema covers device_id, but there is no mention of return values, execution duration, or conditions under which the flow might fail. The tool's dependence on a device is not clarified, and with no output schema, the agent lacks a complete picture. Still, the basic usage is covered, so it is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 71% of parameters, and the description adds critical constraints not present in the schema: the mutual exclusivity of yaml/files/dir, the scoping of tags to dir, and the role of env vars. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Run a Maestro flow' and notes it delegates to the maestro CLI. This distinguishes it from sibling tools, which are individual UI actions or reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions on input selection: 'Provide exactly one of: yaml (inline), files (paths), or dir' and notes that include_tags/exclude_tags apply to dir. However, it does not mention alternative tools or when not to use this tool, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the location is simulated, which is important behavioral context. However, it does not mention potential side effects, persistence, or any required permissions, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the core action and followed by platform specifics. Every word is meaningful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three obvious parameters, the description covers the most critical context: the simulated nature and platform restrictions. It does not explain return values, but the absence of an output schema makes that less critical. The description is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only device_id having a description. The tool description adds no parameter information, leaving latitude and longitude undocumented beyond their names. The names are somewhat self-explanatory, but the description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the specific resource ('simulated GPS location'), making it distinct from sibling tools like set_permission or set_orientation. It 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear platform-specific constraints ('Android: emulator only. iOS: any simulator.'), which helps the agent know when the tool is applicable. It does not explicitly mention alternatives or exclusions beyond platform, but the context is sufficient for a simple setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key limitation (color-contrast requires pixels and is not evaluated) and implies a read-only audit. However, it does not mention potential side effects, return format, or error behavior, which would be valuable for an agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a parenthetical clarification. It is front-loaded with the main action and lists specific issue categories efficiently, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema, no nested objects), the description covers the core functionality and limitations sufficiently. The lack of an output format hint is a minor gap, but the audit scope is clear and the parameter is fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for the single parameter (device_id with details on accepted formats). The description adds no parameter-specific semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits the current screen for specific accessibility issues (undersized touch targets, unlabeled controls, duplicate labels), using a specific verb 'Audit' and resource 'current screen'. It differentiates from sibling tools like inspect_screen by focusing on accessibility checks rather than a general screen dump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use (auditing accessibility of the current screen) and explicitly notes what is excluded (color-contrast checks). It does not name alternative tools, but the scope is clear enough to imply when to use it over general inspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool does not poll and returns pass/fail, which is helpful. However, it does not explain behavior on failure (e.g., throws exception vs returns false), nor does it mention any side effects or conditions for a successful assertion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no irrelevant details. Every sentence adds value: the first defines the action, the second clarifies behavior and points to an alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple assert but lacks important context. With no output schema and many sibling tools, the agent may need to understand element selection semantics and error handling. The description covers the core behavior but leaves gaps in parameter usage and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only device_id is described). The tool description adds no parameter-specific meaning beyond 'an element', leaving the other six parameters (id, text, index, condition, resource_id, accessibility) unexplained. The description should compensate for the low schema coverage, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assert an element is visible or not visible on the current screen.' It uses a specific verb (assert), identifies the resource (element visibility), and distinguishes itself from sibling tools like wait_for (which is for waiting). The return type is also clarified as pass/fail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with an alternative: 'without polling (use wait_for to wait)'. This tells the agent when to use this tool (for immediate assertions) and when not to (when waiting is needed). It gives clear usage context relative to a named sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the type of report (full/partial/unavailable), backend involvement, and caveats, which gives useful context. However, it does not mention whether the operation is read-only, possible side effects, or error conditions, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core purpose, and the second provides actionable guidance. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is largely complete: it explains what is reported and when to use it. The phrase 'full/partial/unavailable' hints at return values, and the second sentence gives contextual guidance. Minor details about how to interpret results are implied but not fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the single parameter 'device_id' with helpful examples (adb serial, UDID). The description adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and clearly identifies the resource ('which actions are supported on a device'). It distinguishes this tool from siblings by focusing on capability checking rather than performing actions, and it adds a clear scope (full/partial/unavailable) with backend caveats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Check this before relying on a platform-specific action.' This provides clear context for usage but does not explicitly exclude alternatives or name what not to use, so it's a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful behavior (automatic crash & ANR detection, platform support) but omits important traits like return format, whether logs are streamed or snapshot, and error behavior. This partial transparency aligns with a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff: the first states the core action and platform scope, the second lists filtering dimensions. The description is front-loaded with the decisive verb 'Fetch' and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain the return value. It never states what the tool returns (text, list, file path) nor provides caveats like buffer limits or asynchronous behavior. This is a clear gap for a 5-parameter device tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (device_id). The description adds meaning to the remaining parameters by mapping 'app_id', 'substring' (filter), 'time window' (since_seconds), and 'line cap' (max_lines), effectively explaining their purpose. It doesn't specify types or defaults, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Fetch recent device logs') and adds distinguishing detail (Android logcat / iOS unified log, crash & ANR detection). It clearly separates this tool from all siblings, none of which handle log retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys clear context: this is the go-to tool for fetching device logs, with filtering options (app_id, substring, time window, line cap) that suggest common use cases. It doesn't explicitly mention alternatives, but since no sibling tool serves this purpose, the context itself is sufficient.
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 present, so the description must carry the safety and behavior burden. It conveys a read-only fetch via the verb 'Get' and mentions 'stable element ids', but it does not disclose limitations such as whether only visible elements are included, whether the hierarchy may be stale, or any accessibility prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core function first and actionable consumption instructions second. Every word serves a purpose; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the output type (compact JSON), key fields (id, text/resource-id), and how to use it with act tools. It could be more explicit about what elements are included (e.g., visible vs. hidden), but it is sufficient for a typical agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single device_id parameter, including format and source. The tool description adds no parameter-specific information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the current screen's view hierarchy as compact JSON with stable element ids', which is a specific verb and resource. It also distinguishes from screenshot-based inspection by saying 'never retype from a screenshot', positioning itself as the source for textual and structural data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: 'Use the id field with act tools (tap/input_text/...)' and 'Copy text verbatim'. It clearly tells the agent when this tool's output is needed, though it does not explicitly contrast with find_elements/find_text or take_screenshot for when to prefer those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses concrete behaviors: detaching Frida, stopping mitmproxy, and restoring the macOS proxy. This provides meaningful context about side effects (restoring system proxy settings) beyond simply saying 'stop'. It 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and peppers in specific details. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the behavior and side effects. It could mention the relationship to network_start (e.g., stops a capture started by that tool), but the operation is clearly a shutdown/cleanup action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the device_id parameter is clearly described in the schema. The tool description does not add any additional parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an imperative verb ('Stop capturing') and specifies the exact resources involved (Frida, mitmproxy, macOS proxy). It clearly distinguishes this from sibling tools like network_start and network_clear by indicating it detaches/stops and restores the proxy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to stop an ongoing network capture, but it does not explicitly state when to use it compared to alternatives like network_clear or network_mock. There is no 'when not to use' or mention of pairing with network_start.
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 behavioral disclosure. It discloses the Android-only limitation and iOS host-network sharing. However, it does not explain interactions between parameters (e.g., whether airplane_mode overrides wifi) or side effects of toggling, leaving behavioral expectations incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The purpose is stated in the first six words, and platform notes are compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. Key gaps include whether multiple toggles can be set simultaneously, what effect airplane_mode has on wifi/cellular, and expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (device_id described). The description names wifi, cellular, and airplane_mode as togglable, which adds basic meaning. But it does not clarify semantics like requiring at least one boolean, exclusivity, or precedence, so parameter understanding remains partially incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Toggle' and names the exact resources (wifi, cellular, airplane mode). It also clarifies the platform scope (Android only), which distinguishes it from generic network tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (Android emulator/device) and provides an alternative for iOS simulators (Network Link Conditioner), clearly guiding selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool combines action and observation ('act+observe'), which is a behavioral trait beyond what a simple tap implies. With no annotations to rely on, this adds useful context about the tool's side effect of returning screen state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action 'Tap'. It includes the key benefit in the second clause without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 10 parameters and detailed schema, the description provides a helpful overview and the crucial act+observe behavior. It does not explain the observe parameter options, but the schema handles those details, making the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions key selection methods (id/text/resource_id/accessibility) already in the schema without adding significant new meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool taps an element by selector or absolute coordinates, using specific verbs and resources. It distinguishes itself from siblings like long_press and swipe by focusing on standard tap actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the benefit of returning the screen state, implying when to use it (when you want action+observation), but it does not explicitly discuss alternatives (e.g., long_press) or when not to use it. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the underlying mechanism (simctl push on iOS) and the Android limitation. While it doesn't address error handling or prerequisites, it adds valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, purpose first, platform specifics second. Every word earns its place, with no redundant information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required params, no output schema, and no annotations, the description provides a clear purpose, platform constraints, and a mechanism. The schema fills in device_id and payload details, and the example in the payload schema aids understanding. The main gap is app_id, but overall it is sufficiently complete for a simple push tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. Schema coverage is 67% (device_id and payload have descriptions), but the app_id parameter remains bare. The description's mention of 'APNs payload' implicitly references the payload property but adds no new detail, failing to compensate for the undocumented app_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Deliver a push notification.' It then differentiates platform behavior (iOS via simctl push, Android unavailable), which distinguishes it from any sibling tool. There is no ambiguity about what this 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states Android is unavailable, guiding the user to only use the tool for iOS simulator pushes. It doesn't name alternatives because no sibling tool provides this functionality, but the platform exclusion is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: conditions report applied/skipped/failed, unsupported ones are skipped with a reason, and explicit fields override presets. It also flags the app_id requirement for the international preset, adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative, with a front-loaded core sentence followed by organized preset definitions. Each clause earns its place, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with nested objects and no output schema, the description covers the main usage modes, preset semantics, override behavior, and error/skip reporting. It stops short of explaining every parameter interaction or return format, but is largely complete for the tool's intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 44%, so description must compensate. It richly documents preset enum values and override behavior, and clarifies locale/app_id. However, explicit fields like network, location, appearance, font_scale, and orientation are not individually detailed in the description, leaning on self-explanatory schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply multiple device conditions in one call', identifying a specific action and resource. Preset definitions like 'screenshot' and 'accessibility' further distinguish it from individual set_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'a named preset and/or explicit fields' and that 'explicit overrides the preset', giving clear usage direction. The 'edge-case states where bugs hide' provides context, though it doesn't explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool writes a file, includes conditional screenshots, and contains an appendix with network/log data, plus returns the file path. It omits details about overwrite behavior or prerequisites, but for a report exporter this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes necessary context about contents and recommended usage. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and no output schema, the description covers the key aspects: what it produces, return value, and recommended pairing with start_recording. It lacks explicit statements about required recording state or behavior when no recording exists, but the core use case is well communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), so the description must compensate. It mentions that the report includes network requests and logs, which indirectly explains the include_logs and include_network parameters, but does not explicitly map them. The output_path parameter is only described in the schema. The description adds moderate value over the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a self-contained HTML report of the recorded session, with specific contents (timeline, screenshots, appendix). This distinguishes it from sibling tools like export_flow or take_screenshot by describing the exact output format and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by recommending 'Best with start_recording(report=true)' and mentioning the conditional 'if report capture was on'. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds value by noting 'Compact by default', optional detail via include_headers/include_body, and the ability to filter by URL regex and limit to avoid flooding. These are meaningful behavioral traits beyond a simple 'returns requests'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core purpose, then quickly covers default behavior and options, every sentence contributing useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description conveys the key return content (method, url, status), default behavior, and filtering/limiting options. It could mention the requirement of an active capture session, but overall it is adequate for a straightforward read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema leaves limit, include_headers, and include_body undocumented. The description compensates by explaining their purpose: detail options and limiting to avoid flooding. It also clarifies filter as URL regex, adding semantics for the half of parameters missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns captured HTTP exchanges with method, URL, and status. It is a specific verb-resource pairing that distinguishes itself from sibling network tools like network_start/stop/clear/mock which control capture rather than retrieve data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining return volume and filtering options, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or mention prerequisites like an active capture session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses supported keys per platform but does not describe behavioral details such as return values, side effects, or prerequisites beyond what the input schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, then the key list. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, all parameters are documented in the schema, and the description provides the necessary scope. It could benefit from mentioning the observe parameter's effect on return, but the schema covers it. No output schema exists, but the observe parameter addresses return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by listing the full set of valid key values per platform, which goes beyond the schema's generic example. The observe parameter is not mentioned, but schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Press a hardware/system key' with a specific verb and resource, and it enumerates platform-specific supported keys, distinguishing it from sibling tools like input_text or tap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by listing valid keys for Android and iOS, implying it is for system/hardware key presses. However, it does not explicitly mention alternatives or exclusions (e.g., for text input).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the Android-only platform limitation and lists all orientation options. It does not detail side effects or error conditions, but for a simple setter the core behavioral traits are adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the action and resource, then lists the values and the platform caveat. Every word adds value, with no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers the essential aspects: what it does, acceptable values, and platform constraints. It could mention the effect on the device or return state, but the tool's simplicity makes the description largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents device_id with examples, and orientation has a self-explanatory enum. The description reinforces the allowed values and adds the Android-only context, but it does not provide significant additional parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Set') and resource ('device orientation'), and enumerates the exact allowed values. This distinguishes it from sibling 'set_*' tools by focusing on orientation, and the platform note ('Android only') adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance for Android devices and explicitly states an alternative for iOS simulators ('must be rotated via the Simulator menu'). While it doesn't contrast with other 'set_*' tools, the platform exclusion is a strong usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that recording starts, subsequent act tools are captured, and that report=true captures screenshots after each action. This gives the agent actionable behavior insights, though it does not mention side effects like resetting an existing recording or limitations on concurrent sessions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the main purpose in the first and the option detail in the second. No fluff, information is front-loaded and easy to skim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description adequately covers the tool's core behavior: starting a recording session and selecting screenshot mode. It could mention the relationship with stop_recording or what 'session' means, but the essentials are present and the tool is not highly complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'report' has a schema description). The description adds value for 'report' by explaining it enables screenshots for the report, but 'app_id' is left undocumented in both schema and description, leaving the agent without guidance on what value to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool begins recording subsequent act tools as a session, and explicitly names the two export destinations (export_flow, export_report). This distinguishes it from siblings like stop_recording, export_flow, and export_report, and uses a specific verb-resource structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: at the start of a session to capture act tools for later export. It also mentions the optional report flag for screenshot capture, which informs usage. It does not explicitly list exclusions or alternatives, but the context makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently states the destructive nature on Android ('full data wipe') and the limited scope on iOS ('resets permissions'), and even notes that a full data wipe on iOS requires reinstall. This is thorough and honest behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a platform breakdown. It front-loads the core purpose ('Reset app state') and adds only necessary platform-specific details. Every word earns its place with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the key contextual aspect—platform-specific behavior and destructive consequences. It does not mention return values or prerequisites, but with no output schema and only two parameters, the description is reasonably complete for a reset operation. A minor omission is lack of guidance on side effects like whether user data is recoverable, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: device_id has a helpful description, but app_id has none. The description adds no parameter semantics at all, leaving the agent to guess the format or purpose of app_id beyond its name. Despite device_id being well-described, the lack of effort to explain app_id or tie it to the action is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resets app state, with specific verbs and resources: 'Reset app state' and platform-specific actions (full data wipe on Android, permissions reset on iOS). This distinguishes it from siblings like stop_app or launch_app, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when resetting app state is needed) and explains platform-specific behavior. However, it does not explicitly mention alternatives or exclusions, such as 'use stop_app to just stop the app,' so it misses the higher bar for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the core behavior (OCR, bounding boxes, optional filtering) and even suggests a specific tap mode. It omits details like coordinate format or error handling, but for a read-only OCR tool it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the main function, the differentiator, and a usage callback. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the essential use case well, including return type and tap integration. The only notable gap is the undocumented confidence parameter, but overall the tool is understandable and usable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes query and device_id well, but min_confidence lacks any explanation beyond a default. The description does not mention min_confidence at all, leaving its meaning and impact unclear. With 67% schema coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool OCRs the current screenshot and returns on-screen text with pixel bounding boxes. It explicitly contrasts with the accessibility tree, distinguishing it from sibling tools like find_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes this is for elements the accessibility tree misses, giving clear when-to-use guidance. It also advises how to interact with results via tap{text, ocr:true}, which is practical and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It clearly states the tool lists devices and returns specific fields (id, platform, name, OS version, state), which sets expectations for output. It does not explicitly assert read-onlyness, but the verb 'list' strongly implies no side effects, and no destructive behavior is hinted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource. The first sentence states the purpose and platforms; the second specifies return fields. Every word earns its place, with no redundant phrasing or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is fully sufficient. It covers the tool's scope (local devices), platforms (Android/iOS), and return fields (id, platform, name, OS version, state). There are no missing parameters or complex side effects to document, so the description is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema is empty with 100% coverage. The description adds no parameter details, but with no parameters to document, the baseline is 4. It correctly describes the static behavior of returning a list of devices with the specified fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and states the resource ('all available local devices') with clear platform scoping (Android via adb, iOS via simctl). This distinguishes it from sibling tools like device_capabilities, which likely operate on a single device rather than enumerating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to discover available local devices and their metadata, but it offers no explicit guidance on when to use it versus alternatives. Since no direct sibling tool provides the same function, the lack of explicit exclusions is acceptable, but the description does not state a recommended context (e.g., before launching an app).
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 disclosure. It explicitly states that the buffer is cleared and that capture continues, which are the key behavioral traits. It does not mention data irreversibility, but that is inherent in the word 'clear'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all necessary information without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and no output schema, the description plus schema fully equip an agent to invoke it correctly. The description covers the action and its critical nuance, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the sole parameter, device_id, with detailed format and source information. The description adds no additional parameter context, which is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clear' and identifies the resource 'captured-request buffer', and adds the crucial scope condition 'without stopping the capture'. This clearly distinguishes it from sibling tools like network_stop 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without stopping the capture' provides clear context for when to use the tool while a capture is ongoing. It does not explicitly name alternatives or exclusions, but the intent is effectively conveyed for a simple utility.
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?
Despite no annotations, the description discloses key behaviors: it types into the currently focused field, and if a locator (id/text/resource_id) is provided, it taps that field before typing. This gives the agent expected sequencing without overpromising. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action. Every word contributes value, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, this description is concise but covers the essential behavior and the optional targeting mechanism. The schema provides rich descriptions for per_char_delay and observe, so the description doesn't need to repeat them. It adequately frames the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the schema by grouping id/text/resource_id as alternative targeting options and explaining that providing one will trigger a tap first. This clarifies their purpose beyond the individual schema descriptions, which otherwise treat them as generic strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Type text into the focused field' and mentions the optional targeting behavior. This distinguishes it from sibling tools like tap and press_key, which are concerned with tapping or key presses, not text entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for typing text, with an optional step to target a field first. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous, making it easy for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers richly: it discloses first-match-wins, hot-reload, capture logging continuation, flagged mocked exchanges, Android's missing abort support, iOS development status, and the replace:true default with empty-list clearing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: purpose, capabilities, behavior, platform notes, and defaults are sequentially presented. It is slightly longer than ideal but every sentence provides value, 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested rules array, multiple capabilities), the description is highly complete. It covers prerequisites, platform differences, rule matching semantics, hot-reload, logging behavior, and the replace default. No output schema exists, but for a mutation tool, the behavior-level detail is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic context like how rules work and replace behavior, but it doesn't elaborate on individual parameters beyond what the schema already states. The extra context is more about tool behavior than parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Override API responses to test hard-to-reproduce states (Android).' It enumerates distinct capabilities (override status/headers, replace body, regex-rewrite, inject latency) and clearly differentiates itself from sibling network tools by explaining its mocking role and its dependency on network_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case ('test hard-to-reproduce states'), prerequisite guidance ('call network_start with app_id first' on Android), and notes platform limitations (iOS in development). However, it doesn't explicitly contrast with network_clear or network_requests, though the different functionality is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry all behavioral disclosure. It does this well by revealing platform-specific behavior: 'Android sets font_scale directly; iOS maps to the nearest Dynamic Type size.' It also clarifies default scale. However, it does not touch on side effects like persistence or app restart requirements, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, leads with the core purpose, and then packs essential behavioral details without any wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters and no output schema, this description covers the purpose, default scale, and platform behavior comprehensively. It lacks explicit return/error info, but for this operation that is not critical. Overall, it is complete enough for an agent to understand the tool's function and key behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so baseline is 3. The description adds extra meaning by explaining 'scale 1.0 = default' and the platform mapping nuance, which enriches understanding of the 'scale' parameter beyond the schema's examples. This warrants a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'text size for accessibility testing', which immediately distinguishes this from sibling tools like set_appearance or set_locale. It precisely conveys the tool's function 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for accessibility testing' provides a clear context for when to use this tool, but it does not explicitly mention when not to use it or suggest alternatives. This is adequate context without exclusions, hence a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Return' clearly indicates a read-only, side-effect-free operation. The scope ('for writing/exporting flows') is disclosed. It does not mention output format or size, but for a simple reference tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that leads with the action and resource. No wasted words, and the information is immediately clear. Perfectly concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple: no parameters, no output schema, no complex behavior. The description fully explains what the tool does and for whom. Nothing essential is missing. It is complete and appropriately scoped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which gives a baseline of 4. The description correctly avoids inventing parameters and adds no unnecessary detail. Since there are no params, the description fully satisfies this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') with a clear resource ('Maestro flow syntax guidance and best practices'). It distinctly focuses on informational guidance, differentiating it from sibling tools like export_flow or run_flow that perform actual operations on flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when writing or exporting flows, providing clear context. It does not explicitly mention alternatives or when not to use, but the tool is self-contained and no sibling overlaps directly. Could be improved with an explicit 'use when...' statement, but the current wording is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It goes beyond a simple 'stop' by explicitly stating that recorded steps are preserved for export_flow, which is a non-obvious and valuable side effect. It does not detail what happens if no recording is active, but the disclosure of the key data-preservation behavior is sufficient for a simple zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: the main action is stated first ('Stop recording'), followed by a parenthetical that adds essential context without redundancy. Every word contributes meaning, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter mutation tool with no output schema and no annotations, the description fully covers the necessary information: what it does, what scope it applies to, and what happens to the data. The mention of 'export_flow' connects it to the overall workflow, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered and the baseline per rubric is 4. The description does not need to explain parameter syntax or meaning since there are none, and it correctly avoids adding unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop recording') with a specific resource and scope ('the current session'), and the parenthetical 'keeps recorded steps for export_flow' adds crucial differentiation from simply stopping an app. This unambiguously identifies what the tool does and distinguishes it from siblings like 'stop_app' and 'start_recording'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: after recording a session and before exporting, as indicated by 'keeps recorded steps for export_flow'. It does not explicitly mention alternatives or exclusions, but the workflow implication is strong enough to guide correct usage without additional wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels. It discloses the underlying mechanisms (OkHttp Frida hook, mitmproxy routing, CA trust), the side effect on macOS proxy and its restoration on stop, and the meaning of the filter regex. This is exemplary transparency beyond what annotations could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences, front-loaded with the primary action. It structure clearly separates general purpose from platform details, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (platform differences, prerequisites, side effects) and no output schema, the description is remarkably complete. It covers Android and iOS modes, requirements, filter syntax, and proxy restoration, leaving no critical operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying platform-specific requirements (app_id required on Android, optional on iOS), giving a filter example ('v2/search'), and explaining the spawn parameter. These enrich the schema's already explicit descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Capture decrypted HTTP, filtered to specific endpoints,' which is a specific verb+resource+scope. It clearly distinguishes from siblings like network_stop and network_mock by focusing on starting a capture with platform-specific methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: platform-specific prerequisites (Android requires debuggable app and frida-server; iOS uses mitmproxy) and filter semantics. It doesn't explicitly name alternatives, but the sibling names and detailed requirements make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryanperkins/Manos-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server