Server Quality Checklist

Tool Scores

• boot_simulatorC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Boot') but doesn't explain what booting entails (e.g., starting a simulator instance, potential delays, or system requirements), whether it's idempotent, or what happens on failure. This leaves significant gaps for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool with one parameter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, or expected outcomes, which are crucial for an agent to use this tool effectively in context with 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?

  The schema description coverage is 100%, with the parameter 'udid' fully documented in the schema as 'Simulator UDID to boot'. The description adds no additional meaning beyond this, so it meets the baseline score of 3 where the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Boot') and target resource ('an iOS simulator by UDID'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_simulators' or 'launch_app' which might be related to simulator management, so it doesn't reach the highest score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid UDID from 'list_simulators'), exclusions, or how it relates to other simulator operations like 'launch_app' or 'terminate_app'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_elementsC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions searching UI elements but doesn't disclose critical traits like whether this is read-only (implied but not stated), performance considerations, error handling, or output format (e.g., list of elements). This leaves gaps for safe and effective use.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Search the UI tree for elements') and specifies the search criteria concisely, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations and no output schema, the description is incomplete for a search tool. It lacks details on behavioral aspects (e.g., read-only nature, result format) and doesn't compensate for the absence of structured output information, leaving the agent uncertain about what to expect from the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying the 'query' searches across labels, values, and hints, which is already covered in the schema's description for 'query'. Baseline 3 is appropriate as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Search') and target ('UI tree for elements'), specifying the search criteria ('label, value, or hint contains query text'). It distinguishes from siblings like get_ui_tree (which retrieves the entire tree) or tap_text (which interacts with text), but doesn't explicitly differentiate from hypothetical similar search tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator or launched app), exclusions, or comparisons to siblings like get_ui_tree for broader inspection or tap_text for direct interaction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_screen_summaryC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'token-saving options' but does not explain what this entails (e.g., how compact_tree reduces tokens, implications of only_if_changed). It lacks details on permissions, rate limits, error handling, or what the output looks like (UI tree format, image data). For a tool with 7 parameters and no annotations, this is insufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the core purpose ('Get screen context') and adds a key feature ('with token-saving options'). There is no wasted verbiage or redundancy, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It does not explain the output format (e.g., structure of UI tree, image encoding), error conditions, or how token-saving options affect behavior. For a tool that retrieves screen context with multiple configuration options, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds no additional semantic context beyond implying token optimization via 'compact_tree' and 'only_if_changed', but it does not explain parameter interactions or usage scenarios. Baseline 3 is appropriate as the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Get screen context (UI tree and optional screenshot)' which specifies the verb ('Get') and resource ('screen context'). It distinguishes itself from siblings like 'get_ui_tree' and 'take_screenshot' by offering both UI tree and screenshot capabilities with token-saving options, though it could be more explicit about the differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides minimal guidance on when to use this tool. It mentions 'token-saving options' but does not specify when to choose this over alternatives like 'get_ui_tree' or 'take_screenshot', nor does it outline prerequisites or exclusions. No explicit when/when-not or alternative recommendations are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_ui_treeC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify permissions, rate limits, side effects, or what 'full' entails (e.g., depth, format details). This is insufficient for a tool with no annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the structure or content of the returned JSON, potential errors, or how it relates to sibling tools. For a tool that retrieves complex UI data, more context is needed to guide effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with the single parameter 'udid' documented in the schema as optional and defaulting to the booted simulator. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get') and the resource ('full accessibility/UI tree as structured JSON'), making the tool's function understandable. However, it doesn't differentiate from siblings like 'get_screen_summary' or 'find_elements', which might also retrieve UI information, so it lacks sibling distinction for a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as 'get_screen_summary' or 'find_elements'. It mentions no prerequisites, exclusions, or specific contexts, leaving the agent to infer usage from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• launch_appC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Launch') but lacks details on permissions, side effects (e.g., if it affects other apps), error handling, or what happens if the app is already running. This is inadequate for a mutation tool with zero annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It doesn't explain behavioral traits, return values, or error conditions, leaving gaps that could hinder an AI agent's ability to use it correctly in context with siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters (bundle_id and udid). The description adds no additional meaning beyond implying the tool uses these parameters, which meets the baseline for high schema coverage without compensating value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Launch') and the target ('an app on a simulator'), which is specific and unambiguous. However, it doesn't distinguish this tool from sibling tools like 'boot_simulator' or 'terminate_app' in terms of scope or relationship, missing explicit differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), exclusions, or how it relates to siblings like 'boot_simulator' (for starting the simulator) or 'terminate_app' (for stopping apps), leaving usage context unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swipeC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks critical details: it doesn't specify if this gesture simulates user input on a UI, mention any side effects (e.g., triggering app navigation), describe error conditions (e.g., invalid coordinates), or note performance aspects like execution time. This leaves significant gaps for an agent to understand 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('perform a swipe gesture') and specifies the key aspect ('from one coordinate to another'), making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a gesture-based interaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success status, error messages), behavioral nuances like coordinate system origin or bounds, or integration with sibling tools (e.g., requiring a booted simulator). This leaves the agent with incomplete context for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% description coverage, clearly documenting all six parameters (coordinates, duration, and UDID) with their types and purposes. The description adds no additional parameter semantics beyond implying coordinate-based movement, which is already covered by the schema. This meets the baseline score since the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('perform a swipe gesture') and specifies the movement ('from one coordinate to another'), making the purpose evident. However, it doesn't differentiate this tool from similar sibling tools like 'tap' or 'press_button', which would require mentioning it's specifically for continuous touch movement across coordinates.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'tap' (for single-point touches) or 'press_button' (for button interactions). It also doesn't mention prerequisites such as needing a simulator to be booted or an app to be launched, which are implied by sibling tools but not explicitly stated here.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• type_textC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It mentions typing into a focused element but doesn't disclose behavioral traits like whether it simulates keystrokes, handles special characters, requires the simulator to be running, or what happens if no element is focused. This leaves significant gaps for an agent to understand 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the main purpose, making it easy to parse and understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't cover important aspects like error conditions, return values, or detailed behavioral context (e.g., interaction with simulator state). For a tool that interacts with a UI simulator, more guidance is needed to ensure proper usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, with clear descriptions for both parameters ('text' and 'udid'). The description doesn't add any meaning beyond the schema, such as examples or constraints, but the schema itself is sufficient. This meets the baseline for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('type text') and target ('currently focused element on the simulator'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'tap_text' or 'press_button', which might also involve text input in some contexts.

  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 minimal guidance, stating only that it types into the 'currently focused element'. It doesn't explain when to use this versus alternatives like 'tap_text' (which might tap text elements) or 'press_button' (which could simulate keyboard input), nor does it mention prerequisites such as needing a focused element or simulator state.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• press_buttonB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose effects (e.g., state changes in the simulator), error conditions, or any constraints like simulator readiness, leaving significant gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero wasted words, front-loading the core action. It's appropriately sized for a simple tool with well-documented parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no annotations and no output schema, the description is minimal but covers the basic purpose. However, it lacks details on behavioral impact and usage context, making it incomplete for guiding an agent in complex scenarios, though adequate for straightforward use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying hardware button interaction, which is already clear from the enum values. Baseline 3 is appropriate as the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('press') and target ('hardware button on the simulator'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'tap' or 'swipe' that also involve simulator interactions, missing explicit distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like 'tap' or 'swipe', nor does it mention prerequisites such as needing a booted simulator. The description lacks context for tool selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tapB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action ('Tap') but doesn't clarify what happens after tapping (e.g., UI response, error handling), whether it requires a booted simulator, or any side effects like app state changes. This leaves significant gaps for a tool that interacts with a simulator.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (simulator interaction), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic action but misses behavioral details like error conditions or simulator state requirements, which are important for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters (x, y coordinates and optional udid). The description adds no additional meaning beyond implying coordinate-based tapping, which aligns with the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Tap') and target ('at specific (x, y) coordinates on the simulator screen'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish from sibling tools like 'tap_id', 'tap_relative', or 'tap_text', which offer alternative tapping methods.

  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 'tap_id' (tapping by element ID), 'tap_relative' (tapping relative to screen dimensions), or 'tap_text' (tapping by text content). The description only states what the tool does, not when it's appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_simulatorsB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool lists simulators and their states, but lacks details on output format (e.g., JSON, list), pagination, error handling, or performance characteristics (e.g., speed, rate limits). This leaves gaps for an agent to understand how to interpret results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to scan and understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It covers what the tool does but lacks details on output format or behavioral traits, which could hinder an agent's ability to use it effectively without additional context or trial-and-error.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here, earning a baseline score above 3 due to the lack of parameters to explain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and resource ('iOS simulators'), with the specific detail of including state information. It distinguishes itself from siblings like 'boot_simulator' by focusing on listing rather than modifying, though it doesn't explicitly contrast with other read-only tools like 'get_screen_summary'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing Xcode installed), compare to other listing tools, or indicate scenarios where this is preferred over other simulator-related operations among the siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• take_screenshotB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional compression and unchanged-image suppression, which adds some context beyond basic functionality. However, it lacks critical details: it doesn't specify what happens on success (e.g., returns image data), error conditions, permissions needed, or side effects (e.g., whether it affects simulator state). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the core action ('Take a JPEG screenshot') and concisely adds key optional features. Every word earns its place, with no redundancy or fluff, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (a 5-parameter tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return value (e.g., image data or error), error handling, or dependencies on other tools (e.g., requiring a booted simulator). While the schema covers parameters well, the lack of behavioral and output information leaves the agent without sufficient context for reliable use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema: it references 'optional compression' (mapping to quality parameter) and 'unchanged-image suppression' (mapping to only_if_changed and previous_image_hash), but doesn't provide additional syntax, format, or usage context. This meets the baseline for high schema coverage, where the description isn't needed for parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Take a JPEG screenshot') and distinguishes it from siblings by focusing on image capture rather than simulator control, UI interaction, or app management. It specifies the output format (JPEG) and key optional behaviors (compression, unchanged-image suppression), making the purpose unambiguous and distinct from tools like get_screen_summary or get_ui_tree.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), compare it to siblings like get_screen_summary (which might provide textual data instead of images), or specify scenarios where screenshot capture is appropriate over other UI inspection tools. Usage is implied only by the tool's name and purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tap_idA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (find and tap) but does not mention potential side effects (e.g., app state changes), error conditions (e.g., if element not found), or performance considerations. It adds minimal context beyond the basic action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it easy to understand quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (interactive UI action), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, errors, or output, which could be important for an AI agent to use it correctly in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both parameters ('id' and 'udid') fully. The description does not add any meaning beyond what the schema provides, such as examples or usage nuances, but the baseline is 3 when schema coverage is high.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Find... and tap its center') and the target resource ('UI element by its accessibility identifier'). It distinguishes itself from siblings like 'tap' (generic), 'tap_text' (text-based), and 'tap_relative' (coordinate-based) by specifying the identifier-based targeting method.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need to tap an element via its accessibility identifier, but it does not explicitly state when to use this tool versus alternatives like 'tap_text' (for text-based tapping) or 'tap' (for coordinate-based tapping). No exclusions or prerequisites are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• terminate_appA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses the 'force-quit' behavior, which is valuable beyond basic 'terminate'. However, it lacks details on permissions needed, side effects (e.g., app data loss), error conditions, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Terminate (force-quit)') and resource, making it immediately scannable and appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations and no output schema, the description is minimal but covers the essential action. It doesn't explain return values or error handling, which are important for a mutation tool. However, the simplicity of the operation (force-quit) and clear parameters make it somewhat complete, though lacking in behavioral depth.

  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 parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond implying 'bundle_id' identifies the app and 'udid' targets a simulator. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Terminate (force-quit)') and resource ('an app on a simulator'), using precise terminology. It distinguishes itself from sibling tools like 'launch_app' by specifying the opposite operation, making its purpose immediately understandable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when needing to force-quit an app on a simulator, but provides no explicit guidance on when to use this versus alternatives (e.g., normal app closure methods if available) or prerequisites (e.g., requires a running simulator). It doesn't mention sibling tools like 'launch_app' as complementary operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tap_relativeA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It mentions the coordinate system but lacks behavioral details such as what happens if coordinates are out of bounds, whether it simulates a human tap with timing, if it requires the simulator to be active, or error handling. For a mutation tool (tap implies interaction) with zero annotation coverage, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero waste. It front-loads the key information (action and coordinate system) and avoids redundancy. Every word earns its place by clarifying the tool's unique aspect.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a mutation tool (tap action) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., error conditions, simulator state requirements), output expectations, or interaction effects. The schema covers parameters well, but the description does not compensate for the missing behavioral and output context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters ('rx', 'ry', 'udid') with their types and descriptions. The description adds minimal value by reinforcing the coordinate range and center point for 'rx' and 'ry', but does not provide additional syntax or context beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Tap') with the resource ('relative coordinates') and distinguishes it from siblings like 'tap' (absolute coordinates) and 'tap_id'/'tap_text' (element-based). It specifies the coordinate system ([0,1] range) and reference point (center at 0.5,0.5), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly provides context by defining the coordinate system, which helps differentiate when to use this tool versus 'tap' (absolute coordinates) or 'tap_id'/'tap_text' (element-based). However, it does not explicitly state when to prefer this over alternatives or mention prerequisites like needing a booted simulator, though the optional 'udid' parameter hints at simulator context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tap_textA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('tap its center') but omits critical details like whether this requires app focus, what happens if the text isn't found (error behavior), or if it's limited to specific app states. For a UI interaction tool, this leaves significant gaps in understanding its operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the core action ('Find... and tap') with no wasted words. Every part contributes directly to understanding the tool's purpose, making it highly concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's moderate complexity (UI interaction with targeting), no annotations, and no output schema, the description is minimally adequate. It covers the basic action but lacks details on behavioral outcomes, error handling, or dependencies (e.g., needing a booted simulator), leaving room for improvement in completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents both parameters (text and udid). The description adds no additional parameter semantics beyond what the schema provides, such as text matching rules or udid defaults. Baseline 3 is appropriate when the schema handles all parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Find... and tap') and target resource ('UI element by visible text'), distinguishing it from siblings like tap_id (by ID) or tap_relative (by coordinates). It precisely conveys the tool's function without redundancy.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by specifying 'visible text' targeting, suggesting it's for interacting with labeled UI elements. However, it lacks explicit guidance on when to use this versus alternatives like tap_id (for elements with IDs) or find_elements (for locating without tapping), missing clear exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.