Server Quality Checklist

Tool Scores

• simctl_bootC
  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 full burden for behavioral disclosure. It states the action ('boot') but doesn't explain what booting entails (e.g., starting a virtual device, potential delays, or system requirements), nor does it cover error conditions or side effects, 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 extremely concise with a single sentence 'Boot a simulator device', which is front-loaded and wastes no words. Every part of the sentence directly contributes to understanding the tool's purpose, making it efficient 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 complexity of booting a simulator device (a mutation operation with no annotations or output schema), the description is incomplete. It lacks details on behavioral traits, success indicators, or error handling, which are crucial for an agent to use this tool effectively in context with its 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?

  The input schema has 100% description coverage, with the 'device' parameter documented as 'Device UDID or name to boot'. The description adds no additional meaning beyond this, but since schema coverage is high, the baseline score of 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.

  Purpose4/5

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

  The description 'Boot a simulator device' clearly states the action (boot) and target resource (simulator device), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'simctl_shutdown' or 'simctl_launch' which also operate on simulator devices, 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device must be shut down), exclusions, or how it differs from related tools like 'simctl_launch' or 'simctl_shutdown', leaving the agent without context for selection.

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

• simctl_installC
  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 full burden but adds minimal behavioral context. It states the action ('Install') but doesn't disclose traits like whether it overwrites existing apps, requires specific simulator states (e.g., booted), handles errors, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action without unnecessary words. Every word earns its place by directly conveying the tool's function, making it easy to parse quickly. No fluff or redundancy is present.

  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, prerequisites (e.g., simulator state), and what happens post-installation. For a tool that modifies simulator state, this leaves critical gaps for an AI agent to use it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters ('device' and 'app_path') well-documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain format details or usage examples). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.

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

  Purpose4/5

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

  The description clearly states the action ('Install') and resource ('app bundle on a simulator'), making the purpose immediately understandable. It distinguishes from siblings like 'simctl_uninstall' (removal) and 'simctl_launch' (execution), though it doesn't explicitly mention these distinctions. The specificity is good but could be slightly enhanced by noting it's for iOS/macOS simulators.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the simulator must be booted, which might be inferred from sibling 'simctl_boot'), exclusions, or comparisons to tools like 'simctl_launch' (which might start an installed app). This lack of context leaves the agent to guess based on tool names alone.

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

• simctl_io_screenshotC
  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 core action ('Capture a screenshot') but lacks critical details: it doesn't specify if this requires simulator boot state, mention error conditions (e.g., if device isn't found), describe output handling (e.g., base64 format when output_path is omitted), or note any side effects. For a tool with no annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence 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. Every word earns its place, with no redundancy or fluff.

  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 screenshot tool with 4 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain the return behavior (e.g., base64 data when output_path is omitted), error handling, or dependencies like simulator state. For a tool that interacts with device state and has multiple 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?

  Schema description coverage is 100%, so the schema fully documents all parameters (device, output_path, type, mask) with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

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

  Purpose4/5

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

  The description clearly states the action ('Capture a screenshot') and target resource ('from a simulator'), which is specific and unambiguous. It distinguishes this tool from siblings like simctl_boot or simctl_install by focusing on visual capture rather than device management or app operations. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a simctl_record_video), though none exist in the sibling list.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the simulator must be running), exclusions (e.g., not for physical devices), or compare to other screenshot methods. This leaves the agent to infer usage from the tool name and context alone.

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

