Server Quality Checklist

Tool Scores

• get_orientationB
  3.3/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden of behavioral disclosure. The word 'Report' conveys a read-only, non-mutating operation, but the description does not disclose what happens if the simulator is not booted, what orientation values are returned (e.g., portrait/landscape labels vs. degrees), or whether any side effects occur.

  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 8-word sentence with no wasted words; the key action and object are front-loaded. It is appropriately sized for a zero-parameter tool, though a touch more behavioral detail would fit without bloating it.

  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 zero-parameter read tool, the description covers the basic purpose, but with no output schema and no annotations, it fails to explain what the reported orientation looks like (value format/enum) or how it behaves when the simulator is not running. An agent can infer the tool picks up the current orientation but must guess the return shape.

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

  Parameters4/5

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

  The tool has 0 parameters, so there is nothing for the description to add beyond the schema — the baseline 4 applies. The description neither confuses nor repeats parameter-related information.

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

  Purpose4/5

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

  The description states a specific verb ('Report') and resource ('the simulator's current physical orientation'), making the core action clear. It implicitly distinguishes itself from the sibling set_orientation through the read-oriented verb 'Report', though it never names the sibling explicitly.

  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 given on when to use this tool versus set_orientation — an agent must infer that 'get' is for reading and 'set' for changing. There are no exclusions, prerequisites, or conditions provided.

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

• shutdown_deviceA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It reveals that the tool targets a simulator optionally specified by name/udid and falls back to the booted one, but it does not mention side effects, error behavior for unknown names, or confirmation. The primary behavior is still clear enough for a simple shutdown command.

  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?

  One short sentence that immediately states the action, the target, and the default behavior. There is no filler or redundant information.

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

  Completeness4/5

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

  For a one-parameter tool with no output schema, the description covers the main call contract: what it does, how to select the target, and the default behavior. It could add error or response details, but those are unlikely to be essential for an agent to invoke it 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?

  The schema provides only a bare string property with no description, so the phrase 'by name or udid (defaults to the booted one)' adds essential meaning and clarifies that the parameter is optional. This compensates well for 0% schema coverage, though it omits example formats.

  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 states a specific action ('Shut down') and resource ('a simulator'), and clarifies selection by name, udid, or default to the booted one. It does not explicitly contrast with the sibling boot_device, but the intent is unambiguous.

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

  Usage Guidelines2/5

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

  The description says what the tool does but gives no guidance on when to use it over alternatives such as boot_device, nor does it mention prerequisites or exclusions. The default-to-booted note is selection behavior, not usage guidance.

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

• press_homeA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description is the only source of behavioral information. It accurately states the action but adds no context about consequences (e.g., navigating to the home screen, minimizing the current app) or whether it waits for the action to complete. This is adequate for a trivial action but lacks depth.

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

  Conciseness5/5

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

  The description is a single sentence, 'Press the device Home button,' with no wasted words. It is as concise as possible while still being clear and front-loaded.

  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, no output schema, and no annotations, the description fully covers the operation. The action is simple and self-contained; nothing an agent needs to invoke it correctly is missing.

  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 is empty (0 parameters), so the description has no parameter burden. The baseline for 0 parameters is 4, and the description does not need to mention parameters.

  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 states a specific verb ('Press') and resource ('device Home button'), clearly identifying the action. It does not explicitly differentiate from the sibling 'press_key', but the dedicated home-button scope is unambiguous.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like 'press_key' or 'tap'. The description provides no contextual conditions or exclusions, leaving the agent to infer usage.

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

• type_textA
  3.6/5.0
  Behavior2/5

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

  There are no annotations provided, so the description must carry the full transparency burden, but it only states the primary action. It doesn't disclose whether text is appended or replaced, what happens if no field is focused, or if any special characters are supported.

  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?

  One sentence, exactly as concise as the tool needs. Every word earns its place and it entirely avoids redundant or technical fluff.

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

  Completeness4/5

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

  For a tool with a single parameter, no output schema, and no nested complexity, this description materially cover: main function, target verb, and target resource. It doesn't include all edge-case behavior, but the core context is present and 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?

  With 0% schema description coverage, the description compensates by making it clear that the text parameter is the content to be typed. It does not add further detail like length limits, newline handling, or whether the text is sent as-is.

  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 states a specific verb ('type') and resource ('text into the focused field on the simulator'), which is clear and unambiguous. It is also distinguishable from siblings like press_key and tap, which serve different functions, even though it doesn't name them explicitly.

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

  Usage Guidelines3/5

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

  The description clearly implies a usage condition: the target must already be focused. However, it gives no explicit guidance about when to prefer this tool over alternatives, nor does it mention required preconditions like focusing a field first.

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

• open_urlA
  3.7/5.0
  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 behavioral disclosure burden. It conveys the target scope (booted simulator) and the nature of the action (opening a URL), but it does not state what happens with an unhandled or malformed scheme, whether the handling app is launched as a side effect, or what a successful or failed invocation looks like.

  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, focused sentence that immediately states the action and target before providing a usable example. It contains no filler, front-loads the essential information, and is appropriately sized for a one-parameter tool.

  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 simple one-parameter action tool with no annotations and no output schema, the description covers the core behavior and precondition but leaves edge cases uncovered—invalid schemes, fallback behavior, and what the caller should expect afterward. It is adequate but not 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 coverage is 0%, meaning the 'url' property is otherwise undocumented. The description adds real meaning by suggesting the expected format through examples like 'exp:// deep link or custom scheme'. This compensates somewhat, but it still leaves the full set of accepted schemes and any format restrictions unspecified.

  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 states a specific verb plus resource ('Open a URL') with an explicit scope ('on the booted simulator') and grounding examples (exp:// deep link or custom scheme). This clearly distinguishes it from siblings such as launch_app, open_app, and open_storybook, which open applications rather than URLs.

  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 the main use case through examples like exp:// deep links and custom schemes, and it hints at a precondition with 'booted simulator'. However, it never explicitly says when to prefer this tool over alternatives or names sibling tools as fallbacks, so the roadmap selecting between open_url and open_app/launch_app is left to inference.

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

• swipeA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the action and coordinates but does not mention side effects like scrolling, whether it requires the screen to be on, or how the duration parameter affects the gesture. It is not misleading, but it lacks depth beyond the basic mechanics.

  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 zero redundancy. It front-loads the core action and coordinate context, making it easy to scan. It is appropriately concise for a simple tool.

  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 basic gesture tool with no output schema and no annotations, the description covers the essential function and parameters. It lacks minor details like coordinate origin or duration default, but these are either common knowledge or provided in the schema for durationMs. Overall, an agent can correctly call this tool with the given information.

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

  Parameters3/5

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

  The description embeds the four required parameters (x1, y1, x2, y2) in the action sentence, giving them context as start and end points. However, it does not explain the optional durationMs parameter or the coordinate system's origin (e.g., top-left corner). Given that schema coverage is only 20%, the description should compensate more, but the parameter names and sentence provide some clarity.

  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 (swipe) and the resource (coordinates in points). It distinguishes from siblings like tap and tap_normalized by specifying a continuous gesture between two points, and the 'in POINTS' clarifies the coordinate system. This is specific and unambiguous.

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

  Usage 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 a swipe gesture is needed) but does not explicitly mention alternatives or exclusion criteria. It does not say 'use tap for discrete taps' or 'use tap_normalized for normalized coordinates,' so the agent must infer the appropriate choice from sibling names. No explicit when-not-to-use guidance is provided.

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

• tapA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses the coordinate space and that it taps at a point, but doesn't mention whether the tap is a discrete event, whether it waits for UI to settle, or any side effects. The description is adequate but minimal for a simple input 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?

  One sentence, front-loaded with the action and coordinate space, and the parenthetical adds the critical frame-of-reference detail. Zero 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 simple two-parameter tap tool, the description covers the essential context: coordinate space and its relationship to accessibility-tree frames. It doesn't describe return values, but no output schema exists and a tap typically returns nothing meaningful. The main gap is not naming tap_normalized as the alternative for normalized coordinates.

  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 both parameters. The description adds the key context that coordinates are in POINTS and align with accessibility-tree frames, which is valuable beyond the schema's 'x coordinate in points'.

  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 states a specific verb ('Tap') and resource ('at (x, y) in POINTS'), which clearly identifies the action. It distinguishes itself from the sibling tap_normalized by explicitly noting the coordinate space, though it doesn't name the sibling directly.

  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 clarifies that coordinates are in POINTS and the same space as accessibility-tree frames, which is essential context for when to use this tool versus tap_normalized. It doesn't explicitly state when not to use it, but the coordinate-space clarification implies the distinction.

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

• toggle_appearanceA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the core effect (appearance changes to dark or light) but does not mention whether the setting persists across launches, affects all apps on the simulator, or requires a running simulator. Minimal transparency is present, but richer behavioral context is absent.

  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 declarative sentence with no filler. It front-loads the action and includes the acceptable values, making it maximally efficient.

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

  Completeness4/5

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

  For a tool with one enum-only parameter, no output schema, and no annotations, the description covers the essential calling contract: what it does and what the parameter accepts. It omits usage conditions and persistence info, but the tool is simple enough that the included information is close to 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 description coverage is 0%, so the description must compensate. The text maps the single mode parameter directly to 'dark or light,' which clarifies the semantic effect of the enum values. The main gap is that it doesn't state which value is default or how the mode relates to a system-level setting; otherwise, the parameter meaning is well conveyed.

  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 states a specific verb/resource pair — 'Set the simulator appearance to dark or light' — which clearly conveys the tool's purpose. None of the sibling tools address appearance, so it is immediately distinguishable without opening the schema.

  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 offers no guidance on when to use this tool versus alternatives, no prerequisites (e.g., a booted simulator), and no exclusionary conditions. There are no sibling tools that compete directly, but the description doesn't mention that it applies only to a running simulator or that it overrides the user's settings.

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

• launch_appA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It compensates well by explaining the default app selection logic (only non-system running app, else only installed app) and the SIM_APP_BUNDLE_ID override. It does not mention failure modes or behavior when multiple apps are 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?

  Two focused sentences with no filler. Every clause adds information: target, context, default behavior, and override mechanism.

  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 a simple one-parameter tool with no output schema, this description covers invocation context, default selection, and override options. Minor gaps remain around error cases (multiple non-system apps, nothing to launch), but the core usage is complete enough.

  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 provides only a bare bundleId string, but the description clarifies its meaning, that it is optional, and how the default is determined. It stops short of giving an example or specifying bundle-id format.

  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 names a specific verb ('launch') and target ('app by bundle id on the booted simulator'), making the core action clear. It does not explicitly distinguish itself from the sibling open_app, so it stops short of a 5.

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

  Usage Guidelines3/5

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

  The description conveys the intended context: launching an app on the booted simulator by bundle id, with automatic defaults. However, it gives no explicit guidance on when to prefer this over sibling tools like open_app or open_storybook.

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

• set_orientationA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that screenshots reflect the rotation and that tap coordinates change accordingly, which is critical for an agent to understand downstream effects. It also explains the underlying toolchain. It does not mention prerequisites like booted simulator or potential errors, but the key behavioral consequence is well covered.

  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 action and values are front-loaded, followed by a relevant technical note and a practical consequence. The structure is tight and scannable.

  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 one-parameter tool with no output schema, the description covers the core behavior and the important side effect on coordinates. It omits potential prerequisites like simulator boot status, but given the sibling tool set includes boot_device and the action is straightforward, the completeness is strong but not exhaustive.

  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 a clear enum description ('target orientation'). The description repeats the enum values but adds no new semantic meaning beyond what the schema already provides, so it meets the baseline of 3 but does not exceed it.

  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 (rotate) and resource (simulator) and enumerates the four possible values, making the action unambiguous. It distinguishes itself from the sibling get_orientation and other device tools by specifying the exact operation.

  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 naming the toolchain (devicectl) and noting why simctl isn't used, but it does not explicitly state when to choose this tool over alternatives or provide exclusion conditions. The presence of get_orientation as a sibling makes the read/write distinction obvious, but no direct guidance is given.

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

• list_devicesA
  4.1/5.0
  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 states the tool lists simulators, which implies a read-only operation, but it does not disclose any side effects, prerequisites (e.g., Xcode runtime), or whether it returns only booted devices. For a simple list tool this is acceptable but not rich.

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

  Conciseness5/5

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

  The description is a single sentence with no filler, directly stating the action and output fields. It is appropriately front-loaded and earns every word.

  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?

  With no parameters and no output schema, the description provides all necessary context: what it lists and the key attributes included in the result. There is nothing an agent needs to know to call it correctly that is missing.

  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?

  There are zero parameters, and the description adds no parameter-specific information because none exists. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description does not need to compensate for any schema gaps.

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

  Purpose5/5

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

  The description uses a specific verb 'List' with a clear resource 'available iOS simulators' and explicitly enumerates the fields returned (udid, name, state). It is distinct from all sibling tools, which are actions (tap, swipe, launch, etc.), making its purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when to use it – to enumerate simulators – but does not explicitly contrast it with any alternative or state exclusions. However, given the sibling set contains no other listing tool, the usage context is clear enough without explicit guidance.

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

• get_accessibility_treeA
  4.2/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. 'Return' implies a read-only operation, and the description usefully lists what data is returned. However, it does not mention snapshot freshness, whether hidden/off-screen elements are included, or the coordinate space of the center points, so some important behavioral details remain implicit.

  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 short sentences with no redundancy. The first sentence states what the tool returns, and the second immediately gives the practical use case. 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?

  For a simple, zero-parameter read-only tool, the description adequately covers what is returned and why an agent would call it. Since there is no output schema, the description's enumeration of the returned fields is especially valuable. It could be slightly more explicit about coordinate system or hierarchy, but the core information is present.

  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 zero parameters, and the schema is empty with 100% coverage by default. The description therefore has no parameter burden to carry, and the baseline score of 4 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 uses the specific verb 'Return' with the clear resource 'simulator accessibility tree' and enumerates its contents (labels, roles, frames, center points). It strongly differentiates this tool from UI interaction siblings like tap and swipe by focusing on inspection rather than action.

  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 states the intended use: 'Use this to find exact tap coordinates for an element.' This gives clear context for when the tool is useful. It does not mention when not to use it or name alternatives, but the use case is concrete enough.

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

• open_storybookA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden and does well by specifying the booted simulator requirement, the default port, and the SIM_STORYBOOK_URL environment override. It stops short of describing failure modes or return behavior, but that is acceptable for a zero-parameter open 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 dense sentence with no filler. Every clause adds useful information: target, environment, mechanism, port, and environment variable override.

  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 no-parameter tool with no output schema, the description captures target, precondition, port, and configuration override, which is sufficient to invoke it correctly. It could mention what happens on success or if Metro is not running, but that is not essential for a simple open action.

  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?

  There are zero parameters and 100% schema description coverage, so the schema and description leave nothing ambiguous about arguments. The baseline of 4 applies because the tool requires no inputs.

  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 ('Open'), target resource ('Storybook'), and environment ('booted simulator'), while adding the concrete mechanism of a Metro server on port 8082. This makes it readily distinguishable from sibling tools like open_app or open_url.

  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?

  It implies when to use the tool: when you need Storybook on a booted simulator via Metro. However, it does not explicitly contrast this with sibling tools such as open_app, open_url, or launch_app, leaving when-not-to-use guidance to inference.

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

• press_keyA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that it presses a single HID key code, which implies a low-level input action. It doesn't mention whether the key press is a tap (down+up) or a hold, or whether it requires a device to be connected. However, the description is honest about what it does, and the key code list adds useful context. It doesn't contradict any annotations (none exist).

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

  Conciseness5/5

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

  The description is two sentences: the first states the action, the second provides a compact, useful reference. No wasted words. The key code list is front-loaded and easy to scan.

  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 one-parameter tool, the description is quite complete. It explains the parameter and gives common values. It doesn't mention return values (no output schema), but for a key press tool, the return is likely trivial. It could mention whether the key press is a tap or hold, but that's a minor gap. The sibling list shows this is part of a device control suite, and the description fits that context.

  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 0%, so the description must compensate. It explains the keyCode parameter by providing a mapping of common codes to keys, which adds significant meaning beyond the bare integer type. It doesn't explain the full range or all possible codes, but it gives enough for common use cases. This is strong compensation for a single 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 the tool's function: 'Press a single HID key code.' It specifies the resource (HID key code) and the action (press), and the title reinforces it. It distinguishes from siblings like type_text (which types text) and tap (which touches the screen) by focusing on HID key codes.

  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 a list of common key codes, which implicitly tells the agent when to use this tool (e.g., for Enter, Backspace, Tab, Space, Escape, letters, numbers). It doesn't explicitly state when not to use it or name alternatives, but the context of siblings like type_text and tap makes the usage context clear. The key code list is practical guidance.

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

• screenshotA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the disclosure burden. It clearly states capture behavior, PNG output, saved file path, pixel dimensions, and logical dimensions/scale. It does not mention failure behavior when no simulator is booted, but overall it is transparent about what the tool does and returns.

  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 filler: the first gives the action and output format, the second enumerates the returned data and explains why it is useful. The key information is front-loaded.

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

  Completeness4/5

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

  Given there is no output schema and no annotations, the description does well by enumerating the main return fields and connecting them to tap coordinates. Minor omissions are exact failure behavior and file lifecycle, but for a zero-parameter tool this is still largely 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 tool has zero parameters, so a baseline of 4 applies. There is nothing additional the description needs to explain for invocation, and invoking without arguments is self-explanatory.

  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?

  States a specific verb ('Capture') and resource ('booted simulator screen') plus the output format ('as a PNG'). It is clearly distinct from sibling tools like tap, get_accessibility_tree, or list_devices.

  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 booted precondition and the coordinate-derivation motivation imply when to call it, but it does not name any alternative or exclusion. It never tells an agent when to prefer get_accessibility_tree or another inspection tool.

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

• tap_normalizedA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It describes the normalized coordinate mapping, which is the main behavioral trait, but it doesn't mention possible side effects, device focus requirements, or error behaviors. For a simple tap, this is adequate but not rich.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action and coordinate definition. Every phrase adds useful context, 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?

  For a tool with only 2 parameters and no output schema, the description plus schema gives the agent enough to call it correctly. Slightly incomplete in that it omits outcome/error expectations, but this is a very simple tap action.

  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 already describes x and y as fractions of screen width/height; the description adds the valuable mapping of (0,0)=top-left, (1,1)=bottom-right and the screenshot-scaling motivation, meaning beyond the schema's min/max bounds.

  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?

  States a clear verb and resource: taps at a normalized position. Defines the coordinate system explicitly and explains the scaling context, distinguishing it from the likely absolute-coordinate sibling 'tap'.

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

  Usage Guidelines4/5

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

  Provides a clear context: 'useful when tapping from a screenshot without knowing the scale'. However, it does not explicitly name the alternative tool or say when not to use this one, so it lacks the full when/when-not guidance.

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

• open_appA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure. It explains the Expo/React Native dev-client path (Metro on port 8081 and the app's registered scheme), which is genuinely helpful. However, it does not state failure behavior, such as what happens when no simulator is booted, no Metro server is listening, or the app is not an Expo dev client.

  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 just two sentences. The core action is front-loaded, and the conditional Expo behavior is stated in a compact second sentence with no wasted words, making it easy to scan.

  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 zero-parameter tool with no annotations and no output schema, the description covers the main call scenario and the important dev-client exception. It does not mention failure cases, which is a moderate gap, but the essential context for invoking the tool is present.

  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 is empty, so there are zero parameters to document and schema coverage is trivially complete. With no parameters, the description correctly adds no parameter-specific semantics, and the baseline of 4 applies.

  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 what the tool does: opens the app on the booted simulator. It also distinguishes itself from the sibling tool launch_app by calling out the Expo/React Native dev-client case, so an agent can separate roles without opening the schema.

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

  Usage Guidelines5/5

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

  The description explicitly says 'For a regular app, prefer launch_app,' giving the agent a direct routing rule. It also implies the favorable scenario for open_app — Expo/React Native dev clients — and where the tool fits relative to launch_app.

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

• terminate_appA
  4.4/5.0
  Behavior4/5

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

  No annotations are present, so the description itself must convey behavior. It discloses meaningful behavior beyond the name: the default selection logic (only running non-system app, else only installed app), the ability to override via bundleId or SIM_APP_ID, and the simulator environment. It does not describe failure modes when multiple apps match, but the defaulting logic is clearly stated.

  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, information-dense sentence that front-loads the action and environment, then explains the parameter defaulting behavior. There is no filler or repetition.

  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 one-parameter tool, the description gives enough context for an agent to invoke it correctly in common cases: target simulator, optional parameter, fallback behavior, and override mechanism. It could mention what happens when no app matches or when multiple apps are running, but this is a minor gap and not likely to block correct use in typical scenarios.

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

  Parameters4/5

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

  The input schema only defines 'bundleId' as a string with no description, so the tool description adds needed meaning. It explains that bundleId is optional from the agent's perspective when defaults apply)Skip and that it can also come from an environment variable. The format of a bundle id is not elaborated, but the meaning and optionality are clear.

  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 uses a specific verb ('terminate') and a clear object ('an app by bundle id on the booted simulator'), so the tool's function is unambiguous. It is distinct from sibling tools like launch_app, open_url, or shutdown_device because it performs a shutdown of an app 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 gives clear operating context: it targets apps on the booted simulator and explains the bundleId default behavior, including the fallback from running apps to installed apps. It does not explicitly contrast with alternatives, but the usage context is strong enough to guide the agent.

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

• boot_deviceA
  4.5/5.0
  Behavior4/5

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

  With no annotations present, the description carries the burden and does disclose a key side effect ('open the Simulator app') beyond booting. It does not mention behavior when the simulator is already booted 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?

  Single sentence, front-loaded with the action, and no redundant restatement of the tool name. It packs the default behavior and side effect into minimal space.

  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 one-parameter boot operation, the description is nearly complete: action, parameter semantics, default, and side effect. It does not mention the return value or error conditions, but those are secondary for this kind of command.

  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?

  The schema likely provides only a generic string type with no per-parameter description, so the description adds essential meaning: the parameter can be a simulator name or UDID, and omitting it selects the configured device.

  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 uses a specific verb ('Boot') and resource ('a simulator'), and adds the accepted input forms ('by name or udid'). This clearly distinguishes it from sibling tools such as list_devices and shutdown_device.

  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 explains the invocation conditions: supply a name or UDID, or fall back to 'the configured device'. It could explicitly contrast with sibling tools like shutdown_device, but the usage context is still clear.

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