podium-mcp

by hoainho

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose. App management, device operations, Metro debugging, WebView interactions, gestures, assertions, and utilities are all well-separated with no overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores, e.g., app_install, crash_list, webview_inspect. No mixed conventions.
Tool Count2/5
With 43 tools, the server has far more than the typical 3-15 well-scoped range. While each tool is specialized, the count feels excessive and may overwhelm agents.
Completeness4/5
The tool surface covers a broad spectrum of mobile test automation tasks: app lifecycle, device control, gestures, assertions, Metro debugging, WebView interaction, and network capture. Minor gaps exist (e.g., no tool for clearing app data), but overall it is very comprehensive.
Average 4.1/5 across 43 of 43 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 37 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the action 'uninstalls' without describing side effects, permissions, or consequences (e.g., data deletion, simulator state requirements). This is insufficient for an agent to predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It is front-loaded with the verb and key identifier. Slightly more detail could be added without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain return values, error conditions, or behavioral context (e.g., whether the simulator must be booted). For a simple tool, some gaps are acceptable, but these omissions reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for udid and bundleId. The tool description adds the context of uninstalling by bundle ID, which aligns with the schema but does not add significant new semantics. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Uninstalls), the resource (app from an iOS simulator), and the method (by bundle ID). It effectively distinguishes from sibling tools like app_install and app_terminate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like app_terminate, nor are there any preconditions or exclusions mentioned. The description is purely definitional.
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 provided, so description carries full burden. It fails to disclose side effects (e.g., does it reset app state?), prerequisites (simulator must be booted), or error conditions (app not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence. No unnecessary words or repetition. Efficiently conveys core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low parameter complexity and no output schema, the description lacks important context for an action tool: prerequisites (simulator booted, app installed), potential errors, and behavior when conditions aren't met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds no extra meaning beyond what the schema already provides for 'udid' and 'bundleId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (launch), target (app on iOS simulator), and key parameter (bundle ID). It distinguishes from sibling tools like app_install or app_terminate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., app_install if app not installed, or device_boot if simulator not running). No prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the core action without disclosing side effects, requirements (e.g., simulator must be booted), or what happens if the app is not running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two simple parameters, the description is adequate but lacks context about prerequisites (e.g., simulator must be running) or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description mentions bundleId but not udid, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'terminates', the resource 'running app on iOS simulator', and the method 'by bundle ID'. It distinguishes the tool from siblings like app_install, app_launch, and app_uninstall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like app_uninstall or app_launch. The description implies it stops a running app but does not mention prerequisites or edge cases.
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, so description carries full burden. It states installation but does not disclose whether it overwrites, checks for existing app, requires simulator booted, or handles errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool, but lacks info on prerequisites, side effects, or success criteria, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description adds no new meaning beyond stating accepted formats, which is already covered in the path parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it installs an app on an iOS simulator and specifies accepted formats (.app or .zip), distinguishing it from sibling tools like app_launch, app_list, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for installing apps, but no explicit guidance on when to use versus alternatives, prerequisites, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It mentions the return type and fields, and discloses the error case when Metro is not running. However, it does not detail other behavioral aspects such as side effects, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action and return structure, and includes an important error condition. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the key aspects: what is listed, the specific fields returned (CDP-style targets with id, title, webSocketDebuggerUrl), and the error case. This is sufficient for an agent to understand usage and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'port', which is fully described in the schema. The description adds minimal extra parameter information beyond mentioning 'given port' in the error condition, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'React Native apps currently connected to a Metro bundler inspector,' and specifies the return fields (id, title, webSocketDebuggerUrl). While it does not explicitly distinguish from sibling tools like metro_logs or metro_network, the purpose is specific and distinct based on the resource and return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only describes the basic function without any contextual usage advice.
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 provided, description carries full burden. Basic action is clear but lacks details on side effects, error handling, or prerequisites. Neither sufficient nor misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource. No wasted words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with 2 parameters, but missing contextual info like prerequisite (device boot), return values, or failure modes. Not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters (udid, url) with descriptions. Description adds no additional meaning beyond what the schema provides. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (opens) and resource (URL on iOS simulator), with examples of URL types (deep-links, https). Distinguishes from siblings like webview_navigate which is for webviews in app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention that the simulator must be booted first or that webview URLs may need webview_navigate instead.
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, and the description lacks behavioral traits like destructiveness, authorization requirements, rate limits, or side effects. It only mentions the flow is 'ephemeral' but does not elaborate on behavior beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the action and mechanism, and the second details parameter requirements. No extraneous information, and important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain return values or outcomes (e.g., success/failure). It also omits prerequisites beyond required parameters. The description covers the basic gesture but is incomplete for edge cases or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter descriptions. The description adds value by clarifying that coordinate parameters are optional overrides and providing format examples (e.g., '10%,50%' or pixel values), enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the action 'Swipes in a direction or between two coordinates via an ephemeral Maestro flow,' which clearly identifies what the tool does and its mechanism. This distinguishes it from sibling tools like tap_on or press_key, which perform different gestures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool vs alternatives, such as tapping or scrolling. It mentions direction is required and coordinates are optional overrides, but does not specify appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses matching rules (exact bundle-id for installed, token boundary for running) and mentions no prefix false positives. However, does not disclose what the output looks like, error behavior, or any side effects. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides critical functional detail. No redundancy or filler. Front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and matching logic, but omits description of return format or values. Since no output schema exists, the description should provide this information to be fully complete. Adequate but leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters concisely (udid and bundleId). Description adds no additional parameter-level semantics beyond the schema's own descriptions. Baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'checks' and resource 'app on iOS simulator'. Distinguishes from sibling tools like app_install or app_list by specifying it checks both installed and running states. The detailed matching criteria further clarify the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for checking app state, but no explicit guidance on when to use it versus alternatives like app_list or other inspection tools. No when-not-to-use or context provided.
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 reveals the mechanism ('ephemeral Maestro flow') and platform limitation (iOS only). It lists valid keys but does not disclose side effects (e.g., pressing home exits app) or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, the second adds a critical caveat. It is front-loaded, concise, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (3 required) and no output schema or annotations. The description covers the main behavior and a key platform limitation, but lacks details on error conditions, prerequisites (e.g., device must be booted), or what happens on failure. It is minimally complete for a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the Android key caveat and the purpose of noLaunch, but does not elaborate on timeoutMs or other parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Presses'), the resource ('hardware or system key'), and the context ('via an ephemeral Maestro flow on the iOS simulator'). It distinguishes from sibling tools (e.g., tap_on, swipe) by specifying it deals with hardware/system keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that back/power/tab are Android key events with no effect on iOS, providing partial guidance on when not to use certain keys. However, it does not explicitly state when to use this tool vs. alternatives like tap_on or input_text.
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 exist. The description indicates a read-only operation and states the required condition (booted simulator). However, it doesn't disclose error handling or behavior when the simulator is not booted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the core action and includes key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description adequately covers the return fields and precondition (booted simulator). Could mention error scenarios but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'udid' with a description. The tool's description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns the list of installed apps on a booted iOS simulator' with specific fields. This distinguishes it from sibling tools like app_install, app_launch, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance is provided. The usage is implied by the tool's purpose, but it doesn't mention when to choose app_list over other listing 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?
No annotations provided, so description carries the burden. It mentions polling, timeout, and failure on timeout, but lacks details on return value, side effects, or the 'oracle ladder' behavior. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with the essential operation. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (6 params, no output schema, no annotations), the description plus detailed schema provide adequate completeness. Could add more context about surface-specific parameter usage, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no extra nuance about parameter selection or usage beyond what the schema provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it polls until an element/text is visible (specific verb and resource) and distinguishes from a blind sleep but does not differentiate from siblings like assert_visible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to act the instant the UI is ready instead of a blind sleep,' providing clear context. However, it does not mention when not to use it or alternatives (e.g., assert_visible).
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 mentions 'Same oracle ladder + unverifiable handling', which hints at underlying behavior but does not fully disclose what happens on failure, side effects, or timing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences that are both informative and relevant. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks details like what happens on pass/fail, error messages, or clarification of 'unverifiable handling'. Without annotations or output schema, the description could be more complete, though it covers the core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so the baseline is 3. The description does not add significant meaning beyond the schema; it provides high-level context (shorthand for assert_visible) but no parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'asserts' and the resource 'text visible on screen', and distinguishes itself as a shorthand for assert_visible. This differentiates the tool from its sibling assert_visible and provides a specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is a shorthand for assert_visible, implying it is used when wanting to assert by text rather than other selectors. However, it does not explicitly state when not to use it or provide alternatives beyond the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a fallback behavior (deriving orientation from screenshot when native backend is unavailable) and implies a read-only operation. It does not mention any side effects, return format, or error cases, but the disclosed fallback is a valuable behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose is front-loaded, and the fallback detail is provided efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema), the description is mostly complete. It explains the fallback behavior, which is a key detail. However, it does not specify the format of the returned orientation (e.g., string like 'portrait' or 'landscape'), which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage with 'Simulator UDID'. The tool description does not add any additional meaning or constraints beyond that. Baseline 3 is appropriate as the schema already explains the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the current orientation of a booted iOS simulator. The verb 'Returns' and specific resource 'current orientation' leave no ambiguity. The sibling tool 'orientation_set' implicitly differentiates the get vs set use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use or not use this tool versus alternatives. It explains the underlying method (native backend vs screenshot) but lacks guidance on prerequisites or when to prefer one over the other. The use case is implied but not explicitly contrasted with 'orientation_set'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: sends SIGINT, waits for file size stabilization, returns path/size. However, does not mention behavior if no active recording or error cases. With no annotations, this is strong but not fully thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with the main purpose first. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the workflow and return value well for a simple tool. Lacks details on failure handling and idempotency, but overall sufficient given the tool's simplicity and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes 'udid' as 'Simulator UDID' adequately. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops an active screen recording for an iOS simulator, specifying the resource and action. It distinguishes from the sibling 'record_start' by being its counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage after starting a recording, but does not explicitly mention when not to use (e.g., if no active recording) or provide alternatives. Adequate but lacks guidance on preconditions.
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 discloses the output format and design decision to avoid base64, but omits details like whether it overwrites existing files, permissions needed, or if the simulator must be booted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (file path and byte size) and default behavior. It could mention error conditions or prerequisites, but is still mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the default save location details (os.tmpdir()), which goes beyond the schema's 'Defaults to a tmp file.' This extra context helps the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a screenshot of an iOS simulator, which is a specific verb+resource. Among siblings like inspect_screen, this tool uniquely captures a full screenshot image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (returns file path, not base64, default save location) but does not explicitly state when to use this tool versus alternatives like inspect_screen or tap_on. Usage 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?
The description discloses the internal behavior of taking a temporary screenshot and using sips to read dimensions, providing transparency beyond what annotations would cover. However, it does not mention potential side effects like temporary file creation or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, efficiently conveying the tool's purpose and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely complete, but it omits the prerequisite of the simulator being booted and details about the return format or units of the dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the only parameter (udid) with a basic description. The description adds no additional meaning or context for the parameter beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('returns'), the specific resource ('pixel dimensions of a booted iOS simulator screen'), and the method. It distinguishes this tool from siblings like 'screenshot' by specifying that it extracts dimensions rather than capturing an image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting screen dimensions but does not explicitly state when to use this tool versus alternatives (e.g., orientation_get). It lacks guidance on prerequisites (e.g., simulator must be booted) and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the location is simulated and for testing, but lacks details on side effects (e.g., persistence, prerequisites). This moderate transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, the first stating the action and the second providing context. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (setter, no output schema), the description covers purpose and usage context adequately. It could mention error handling (e.g., simulator not running), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%, so the schema already documents the three parameters. The description does not add new meaning beyond schema descriptions, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Sets the simulated GPS location on a running iOS simulator', providing a specific verb and resource. It also adds context about the QA use case, distinguishing it effectively from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('unblock location-gated features during QA testing without moving the physical device'), giving clear usage context. It does not mention explicit alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that the tool evaluates JS and returns results, and warns about inspectability requirements. However, it does not disclose potential side effects of JS evaluation, error handling, or whether the operation is synchronous. This is adequate but leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct yet informative, consisting of two sentences that front-load the core functionality and then provide context on when it works. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description clarifies that the tool 'returns the result' and gives examples of use cases. It covers the key aspects of what the tool does and its limitations (inspectability). A minor gap is not describing error behavior for invalid expressions, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, so schema coverage is 100%. The description does not add significant parameter-level detail beyond the schema, but it does provide example expressions which help illustrate usage. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Evaluates') and resource ('JavaScript expression in a WebView's page context'). It provides specific examples like location.href and DOM queries, and the tool is clearly distinguished from siblings such as webview_navigate and webview_inspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('read web-app state' or 'assert conditions against the live DOM') and notes a critical prerequisite (inspectable WKWebView) with context about build variants. It does not explicitly mention alternatives but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the inspectable requirement, which is a key behavioral trait, and notes it's often disabled in production builds. However, it omits error handling or failure behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently worded sentences with no unnecessary information. The core action and critical precondition are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a navigation tool with 4 parameters and no output schema, the description covers main actions and a key precondition. It lacks details on return values or error states, but is largely adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it repeats that 'goto' requires 'url' and mentions auto-selection of webviewId, but doesn't elaborate on parameter types or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drives WebView navigation with specific actions (goto, back, forward, reload) and distinguishes itself from sibling tools like webview_eval and webview_inspect by focusing on navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing actions and mentions a critical requirement (inspectable WKWebView), but does not explicitly state when to use this tool versus alternatives or exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden of behavioral disclosure. It details the tap location (50,850), the backend order (idb else Maestro), the screenshot comparison method, and explicitly notes the heuristic nature and potential unreliability. This is thorough and honest about limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences covering purpose, mechanism, and caveats. It is front-loaded with the primary action and structured logically. While every sentence earns its place, the note about the heuristic slightly extends the length; however, it is necessary for transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and absence of an output schema, the description provides adequate context. It explains the tool's goal, method, and limitations (heuristic, device-specific). No return value is described, but that is acceptable without an output schema. The description could include a note about potential side effects (e.g., accidental taps), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds value by explaining that 'bundleId' is only used for the Maestro fallback and can be auto-detected, which provides context beyond the schema's 'App bundle id for the Maestro fallback' description. For 'udid', no additional meaning is added, but the overall contribution justifies above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to dismiss the React Native debug notification bar. It specifies the action ('dismiss'), the target resource ('debug notification bar'), and the context ('appears at the bottom of the screen and intercepts taps'). This distinguishes it from sibling tools like tap_on or tap_with_fallback, which are generic 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when the debug notification bar appears), but it does not provide explicit guidance on when not to use it or suggest alternatives. For example, it does not mention that other tools should be used for non-debug bars or general interactions. The context is clear but lacks comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the transparency burden. It discloses auto-discovery behavior, app selection reporting, and file saving. However, it omits prerequisites (e.g., app must be connected) and side effects, and does not detail output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the core purpose. Every sentence adds value without redundancy, making it efficient for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema, the description covers main functionality, auto-discovery, and save option. However, it lacks details on output format, error handling, and prerequisites, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that omitting webSocketDebuggerUrl triggers auto-discovery and that saveTo writes a timeline file for evidence, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads console logs from a React Native app via Metro CDP debugger. It specifies the verb 'reads' and the resource 'console logs', distinguishing it from sibling tools like metro_network and metro_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using auto-discovery vs. providing a URL, and mentions the optional saveTo parameter for evidence. However, it does not explicitly compare this tool to siblings or state when not to use it.
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 use of Runtime.evaluate with returnByValue, auto-discovery, and the need for global exposure. However, it does not explicitly state whether the evaluation is read-only or note potential side effects from custom expressions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each providing essential information. The first sentence states the core action and mechanism; the second explains customization; the third covers prerequisites and auto-discovery. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that evaluates an expression and returns a value, the description covers key aspects: input parameters, default behavior, auto-discovery, and prerequisites. It lacks explicit mention of the output format but that is implicit. Error handling or failure modes are not discussed, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The tool description adds value by explaining the default expression behavior, auto-discovery for webSocketDebuggerUrl, and practical examples for expression. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads app state by evaluating a JS expression via Metro CDP debugger. It specifies the default expression (Redux store) and overridability. It distinguishes itself from siblings like metro_apps by mentioning auto-discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to read app state or any in-app value via expression override) and mentions auto-discovery via metro_apps. It does not explicitly state when not to use, but context and sibling differentiation are clear.
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; description mentions 'ephemeral Maestro flow' hinting at temporary change, but lacks detail on side effects, permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no fluff, front-loading the action and adding key parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description sufficiently covers purpose, parameters, and valid values for a simple setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters; description adds context that bundleId is required for Maestro appId header, enhancing beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets screen orientation on an iOS simulator via Maestro flow, with explicit valid values. Distinguishes from sibling orientation_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context: set orientation vs get orientation from sibling. Does not explicitly state when-not or alternatives, but purpose is clear.
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?
Discloses that recording runs in a detached background process, adding behavioral context beyond the schema. No annotations provided, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description implies no immediate output; return file via record_stop. Complete enough given simplicity and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. Description adds no extra meaning beyond schema defaults (e.g., saveTo default tmp file). Adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a screen recording on a booted iOS simulator, with a specific verb and resource, distinguishing it from sibling record_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call record_stop to finalize and retrieve the file, indicating proper usage sequence. Lacks explicit when-not-to-use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly discloses that lossy steps (coordinate tap/swipe, focused-field type, regex tapText) are emitted as commented '# TODO[unstable]' lines plus a warnings[] list, never silently excluded. This is excellent transparency about edge cases and output 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is informative but slightly verbose with phrases like 'the engineer→QA bridge'. It front-loads the main purpose and is mostly clear, but could be more concise. Overall efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output format (commented lines for lossy steps, warnings list) and transpilation behavior for selector-based steps. It covers major behavioral aspects but does not mention prerequisites or limitations beyond what schema implies. Completeness is good but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters ('bundleId' and 'steps') are fully described in the input schema with detailed descriptions. The description adds no new parameter-specific information beyond what is already in the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool exports a run_steps action sequence to a reusable Maestro flow, specifying it as an 'engineer→QA bridge'. This verb+resource combination is specific and distinguishes it from sibling tools like run_flow, run_steps, and validate_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you want to convert a run_steps sequence into a durable Maestro flow. It mentions that lossy steps become TODOs, hinting at needed remediation. It does not explicitly state when not to use or compare to alternatives, but the context makes it reasonably clear.
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 key behaviors: the fallback between idb and maestro, the default compact mode behavior, and the WebView opacity limitation. No annotations are provided, but the description compensates well. It does not cover authentication or rate limits, but these are not critical for a read-only hierarchy tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, then detailing parameters, and finally noting limitations. Every sentence serves a purpose, though it could be slightly more concise by removing redundant phrases like 'dramatically smaller'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description adequately explains the output format (flattened list vs full tree) and the key limitation. It does not specify the exact format (e.g., JSON or XML), but for an agent, this is sufficient to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond the schema: it explains the default value of compact (true), what the compact mode does (flattened list of meaningful nodes), and provides a practical size comparison. This helps the agent understand the impact of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns the current view hierarchy for a booted iOS simulator, specifying the platform (podium's target platform) and the underlying methods (idb or maestro). This clearly distinguishes it from sibling tools like screenshot or screen_size, which deal with visual representations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use compact:true vs false, and addresses the WebView limitation by advising an alternative approach (screenshot + coordinate calculation). It does not explicitly list when not to use the tool, but the context is clear enough for an agent to make correct decisions.
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 fully discloses key behaviors: auto-discovery, request/response pairing by requestId, redaction of sensitive headers by default, and format differences. It warns about not committing unredacted HAR. Missing details on rate limits or what happens if no app is connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with front-loaded core purpose. Every sentence adds value: pairing, format, redaction, save. Could be slightly more concise, but information density is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description covers all parameters meaningfully, explains output (HAR-lite), and includes safety warnings. It lacks detailed structure of 'json' output but mentions method, url, status, headers, timing, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds substantial meaning beyond the schema: explains auto-discovery for webSocketDebuggerUrl, defaults for port/duration/maxEntries, that format 'har' emits HAR-lite, redact default true, and saveTo for writing files. This enriches understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Captures network requests from a React Native app via the Metro CDP debugger (Network domain)', specifying the action and resource. It distinguishes from siblings like metro_apps (list apps) and webview_network (webview context), as seen in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: auto-discovery when webSocketDebuggerUrl omitted, pairing of requests, format options, and a warning not to commit unredacted HAR. However, it does not explicitly mention when not to use this tool versus alternatives like webview_network.
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. It explains that the tool lists WebViews, resolves a CSS selector, returns tap coordinates, defaults to interactive elements, and requires isInspectable=true. This is adequate for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and then provides context. It is informative without wasted sentences, though slightly lengthy. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers the core functionality, prerequisites, default behavior, and what the tool returns. It is fairly complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the overall purpose, how parameters interact (e.g., webviewId optional, max default), and the default selector for interactive elements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists embedded WebViews and resolves a CSS selector to DOM elements with absolute on-screen tap coordinates. It distinguishes itself from coordinate tools by solving the 'WebView content is opaque' limitation, differentiating it from siblings like inspect_screen and tap_on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use: for inspecting WebViews when coordinate tools fail due to opaque content. It notes the prerequisite that WKWebView must be inspectable. However, it does not explicitly mention alternatives for native UI or when not 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, description fully carries burden. Discloses truncation (first ~8000 chars, truncated flag), path-traversal safety, and optional udid resolution. Adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. Front-loaded with primary action, then adds necessary details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains output for .ips files and safety. With only 2 params, this is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but description adds value by clarifying 'id' is from crash_list and 'udid' enables sim-container resolution. Goes beyond mere schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Reads' and resource 'crash report', links to sibling crash_list, and clearly identifies input as filename from that list. Purpose is unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to pass udid (to resolve sim-container reports) and describes truncation behavior for .ips files. Does not explicitly state when not to use, but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses directories scanned, sorting order, filtering behavior. No annotations provided, but description fairly covers behavioral aspects for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first covers main function, second adds key filtering details. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes inputs and behavior adequately for a list tool. No output schema, but return format is implicit. Incomplete only in not describing output structure, but acceptable given sibling crash_get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context about udid expanding search to simulator container and sorting order, beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists crash reports from a specific directory, sorted newest first, with filtering. Distinguishes from sibling crash_get by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (to browse crashes) and filtering options, but no explicit mention of when not to use or alternatives beyond sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it returns health status, mentions toolchain availability, and notes the limitation regarding Android devices. It does not describe the return format but adequately covers behavioral traits for a read-only health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the core functionality, and the second adds scope 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is fairly complete. It explains what the tool returns and its scope limitations. Could elaborate on 'toolchain availability' but is adequate for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds context about the tool's purpose and scope, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns health status of the server and toolchain availability. It also distinguishes itself from siblings by being a health check tool, while siblings are for app management, device control, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use it (to check health status) and provides scope context (iOS simulators only). However, it does not explicitly state when not to use it or provide alternatives, though no sibling serves this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals that WebView taps report COMPLETED without effect, explains the noLaunch param to avoid disturbing modals, and notes required bundleId. While it covers key traits, it could be more explicit about state requirements and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the main action and targeting methods, then adds critical warnings. Every sentence serves a purpose with no redundancy, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers key aspects: action, targeting, required parameters, and a notable false-completion scenario. However, it lacks an explicit statement of return values or error handling, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining text matching behavior (anchored regex, fallback to substring), emphasizing bundleId necessity, and clarifying double/long press modes. This extra context raises the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: tap, double-tap, or long-press on-screen elements via an ephemeral Maestro flow. It specifies targeting methods (text/regex, accessibility id, coordinates) and distinguishes from siblings by covering multiple tap modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: bundleId is required, and WebView content requires coordinates as text/id selectors fail. However, it does not directly compare to sibling tools like tap_with_fallback or swipe, leaving some usage context implicit.
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?
Despite no annotations, the description thoroughly discloses the oracle ladder (WebView-DOM > native a11y > Maestro; fail-closed), the three health checks (crashes, Metro logs, network errors), and the strict condition for ok=true. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the purpose, then efficiently explains the mechanism and conditions. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more explicit about the return format (e.g., JSON structure of verdict and evidence). However, it sufficiently covers inputs, process, and success criteria. Minor gap on error handling or timeout behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add specific meaning to individual parameters beyond what the schema already provides; it only contextualizes their use in the overall process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a verdict on whether a flow works, specifying the combination of visibility assertions and auto-checks. It uses specific verb 'validates' and distinguishes from simpler sibling tools like assert_visible by describing a higher-level, evidenced validation process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'State the expected outcome as assertions' and frames the tool as making the AI's work auditable, implying use after flow implementation. However, it lacks explicit guidance on when not to use or direct alternatives among siblings.
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?
Discloses that it returns an offline copy of the cheat sheet. No annotations are provided, but the description implies a read-only operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that covers purpose and usage without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides all necessary context: what it returns and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the description does not need to explain them. According to guidelines, zero parameters warrant a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a cheat sheet for Maestro flow scripts, specifying the content (commands, required args, nested properties, conditionals, multi-screen flows). This distinguishes it from all sibling tools which are action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises consulting this before authoring unfamiliar Maestro commands, providing a clear when-to-use. It does not explicitly state when not to use, but the context of siblings implies it is for reference, not execution.
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?
Discloses important behavioral details: waits up to 30 seconds, idempotent behavior, and response with alreadyBooted:true. With no annotations, the description carries the full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words, front-loading the main action and then adding key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return behavior (alreadyBooted:true). Also covers timeout and idempotency, making it complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers param fully (100% coverage) but description adds no extra meaning beyond referencing 'from device_list', which is already in schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Boots an iOS simulator by UDID'), distinguishing it from sibling tools like device_list which lists devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context (30s wait, idempotent) but does not explicitly state when to use or when not to use this tool compared to siblings. However, given the sibling set focuses on other operations, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral trait: fails closed with an 'unverifiable' error instead of a false pass. Describes conditions for failure (e.g., WebView with unreadable DOM). No annotations provided, so description fully addresses behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential. First states purpose, second adds critical failure mode. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral nuances (fails closed, verification conditions) for a moderately complex tool with 6 parameters and no output schema. Slight gap: does not describe the success/error return format, but error behavior is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context for some parameters (e.g., 'native a11y / WebView innerText' for text) but does not significantly augment beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool asserts an element/text is absent. Provides specific behavior (FAILS CLOSED) and distinguishes from sibling tools like assert_visible and assert_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when the tool will fail (unverifiable absence) and passes only when a capable oracle confirms absence. Implicitly guides when to use vs alternatives.
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?
Discloses the oracle ladder, the 'unverifiable' error for non-inspectable WebViews, and substring matching behavior for WebView innerText, all beyond what annotations (none provided) would cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences front-load the core action and add necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behaviors and parameter guidance, but lacks explicit return value description or comparison with assert_text. No output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining oracle ladder, error behavior, and clarifying that WebView text is always substring despite the 'contains' default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it asserts visibility of an element/text via a specific oracle ladder, differentiating it from siblings like assert_not_visible and assert_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (text or selector) and describes behavior for unverifiable WebViews, but does not explicitly exclude alternatives or compare with assert_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It details fallback behavior, verification mechanisms, oracle field, conditions for each oracle type, and offsetStep behavior. Very transparent about potential issues like animation affecting screenshot verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information but every sentence adds value. It is front-loaded with the main purpose and fallback. Slightly long but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (fallback, verification, oracle) and no output schema, the description covers return value ('oracle' field) and all crucial aspects. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds significant value beyond schema: explains bundleId auto-detection, offsetStep default behavior (no blind walk), maxRetries default, and verification context for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends a raw coordinate tap via native backend with fallback, specifies use for WKWebView game overlays where visual position differs from DOM hit-test, and distinguishes from sibling tools like 'tap_on'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use (WKWebView overlays) and mentions verification details. Lacks explicit 'when not to use' but points to alternative 'webview_inspect' for WebView targets.
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 fully discloses behavior: it returns a merged list, gracefully handles missing adb, and clarifies Android is detection-only. This covers key behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Information is front-loaded with the main purpose, then caveats and limitations are added efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description sufficiently explains what the tool returns (iOS and Android fields) and important caveats (adb handling, Android automation limitation). No further information is needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so description does not need to add param meaning. Baseline 4 applies as schema coverage is 100% and no param details are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a merged inventory of iOS simulators and Android devices, specifying included fields (udid, name, state, runtime) and handling of missing adb. This distinct purpose differentiates it from sibling tools which are automation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use (to list devices) and notes that Android entries are detection-only and not usable with podium's automation tools, providing context for Android limitations. It lacks explicit mention of alternatives for Android automation but is otherwise clear.
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 full burden. It discloses a critical trust boundary: flows can run arbitrary JS and local files, alerting about security. It doesn't detail other behaviors like output or side effects, but the primary behavior is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise with no wasted words. It front-loads the core action and constraints, then adds usage guidance and a security note. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an execution tool with 8 parameters, the description covers input constraints well. It doesn't mention return values or error handling, but the tool likely outputs to stdout/logs, which may be assumed. The trust boundary note adds important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the mutual exclusivity of yaml/files/dir and applicability of tags only with dir. Also notes yaml is preferred for exploration. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes Maestro flows on a device, with specific verbs and resource. It distinguishes from sibling tools like run_steps and individual gesture tools by noting when each is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to provide exactly one of yaml, files, or dir, and clarifies that includeTags/excludeTags only apply to dir. Provides clear guidance on when to use this tool vs run_steps or individual gesture tools.
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?
Discloses key behaviors: native backend with Maestro fallback, stops on first error unless stopOnError:false, bundleId auto-detection, WebView limitations for tapText, real keystrokes for type. No annotations present, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded with core purpose and value, followed by action list, tips, and usage guidance. Though lengthy, each sentence serves a purpose; could trim minor redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many step types, no output schema), the description is comprehensive: covers all actions, edge cases (WebView), error behavior, and timing recommendations. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters (100% coverage), so baseline 3. Description adds value with context: bundleId auto-detection, stepDelayMs optional, stopOnError default true, and succinct explanations for each action type in the steps array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes an ordered batch of UI actions in one call for fast continuous flows, and distinguishes from siblings like run_flow and individual gesture tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use vs alternatives: use run_steps for >2 known sequential gestures, run_flow for assertions/retries, individual tools for single exploratory actions. Also includes best practices like preferring waitFor over waitMs.
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?
Given no annotations, description fully discloses behavioral traits: injection mechanism, capture duration, recording only after start, redaction of sensitive data, HAR format validation, and inclusion of performance resource timing. Also warns about not committing unredacted HAR.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but every sentence adds value. Well-structured with clear main purpose first, then context, then parameter details. Could be slightly tighter, but no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations and no output schema, description covers behavior, parameters, output format, side effects, prerequisites, and security warnings. Thoroughly explains the tool's role in the debugging workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value beyond schema: explains default for redact, clarifies includeResources behavior, details format:'har' usage and saveTo, and provides context for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it captures HTTP traffic from WebView and exports as JSON or HAR. Distinguishes from sibling metro_network, which uses CDP and doesn't work for WebView-based apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (WebView-based apps like RN shells) and when not (metro_network instead). Also mentions requirements: WKWebView inspectable and debug/staging builds.
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?
No annotations are provided, so description carries full burden. It discloses Android Unicode limitation, WebView caveat (React onChange not firing), and the ephemeral Maestro flow nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences covering core function, option, and two key caveats. No redundancy, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool without output schema, the description covers purpose, usage guidelines, behavioral caveats, and parameter nuances completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context beyond schema: explains noLaunch to avoid implicit launch, and that submit triggers Enter. Adds meaning to text and submit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool types text into the currently-focused element, uses a specific verb 'types', and distinguishes from sibling tool mobile_type_keys for WebView forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use an alternative: 'For WebView forms use mobile-mcp mobile_type_keys instead.' Also explains the submit parameter and the noLaunch parameter's purpose.
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:

[![podium-mcp MCP server](https://glama.ai/mcp/servers/hoainho/podium-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hoainho/podium-mcp)

Score Badge

Copy to your README.md:

[![podium-mcp MCP server](https://glama.ai/mcp/servers/hoainho/podium-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hoainho/podium-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoainho/podium-mcp'

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