• simctl_launchC
  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 full burden. It states the action ('Launch') but doesn't disclose behavioral traits such as error conditions (e.g., if the app isn't installed), side effects, or what happens on success/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 and appropriately sized for the tool's purpose, 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.

  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 with 5 parameters, no annotations, and no output schema), the description is inadequate. It lacks details on behavior, error handling, and output, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.

  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 doesn't add any meaning beyond the schema, such as explaining parameter interactions or usage examples. 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.

  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 target ('an app on a simulator'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like simctl_terminate (which stops apps) or simctl_install (which installs apps), missing explicit sibling distinction.

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

  Usage 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. The description doesn't mention prerequisites (e.g., needing a booted simulator or installed app), exclusions, or comparisons to siblings like simctl_terminate for stopping apps or simctl_openurl for opening URLs.

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

• simctl_listC
  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 full burden. It states the action 'List' but doesn't disclose behavioral traits such as output format (e.g., list of objects, JSON structure), pagination, rate limits, or error conditions. The description is minimal and lacks necessary context 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 purpose and lists all relevant resource types without unnecessary words, 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. It doesn't explain what the output looks like (e.g., structured data, plain text), how results are formatted, or any dependencies. For a tool with 2 parameters and no structured output info, more context 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?

  Schema description coverage is 100%, with clear descriptions for both parameters. The description mentions 'Filter to show only specific category' implicitly through the listed resources, but adds no additional meaning beyond the schema's enum values and search term explanation. 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 verb 'List' and specifies the resources: 'available simulators, device types, runtimes, or device pairs'. It distinguishes from siblings like 'boot', 'install', or 'launch' by focusing on listing rather than actions, but doesn't explicitly differentiate from potential similar listing tools (though none exist in siblings).

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives is provided. The description lists what it does but doesn't specify context, prerequisites, or exclusions. For example, it doesn't mention if this should be used before booting a simulator or to check available options.

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

• simctl_openurlC
  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 full burden. It states the action ('Open') but doesn't disclose behavioral traits such as what happens if the simulator isn't running, whether this requires specific permissions, error conditions, or the expected outcome (e.g., opens in browser vs. app). For a mutation tool with zero annotation coverage, 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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'Open' entails behaviorally, potential side effects, error handling, or return values. For a tool that interacts with simulators, more context is needed to use it effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters (device and url). The description doesn't add any meaning beyond what the schema provides (e.g., no examples of deep link formats or device selection strategies). 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 ('Open') and target ('a URL or deep link on a simulator'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like simctl_launch (which might launch apps) or simctl_push (which might push notifications), but the specific focus on URLs provides reasonable 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?

  No guidance is provided about when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a booted simulator), exclusions, or relationships with sibling tools like simctl_launch (for app launching) or simctl_boot (for starting simulators). The description assumes context without providing usage context.

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

• simctl_pushC
  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 doesn't mention side effects (e.g., whether the notification triggers app behavior), permissions needed, or error conditions (e.g., invalid device or bundle ID). This is a significant gap 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 front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function, 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 complexity of sending push notifications (a mutation operation), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, or return values, which are crucial for an agent to use this tool effectively in a simulator environment.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents all three parameters (device, bundle_id, payload) with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as examples or constraints, resulting in a baseline score of 3.

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

  Purpose4/5

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

  The description clearly states the action ('send a push notification'), target resource ('to an app on a simulator'), and distinguishes from siblings like simctl_install or simctl_launch by focusing on push notifications. However, it doesn't explicitly differentiate from other notification-related tools (none in the sibling list), so it's not a perfect 5.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, such as simctl_launch for app startup or simctl_openurl for URL handling. It lacks context about prerequisites (e.g., simulator must be running) or exclusions, 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.

• simctl_uninstallC
  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 full burden. It states the action but lacks critical behavioral details: whether this requires specific permissions, if it's destructive (likely yes, but not confirmed), error conditions, or what happens on success/failure. For a mutation tool 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, direct sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately scannable and efficient for an agent to parse.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral risks, success indicators, or error handling. For a tool that performs a potentially destructive action, more context is needed to ensure safe and correct usage.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'bundle_id' identifies the app and 'device' targets a simulator. Since the schema already covers this, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('uninstall') and target ('app from a simulator'), making the purpose immediately understandable. It distinguishes from siblings like 'simctl_install' by specifying the opposite operation. However, it doesn't explicitly mention the specific simulator context beyond the tool name, which slightly limits 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 relationships with sibling tools like 'simctl_terminate' or 'simctl_shutdown'. The agent must infer usage from context alone.

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

• simctl_privacyB
  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 actions (grant/revoke/reset) but doesn't cover critical aspects like required permissions, side effects (e.g., app restart), error conditions, or what 'reset' entails. 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 front-loads the core functionality. Every word earns its place, with no redundancy or wasted phrasing. It's 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.

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (e.g., side effects, error handling), usage context, and return values. The 100% schema coverage helps but doesn't compensate for missing behavioral context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain 'service' enum values or 'device' formats). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific verb ('grant, revoke, or reset') and resource ('privacy permissions for an app on a simulator'), distinguishing it from sibling tools like simctl_install or simctl_launch. It precisely defines the tool's scope without ambiguity.

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

  Usage 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., simulator must be running), exclusions, or how it differs from other privacy-related tools. Usage context is implied but not explicit.

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

• simctl_locationB
  3.4/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 disclosing behavioral traits like permission requirements, side effects (e.g., impact on simulator state), or error handling. It lacks details on what 'clear' entails or how location changes persist.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—front-loaded and directly states the tool's purpose. Every word earns its place, 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 no annotations and no output schema, the description is incomplete for a mutation tool with 4 parameters. It doesn't explain return values, error conditions, or behavioral nuances, leaving gaps in understanding the tool's full context and effects.

  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 parameters. The description adds no additional meaning beyond implying latitude/longitude are for 'set' actions, which is already covered in schema descriptions. Baseline score of 3 is appropriate as 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 ('set or clear') and resource ('simulated GPS location on a simulator'), distinguishing it from siblings like boot, install, or screenshot tools. It precisely defines the tool's function without ambiguity.

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

  Usage Guidelines3/5

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

  The description implies usage for location simulation on simulators but doesn't explicitly state when to use this versus alternatives (e.g., other simctl tools for different operations). No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred.

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

• simctl_shutdownB
  3.4/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 states the action ('Shutdown') but does not disclose behavioral traits such as whether this requires specific permissions, if it's reversible, what happens to running apps, or error conditions. For a mutation tool 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 that front-loads the core action and scope. Every word earns its place, with no redundancy or unnecessary details, 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 complexity of a shutdown operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks details on permissions, reversibility, error handling, or return values, which are crucial for safe and 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 parameter 'device' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain UDID formats or side effects). Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the action ('Shutdown') and the target ('a simulator device or all simulators'), using specific verbs and resources. It distinguishes itself from siblings like 'simctl_boot' (which starts devices) and 'simctl_terminate' (which stops apps, not devices), making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for shutting down simulators, but does not explicitly state when to use this tool versus alternatives like 'simctl_terminate' (for apps) or 'simctl_list' (for checking status). It provides basic context but lacks explicit guidance on exclusions or prerequisites.

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

• simctl_terminateA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool's destructive nature (terminating an app) and specifies the behavioral constraint of not shutting down the simulator. However, it doesn't mention error conditions, permission requirements, or what happens if the app isn't running.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose and key behavioral constraint without any wasted words. It's front-loaded with the main action and immediately clarifies the scope limitation.

  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 destructive tool with no annotations and no output schema, the description provides adequate context about what the tool does and its behavioral constraint. However, it doesn't mention what happens on success/failure or potential side effects, which would be helpful for a termination operation.

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

  Parameters3/5

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

  With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description doesn't add any additional semantic information about the parameters beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('terminate a running app') and the resource ('on a simulator'), while explicitly distinguishing it from the sibling tool 'simctl_shutdown' by noting it operates 'without shutting down the simulator'. This provides precise differentiation from related tools.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool (to terminate an app while keeping the simulator running), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage relative to 'simctl_shutdown' but doesn't provide explicit exclusion criteria.

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