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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It implies a read-only operation ('Get'), but does not state whether the app must exist, how errors are handled, what happens when the optional container parameter is omitted, or whether this requires a running simulator. The description lacks sufficient behavioral context.

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

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

The description is a single, clear sentence with no wasted words. However, it could be slightly restructured to front-load the primary purpose and include a brief note on optional output, which would make it even more effective without losing conciseness.

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

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

Given the tool has 3 parameters (one optional) and no output schema, the description is insufficient. It does not explain the return format (e.g., a string path), error conditions (e.g., app not found), or the implications of omitting the container parameter. For a tool that queries file system paths, more context is needed for correct invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds only a redundant listing of container types ('app bundle, data, or app group') already covered by the schema's 'container' parameter description. It does not clarify the default behavior when container is omitted, nor add any syntax or format details beyond the schema.

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

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

The description clearly states the action ('Get') and the resource ('file system path to an app's container'). It distinguishes this tool from sibling tools like app_launch, app_install, or log_stream, which perform different operations. The explicit mention of container types (app bundle, data, or app group) adds specificity.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., app must be installed on the simulator), and no conditions for when to specify the container parameter or omit it. There is no mention of exclusion cases.

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

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 only states the basic action without revealing whether the simulator needs to be running, whether existing installations are overwritten, what errors might occur, or what the tool returns. This is insufficient 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.

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

Single sentence, no wasted words. Information is front-loaded and direct. Every part of the description earns its place, and it is appropriately short for a simple tool.

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

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

For a tool that installs an app bundle, the description omits critical context: expected return value, error scenarios, and post-install state. With no output schema, the description should clarify these aspects. The current brief statement leaves the agent without sufficient information to handle the tool's behavior properly.

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

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

Schema description coverage is 100%, with both 'appPath' and 'deviceId' having adequate descriptions in the schema itself. The tool description does not add any additional meaning or context beyond those field descriptions. Baseline 3 is appropriate; no extra value provided.

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

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

Description clearly states the verb 'Install', the resource '.app bundle', and the target 'simulator'. It effectively distinguishes from sibling tools like app_uninstall and physical_device_install by specifying the target environment. However, it could be slightly more precise by clarifying what 'install' entails (e.g., copying to simulator without launching).

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

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 vs alternatives like app_launch or physical_device_install. There is no mention of prerequisites (e.g., simulator must be booted), nor any indication of whether it should be used before other operations. The description lacks any usage context.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose side effects, such as whether the app launches in the foreground, any permissions required, or if it returns a status. The description also fails to mention that the timeout and consolePty parameters relate to capturing console output, which is a behavioral trait.

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

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

The description is a single sentence that is brief and to the point, with no unnecessary words. It could benefit from a second sentence to provide usage guidance or behavioral context, but given the tool's straightforward purpose, the length is acceptable.

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

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

Given that the tool has 5 parameters and no output schema, the description is somewhat lacking. It does not explain the return value (e.g., if it returns a status or error) or the interaction between parameters like 'consolePty' and 'timeout.' This is a moderate gap for an app launch tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by implying the tool is for launching, but it does not explicitly explain 'consolePty' or 'timeout' in context of app launch behavior, reducing potential clarity. However, the schema itself is well-documented, so the added value is minimal, justifying a slight increase over baseline.

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

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

The description clearly states the verb 'Launch' and the resource 'an installed app on a simulator.' It is specific enough to distinguish from sibling tools like app_install, app_terminate, and app_list, though it could benefit from mentioning the constraint that the app must already be installed.

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

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

The description implies the tool is used for launching an app but does not explicitly state when to use it versus alternatives like app_install or app_terminate. It lacks guidance on prerequisites, such as the simulator being booted, which would help the agent decide when to use this tool.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or required permissions. For a listing tool, 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.

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

A single sentence with no fluff, front-loaded with the action and resource. Every word earns its place.

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

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

The tool is simple (1 parameter, no output schema), but the description does not hint at the return format or behavior. Adequate for a minimal list tool, but could be more complete.

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

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

Schema coverage is 100%, and the single parameter 'deviceId' is described ('Simulator UDID'). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description 'List all installed apps on a simulator' uses a specific verb ('list') and resource ('installed apps on a simulator'), clearly distinguishing it from sibling tools like app_install, app_launch, and other simulator operations.

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

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

The description implies usage (list apps on a specific simulator) but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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

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

The description accurately conveys that the tool opens a URL on a simulator, but with no annotations provided, the description carries the full burden of behavioral transparency. It does not disclose details about side effects (e.g., whether the app is launched if the URL scheme matches), error states (e.g., simulator not booted), or whether the operation is idempotent. It provides basic but incomplete behavioral context.

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

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

The description is a single sentence with no wasted words. It is direct and front-loaded with the verb and resource, making it efficient for an agent to parse.

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

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

Given the tool's simplicity with only two parameters and no nested objects or output schema, the description is mostly complete. However, it could mention that the simulator must be booted to function, which is a common prerequisite for such tools. The description is adequate for a straightforward tool but misses a key execution context detail.

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

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

Schema description coverage is 100%, meaning both parameters have descriptions in the schema. The description does not add additional meaning beyond what the schema already provides for the parameters. Therefore, a baseline of 3 is appropriate.

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

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

The description clearly states the tool opens a URL on a simulator for deep link and universal link testing. The verb 'Open' and resource 'URL on a simulator' are specific, and the mention of testing purposes distinguishes it from generic URL opening. However, it could further differentiate from sibling tools like app_launch by clarifying that this is for link navigation, not app launching.

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

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

The description implies usage for testing deep links and universal links, which provides some context. However, there is no explicit guidance on when to use this tool versus alternatives like app_launch or when not to use it, and no mention of prerequisites like the simulator being booted.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects (e.g., whether reset reverts to default state, if granting an already granted permission is idempotent), permissions required to invoke the tool, or any impact on app state. The only behavioral hint is that bundleId is required for grant/revoke, which 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.

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

The description is a single 13-word sentence, achieving high conciseness with no wasted words. However, it lacks structural elements like bullet points or separate sentences for different aspects (e.g., required arguments, return behavior), which could improve scannability without adding significant length.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description should provide more context such as prerequisites (e.g., simulator must be booted, app must be installed), expected output (e.g., success message or error), and behavior of the 'reset' action. The current description is too minimal for an agent to invoke the tool correctly without relying heavily on the schema alone.

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

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

The input schema has 100% coverage with descriptions for all 4 parameters, so baseline is 3. The description adds one piece of extra semantic value: noting that bundleId is 'required for grant/revoke'. This clarifies parameter usage beyond the schema, but otherwise the description does not elaborate on value formats or constraints.

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

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

The description uses a specific verb-resource combination ('Grant, revoke, or reset privacy permissions') and clearly states the target context ('for an app on a simulator'). It distinguishes itself from sibling tools like location_set and push_notification, which operate on different resource types.

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

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 (e.g., push_notification for notifications, location_set for location overrides). It also omits prerequisites such as the simulator needing to be booted or the app must be installed.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic action, failing to explain if the termination is graceful or forceful (e.g., SIGTERM vs SIGKILL), potential data loss, or side effects like unsaved state loss.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded with the action. However, it could be slightly improved by adding brief context like 'Safely stops the app process' without increasing length significantly.

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

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

For a simple two-parameter tool with no output schema, the description is adequate but incomplete. It does not mention that the simulator must be booted, the app must be running, or what the expected outcome is (e.g., no return value, process killed).

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

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

Schema description coverage is 100% (both bundleId and deviceId have descriptions). The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description 'Terminate a running app on a simulator' uses a specific verb (terminate) and clearly identifies the resource (running app) and context (simulator). It distinguishes itself from siblings like app_launch, app_uninstall, and app_list, as termination is a unique action.

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

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 (e.g., app_uninstall for removal, app_launch for starting). It also does not mention prerequisites such as requiring the simulator to be booted or the app to be running.

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

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 does not state side effects (e.g., removes all app data and sandbox), permissions needed, or any constraints. For a destructive action like uninstalling, 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.

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

The description is a single, concise sentence that clearly conveys the purpose. Every word earns its place, with no unnecessary repetition or filler.

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

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

The tool is simple with only 2 parameters, but as a destructive operation with no annotations and no output schema, the description should provide more context about behavior (e.g., requires booted simulator, removes data, may fail silently if app not found). It is not complete enough for safe agent invocation.

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

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

Schema description coverage is 100%, meaning the schema already documents both parameters (bundleId and deviceId). The description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Uninstall'), the target resource ('app'), the context ('from a simulator'), and the identifier method ('by bundle ID'). This is a specific verb+resource combination that distinguishes it from sibling tools like app_install, app_launch, and app_terminate, though it does not explicitly differentiate from other uninstall-like operations.

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

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. It does not mention prerequisites (e.g., the simulator must be booted, the app must be installed), nor does it clarify when not to use it or reference sibling tools such as app_terminate for similar operations.

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

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 indicates the tool analyzes (a read-only operation) but does not disclose whether it modifies anything, requires specific binary format, or has performance implications. It is minimal but not misleading or contradictory.

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

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

The description is a single, informative sentence with zero waste. It is perfectly concise for a tool with one parameter and a straightforward purpose.

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

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

Given that the tool has one parameter, a clear schema description, and a simple purpose, the description is nearly complete. It could optionally mention the output format, but that is not required without an output schema. The only minor gap is no behavioral disclosure, which is partially covered by the purpose.

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

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

Schema description coverage is 100% with a single parameter clearly documented as 'Absolute path to the Mach-O binary'. The description does not add additional semantic detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool analyzes Mach-O binary size breakdown by segment, specifying both the resource (binary) and the focus (size by segment). It distinguishes well from sibling tools like ipa_analyze or build_warnings that examine different aspects.

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

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

The description implies the tool is for analyzing binary size breakdown, but does not explicitly state when to use it over similar tools like ipa_analyze. No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It states that warnings are extracted and summarized but does not mention side effects, error handling (e.g., no build log), read-only nature, or whether it modifies any state. This is insufficient for an agent to predict tool behavior.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the core purpose. However, being too terse sacrifices completeness for brevity, preventing a perfect score.

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

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

There is no output schema, so the description should describe the return format (e.g., list of warnings, counts, severity). It does not address edge cases like missing build logs or how multiple recent builds are handled. This leaves significant gaps for agent usage.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters. The description adds no additional meaning about parameters (e.g., how projectPath or derivedDataPath affect the search). Baseline of 3 is appropriate.

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

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

The description clearly states the verb (extract and summarize) and resource (warnings from the most recent Xcode build log). It distinguishes itself from sibling tools like xcode_build, xcode_test, xcode_clean, etc., which perform build, test, or cleaning actions rather than analyzing warnings.

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

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

The description does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having a recent build log or running xcode_build first. The context of 'most recent' implies a build has occurred, but this is not stated explicitly.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only says 'Set the simulator to light or dark mode' and omits critical details: whether the simulator must be booted, whether the change persists, whether it affects all apps, or if there are any side effects. This is severely lacking for a tool that mutates simulator state.

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

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

The description is a single, efficient sentence with no redundancy. However, the conciseness comes at the cost of missing important behavioral and usage information. It is well-structured but under-informative, earning a 4 rather than a 5.

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

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

For a simple tool with 2 parameters and no output schema or annotations, the description should provide enough context for correct invocation. It fails to mention prerequisites (e.g., simulator must be booted, deviceId must come from a list or earlier tool like simulator_list). Without this, an AI agent may attempt to use the tool incorrectly, leading to errors.

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

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

Schema coverage is 100%: both parameters have clear descriptions in the schema ('Simulator UDID', 'Appearance mode' with enum). The description adds no additional meaning beyond what the schema already provides. Per the rubric, with high schema coverage, a baseline of 3 is appropriate; no extra value is contributed.

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

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

The description uses a specific verb 'Set' and explicitly identifies the resource ('the simulator to light or dark mode'). It clearly distinguishes from sibling tools like simulator_boot, simulator_shutdown, and status_bar_override, which have different purposes. The action and resource are unambiguous.

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

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. For instance, it does not mention that this tool is for toggling appearance during UI testing, nor does it contrast with tools like status_bar_override which might also affect display. There is no exclusion context (e.g., 'only works on booted simulators').

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

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

Annotations are absent, so the description carries the full burden. It only states that a diagnostic report is collected, but fails to disclose whether the tool is destructive, requires user consent, or overwrites files at the output path. There is no mention of side effects or access requirements.

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

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

The description is a single, clear sentence that conveys the essential purpose without any wasted words. It is appropriately front-loaded and fits the simplicity of the tool.

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

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

Given the tool has a single optional parameter and no output schema, the description is too brief. It lacks details about the output (e.g., format, location), behavior (e.g., archiving, cleanup), and prerequisites (e.g., simulator must be running). The agent may miss critical context for correct invocation.

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

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

The input schema has 100% description coverage with a single parameter 'outputPath' and a clear description. The tool description adds no extra meaning beyond the schema, but given full coverage, the baseline is 3. The description does hint that the output is an archive, which provides mild additional context.

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

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

The description clearly states that the tool collects a diagnostic report from the simulator subsystem, using the verb 'collect' and the resource 'diagnostic report from the simulator subsystem'. This differentiates it from sibling tools like log_collect or screenshot, though it doesn't explicitly contrast with them.

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

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

No usage guidance is provided. There is no indication of when to use this tool versus alternatives (e.g., when to use log_collect vs diagnostics), nor are there preconditions or postconditions described. The agent must infer the purpose.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. While it mentions the verification method (UUID comparison), it does not describe what the tool returns (e.g., exit code, success/failure message, or boolean), how it behaves on mismatch (throws error vs. returns false), or whether it requires permissions. Important behavioral traits are omitted.

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

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

The description is a single, front-loaded sentence that immediately conveys the tool's action. Every word serves a purpose. It is concise, though it could be slightly restructured to include return value information without increasing length significantly.

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

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

Given that there is no output schema, the description should explain the tool's return value or side effects to make it complete for an agent. It fails to do so – the agent won't know how to interpret the result (success/failure, exit code, or thrown error). For a simple two-parameter tool, this is a significant gap.

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

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

Schema coverage is 100% with clear descriptions ('Absolute path to the .dSYM file', 'Absolute path to the binary'). The description adds no additional meaning beyond the schema – no constraints, format hints, or examples. Baseline score of 3 is appropriate as the schema already defines the parameters adequately.

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

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

The description clearly states the tool's purpose: 'Verify that a dSYM file matches a binary by comparing UUIDs'. It uses a specific verb ('Verify') + resource ('dSYM file matches binary') + method ('comparing UUIDs'), which is precise. This purpose is distinct from all sibling tools, which focus on building, archiving, device management, etc.

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

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, when not to use it, or what prerequisites exist. For example, it does not mention that this tool is meant for post-build validation or that it might be used after an archive step. Sibling tools like xcode_archive or build_warnings are not referenced. The agent is left to infer usage context.

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

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

With no annotations, the description must fully disclose behavioral traits. It fails to mention whether the tool is read-only, requires specific permissions, or what qualifies as a 'built app bundle'. It also does not clarify if it reads from the embedded.mobileprovision or the binary. This lack of context leaves the agent guessing about side effects and requirements.

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

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

The description is a single sentence with no wasted words. While it could benefit from additional structure (e.g., bullet points for return format), it is compact and front-loaded with the core action.

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

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

Given the lack of output schema and annotations, the description should provide more context about return format (e.g., list of entitlements, JSON) and edge cases (e.g., missing entitlements, non-existent bundle). It is insufficient for an AI agent to fully understand the tool's behavior and output.

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

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

Schema coverage for the single parameter appPath is 100% (already described in the schema as 'Absolute path to the .app bundle'). The tool description adds no extra meaning beyond that, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Show' and the resource 'entitlements embedded in a built app bundle', which differentiates it from sibling tools like profile_inspect or xcode_build_settings. The purpose is unambiguous and specific.

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

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, such as when inspecting provisioning profiles or code signing. There is no mention of prerequisites (e.g., a valid .app bundle path) or when not to use it.

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

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 implies a read-only analysis but does not explicitly state that the tool does not modify the file or require special permissions. The description is somewhat transparent about outputs but lacks explicit behavioral disclosure.

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

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

The description is a single sentence that lists the analysis outputs, making it concise and front-loaded. However, it could be slightly more structured (e.g., by adding 'returns') to improve clarity.

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

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

For a simple analysis tool with one parameter and no output schema, the description provides a clear list of what is analyzed, making it reasonably complete. It distinguishes from sibling tools but does not describe the return format, which is acceptable given no output schema.

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

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

Schema description coverage is 100% as the only parameter, ipaPath, has a description 'Absolute path to the .ipa file'. The tool description adds no additional meaning beyond what the schema already provides, warranting the baseline score of 3.

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

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

The description states 'Analyze an IPA file: size, bundle ID, version, architectures, embedded frameworks', which is a specific verb and resource, and the listed analysis outputs differentiate it from sibling tools like ipa_permissions and binary_size that cover only subsets.

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

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

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., the IPA file must exist and be valid) or when to prefer sibling tools like ipa_permissions for permission analysis alone.

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

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 accurately indicates a read-only extraction from a file, but it does not explain what happens if the IPA file is missing, if the Info.plist lacks these keys, or if there are multiple entries. For a simple readonly scanner, the current level of transparency is adequate but not thorough.

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

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

The description is a single sentence that efficiently conveys the purpose and key examples (NSCameraUsageDescription). Every word adds value, with no fluff or redundancy. It is front-loaded and perfectly sized for a tool with one parameter.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is nearly complete. It covers the core purpose and examples. Minor gaps include missing return format details and edge-case behavior, but the tool's domain is narrow enough that these are not critical gaps.

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

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

Schema description coverage is 100% for the single parameter, but the tool description adds no additional meaning beyond the schema's 'Absolute path to the .ipa file'. It does not clarify path formats (relative vs. absolute), wildcard support, or validation behavior. Since the schema already covers the parameter, a baseline 3 is appropriate.

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

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

The description uses a specific verb-resource pairing ('List privacy usage descriptions ... from an IPA'), clearly identifies the tool's function and scope, and is well differentiated from the 60+ sibling tools—none of which reference IPA permission scanning. The mention of concrete keys (NSCameraUsageDescription, etc.) confirms a focused extraction task.

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

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

The description implies that this tool is appropriate when you need to inspect permission strings in an IPA file, but it does not explicitly state when to use it versus alternatives like app_privacy or ipa_analyze, nor does it mention prerequisites (e.g., that the IPA must exist and be accessible). Without this context, an agent may infer correct usage from the clarity but lacks explicit guidance.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention if the operation is read-only, requires special permissions, or what output format to expect. It only states what it lists, not how it behaves.

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

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

The description is a single, complete sentence with no wasted words. It communicates the core function efficiently.

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

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 output schema, the description is minimally adequate. It explains what the tool does but omits context like output format or any potential side effects. With no annotations, more behavioral context would be beneficial.

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

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

There are zero parameters, and schema description coverage is 100%. The description does not need to add parameter-level meaning since none exist, earning a perfect score.

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

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

The description clearly states it lists all keychains on the machine, which is a specific verb+resource combination. It distinguishes itself from sibling tools focused on Xcode builds, simulators, app management, etc., but does not differentiate from potential other keychain tools.

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

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 or any exclusions. Since there are no sibling tools with similar names, the lack of guidelines is less critical, but still absent.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states only that the tool clears location, omitting whether the operation is destructive (it is), what happens if no location was set, if the simulator must be booted, or what the return value indicates. This is minimal transparency.

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

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

The description is a single, concise sentence (8 words) with no redundant information. Every word earns its place for a simple one-parameter tool.

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

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

Given the tool has no output schema and a single parameter, the description is minimally adequate but lacks context about preconditions (e.g., simulator must have a location set) and the exact effect (resets to default location?). It needs slightly more detail to be fully actionable.

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

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

Schema coverage is 100% with a clear description for deviceId ('Simulator UDID'). The tool description does not add additional meaning to the parameter beyond what the schema already provides, which meets the baseline for high coverage.

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

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

The description clearly states the verb 'Clear' and the resource 'simulated GPS location' on a 'simulator', distinguishing it from siblings like 'location_set' and other simulator tools. The purpose is unambiguous.

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

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 (e.g., location_set), nor are any prerequisites mentioned (e.g., simulator must be booted, location must previously have been set). The agent receives no context for appropriate invocation.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not state whether this action is destructive, reversible, requires authentication, or has side effects like overwriting an existing location. The description is too minimal 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.

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

The description is a single concise sentence with no unnecessary words, front-loading the action and resource effectively.

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

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

Given the tool performs a mutation action with no annotations or output schema, the description is incomplete. It lacks information about prerequisites (e.g., simulator must be booted), behavior when coordinates are out of bounds, and return value, leaving significant gaps for an agent.

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

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

Schema coverage is 100%, so all three parameters are documented in the schema itself. The description does not add meaning beyond the schema, 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.

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

The description clearly states 'Set a simulated GPS location on a simulator' using a specific verb ('Set') and resource ('simulated GPS location,' 'simulator'). It distinguishes this from its sibling location_clear, which suggests a clearing action.

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

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

The description implies use for setting a GPS location during simulation but provides no explicit guidance on when to use this tool versus alternatives like location_clear or other simulator tools. There is no discussion of prerequisites, such as whether the simulator must be booted.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions time range and predicate filtering, giving some behavioral context, but does not disclose whether the tool is read-only, if it requires simulator to be booted, or what happens if no logs match the predicate. The verb 'collect' suggests a reading operation, but clarity on side effects is missing.

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

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

The description is a single, front-loaded sentence that communicates the essential information without any wasted words. Every phrase earns its place: the verb 'collect', the resource 'logs from a simulator', and the key filtering capabilities 'time range and predicate filtering'.

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

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

Given the tool has 4 parameters, full schema coverage, no output schema, and no annotations, the description is reasonably complete. It communicates the core functionality and filtering capabilities. However, it could mention the output style parameter (enum) and whether results are returned in a specific format or streaming, but the schema compensates for the style part.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by summarizing that filtering is by time range and predicate, which groups the loosely described parameters into a cohesive intent. It does not add syntax details beyond the schema, but the grouping helps the agent understand the tool's purpose.

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

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

The description clearly states the tool collects logs from a simulator and mentions time range and predicate filtering. It specifies the resource ('logs from a simulator') and the action ('collect'), distinguishing it from log_stream, which is a sibling tool for live streaming.

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

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

The description implies usage for collecting recent logs with filtering options, but does not explicitly state when to use this tool over alternatives like log_stream or diagnostics. No when-not-to-use guidance or prerequisites are provided.

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

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

No annotations are provided, so the description carries full burden of behavioral disclosure. It mentions live streaming for a duration but does not disclose whether the tool is read-only or destructive, how connections are managed, or what happens on timeout or errors.

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

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

The description is a single concise sentence that communicates the core functionality efficiently. It is front-loaded with the main action (stream live logs) and duration constraint.

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

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

Given the parameter count (4) and lack of output schema, the description is minimally adequate. It covers the tool's purpose and key constraint (duration) but lacks details on expected output format, error scenarios, or connection lifecycle.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter details beyond what the schema already provides, such as how 'timeout' relates to 'streaming' or the purpose of 'predicate'.

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

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

The description clearly states the tool streams live logs from a simulator for a specified duration, which is specific and distinct from sibling tools like 'log_collect' and 'physical_device_console'. However, it does not explicitly distinguish it from these sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'log_collect' or 'physical_device_console'. It does not mention any prerequisites, context, or when not to use it.

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

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

No annotations are provided, so the description bears full responsibility. It says 'stream its console output for N seconds' but does not disclose whether the call is synchronous or asynchronous, what the response contains, if the app is killed after streaming, or side effects. This is a significant gap for a tool that involves streaming output.

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

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

The description is a single, front-loaded sentence of 14 words. It efficiently communicates the action and the adjustable parameter (N seconds) with no wasted text.

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

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

The tool has 3 parameters and no output schema. The description does not explain the return value or behavior of the stream (e.g., whether output is returned as a string, file, or live feed). Additionally, prerequisites like device connectivity or boot state are omitted. The response format is a critical missing piece.

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

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

Schema description coverage is 100%, with each parameter (deviceId, bundleId, timeout) already well-documented. The description adds 'N seconds' which aligns with timeout but adds no new semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Launch' and 'stream' applied to the resource 'app on a physical device' and 'console output'. It differentiates from siblings like physical_device_launch (launch only) and log_stream (logs without launching) by specifying the combined action.

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

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

The description implies usage for launching an app and getting its console output, which is a distinct use case. However, it does not explicitly state when to use this tool versus alternatives like log_stream or physical_device_launch, nor does it mention exclusions or prerequisites.

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

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

With no annotations, the description must disclose behavioral traits. It only states the action without mentioning prerequisites (e.g., device must be connected), potential side effects (e.g., overwriting existing app), return values, or error conditions. This is insufficient 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.

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

The description is very short (8 words) but not appropriately sized; it sacrifices necessary detail for brevity. While concise, it under-specifies the tool's behavior.

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

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

Given the existence of sibling 'app_install', the lack of differentiation, no output schema, and no annotations, the description is incomplete. It does not clarify the type of app, device connection requirements, or installation behavior.

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

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

Schema coverage is 100% with both parameters described. The description adds no additional meaning beyond the schema, so it meets the baseline of 3.

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

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

The description 'Install an app on a connected physical device' clearly states the verb and resource, and the 'physical device' qualifier helps distinguish from the sibling 'app_install'. However, it does not explicitly differentiate from 'app_install' or other installation tools, leaving some ambiguity.

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

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 like 'app_install' or when not to use it. The description lacks context for prerequisites or conditions.

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

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 only says 'Launch an installed app' but omits critical details: what happens if the device is disconnected, if the app is not installed, if the launch fails, whether the app is brought to foreground, or what the tool returns. This is insufficient for an agent to understand the tool's full behavior and error states.

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

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

The description is one short sentence of 9 words, which is very concise. It front-loads the core action. However, it sacrifices completeness for brevity; a slightly longer description could add value without losing conciseness.

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

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

Given the tool's complexity (launching an app on a physical device), the description is incomplete. It lacks prerequisites (e.g., device must be connected and app installed), behavioral details (e.g., does it return success/error?), and any reference to output. Since no output schema is provided, the description should compensate but does not.

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

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

The schema covers 100% of parameters with descriptions ('App bundle identifier' and 'Device identifier'), so the description adds no extra meaning. Baseline is 3 for high coverage, and the description does not provide additional context like how to obtain these identifiers or format expectations, but does not detract.

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

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

The description clearly states the verb 'Launch' and the resource 'an installed app on a connected physical device', which is specific to physical devices. However, it does not distinguish itself from the sibling tool 'app_launch', which might serve a similar purpose on simulators or other contexts, leaving some ambiguity.

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

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. There is no mention of prerequisites (e.g., device must be connected, app must be installed) or exclusions (e.g., do not use if the app is not installed). Sibling tools like 'app_launch' or 'physical_device_install' could be confused without context.

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

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 only states the purpose and a prerequisite. It does not disclose whether the operation is read-only, what happens if no devices are connected, or any side effects. This is insufficient for a tool with no annotation support.

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

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

The description is a single sentence that is front-loaded with the key action and resource. It contains no filler words and efficiently conveys the essential information. Every word earns its place.

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

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

Given the tool has no output schema, the description should explain what the list returns (e.g., device names, UDIDs, connection status). It does not. Additionally, with no annotations, the description should cover behavioral aspects like idempotency or error conditions. These gaps make it incomplete for an agent to fully understand the tool's behavior.

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

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

There are no parameters and the schema coverage is 100% (empty). According to the baseline rule, a score of 3 is appropriate when schema coverage is high but the description adds no additional meaning. The description does not elaborate on the output or any implicit parameters, so it does not exceed the baseline.

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

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

The description clearly states the verb 'List' and the resource 'connected physical iOS devices', which is specific and distinguishes it from sibling tools like simulator_list (lists simulators) and physical_device_install (installs). The prerequisite requirement adds further specificity.

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

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

The description mentions a prerequisite (Xcode 15+ with devicectl), which provides some usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., simulator_list), nor does it mention when not to use it. The implication is clear from the name, but explicit guidance is lacking.

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

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

The description does not disclose any behavioral traits beyond the basic action. Given no annotations exist, the description fails to convey that the tool modifies the Podfile.lock, downloads dependencies, may require network access, or has side effects. This is insufficient for safe invocation.

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

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

The description is a single sentence with no wasted words. However, it could be more concise by merging the verb and resource more naturally, but it's acceptable.

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

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

For a simple tool with two parameters and no output schema, the description is somewhat complete but misses key contextual information such as prerequisites (Podfile required), potential errors, and behavioral notes (long-running, network usage). Given the low complexity, a score of 3 is appropriate.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the parameter descriptions in the schema. It does not clarify how the parameters interact or provide additional context like default values or when to set repoUpdate to true.

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

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

The description clearly states the verb ('Run') and resource ('CocoaPods install') with the purpose of setting up pod dependencies. It is specific and distinguishes the tool from siblings like pod_update and pod_outdated.

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

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 such as pod_update, spm_resolve, or xcode_build. The description lacks any context about prerequisites, when not to use it, or how it fits into a workflow.

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

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

With no annotations, the description carries full burden. It does not disclose whether the tool modifies anything (it does not), whether it requires network access, what output format is produced, or if any side effects occur. The word 'Check' implies read-only, but no explicit confirmation of safety.

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

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

Single sentence, front-loaded with verb and resource. No filler words, but it could be slightly more informative without harming conciseness.

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

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

Tool is simple with one parameter and no output schema, but the description lacks critical details: whether it interacts with the network, what it returns (list of outdated pods?), and whether it requires a resolved Podfile.lock. Given sibling tools exist for update, the description should clarify that it only reports, not modifies.

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

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

Schema covers the parameter fully with description 'Project directory containing Podfile', so baseline is 3. The description adds no additional detail beyond schema; however, since coverage is 100%, it is adequate.

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

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

The description states the verb 'Check' and the resource 'outdated CocoaPods dependencies', which clearly indicates the tool's purpose. It does not explicitly distinguish from sibling tools like pod_install or pod_update, but the name and wording already make the distinction clear.

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

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

No mention of when to use this tool versus alternatives such as pod_update. It lacks guidance on whether this is a dry-run or requires network access, and no context on prerequisites like having CocoaPods installed.

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

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

No annotations are provided, so the description must convey behavioral traits. It only says 'update' without explaining what exactly happens (e.g., modifies Podfile.lock, requires network, potential side effects). There is no mention of safety, destructiveness, or required permissions. For a mutation tool, 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.

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

The description is a single sentence of 8 words, immediately stating the action and scope. It is front-loaded and contains no filler or redundant information. Every word earns its place.

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

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

The tool has no output schema, no annotations, and is a mutation operation. The description fails to explain return values, error states, or prerequisites (e.g., that a Podfile must exist). Given the complexity of dependency management, the description is incomplete and leaves the agent with insufficient context to use the tool confidently.

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

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

Schema description coverage is 100% with clear descriptions of podName and projectPath. The tool description adds no new meaning beyond paraphrasing the podName parameter. Given the high schema coverage, a baseline of 3 is appropriate; the description does not compensate for any gaps but also does not mislead.

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

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

The description clearly states the verb 'update' and resource 'CocoaPods dependencies', with scope 'all or a specific pod'. It distinguishes from sibling tools like pod_install (install) and pod_outdated (list outdated), but does not explicitly differentiate from pod_install, which could be ambiguous. A explicit mention of when to use each would elevate it to a 5.

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

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 pod_install or pod_outdated. It does not mention prerequisites, typical use cases, or when it is inappropriate to use this tool. The agent must infer from the name alone.

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

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

Given that no annotations are provided, the description carries the full burden of disclosing behavioral traits. It states that the tool 'decode[s] and inspect[s]' the profile to show 'full contents', implying a read-only, non-destructive action. However, it does not specify whether the output is printed to console, returned as structured data, or saved somewhere. The description is adequate but lacks detail about potential side effects or output format.

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

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

The description is a single, efficient sentence that conveys the action and target without any filler. Every word is meaningful, and it is front-loaded with the key verb 'decode and inspect'.

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

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

Given the simplicity (1 parameter, no output schema) and the sibling tools, the description is mostly adequate. However, it omits what the output actually is (e.g., raw contents parsed and printed, formatted JSON, etc.) and does not clarify if this is purely a display tool or if it returns data for further processing. With no output schema, the description could have added value by describing the return format.

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

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

Schema description coverage is 100%. The description adds context by explaining that the 'profilePath' is an absolute path to a .mobileprovision file, which is slightly more specific than the schema's own description ('Absolute path to the .mobileprovision file'). Since the schema already covers the parameter fully, the tool description still adds marginal value by framing the parameter in the context of the tool's action.

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

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

The description uses specific verbs ('Decode and inspect') and identifies the resource ('provisioning profile'). It clearly states the tool's purpose, but does not distinguish it from siblings like 'provisioning_profiles' or 'entitlements_check', which could be related.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'provisioning_profiles' or 'entitlements_check'. It does not mention prerequisites, such as needing a valid .mobileprovision file path, or when this decode action is appropriate.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It reveals the conditional behavior based on xcodegen presence and the output (path or manual instructions). However, it does not mention side effects like overwriting existing projects, permissions, or error handling, leaving some gaps.

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

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

The description is a single sentence that front-loads the main purpose. It uses backticks for code elements and is fairly efficient. The conditional clause makes it slightly longer than ideal, but it remains clear and concise. No wasted words.

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

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

Given the tool's complexity (7 parameters, no output schema, no annotations), the description covers the core behavioral differentiator but lacks details on edge cases (e.g., existing directory, invalid path, xcodegen failure). It also does not describe the return format beyond 'path' or 'manual instructions', leaving some ambiguity for the agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add new meaning or context to the parameters; it only implicitly references them (name, template, platform, outputPath) without elaboration. The description's value lies in the behavioral conditional, not parameter semantics.

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

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

The description clearly states the tool creates a new Xcode app project with source tree and XcodeGen project.yml. It uses specific verb 'create' and resource 'Xcode app project', and it is distinct from sibling tools (no other project creation tool exists among siblings).

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

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

The description provides clear context on when xcodegen is run automatically vs when manual steps are needed. While it does not explicitly state alternatives or exclusions, the conditional logic is well explained and there are no competing project-creation tools among siblings, so the usage guidance is effective.

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

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

With no annotations, the description must fully disclose behavioral traits. 'List' implies a read-only, non-destructive operation, but it does not explicitly state safety, performance implications, or what happens when no profiles are installed. The description is adequate for a simple listing but lacks explicit transparency.

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

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

The description is a single sentence of 12 words, front-loaded with the verb and resource, and contains no extraneous information. Every word earns its place.

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

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

For a simple list tool with no parameters and no output schema, the description covers the essential information: what it lists and the fields returned. It is mostly complete, though it could mention that it only lists installed profiles (which is clear from 'installed') and that it requires no arguments.

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

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

The tool has zero parameters, and schema coverage is 100% (trivially). The baseline for 0 parameters with high coverage is 3. The description adds no parameter semantics because there are none to describe.

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

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

The description uses a specific verb 'List' and identifies the resource 'all installed provisioning profiles' with fields. It clearly distinguishes from siblings like 'profile_inspect' (which likely inspects a single profile) and 'signing_identities' (lists certificates, not profiles).

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

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 such as 'profile_inspect' or 'signing_identities'. The description does not mention that this lists all profiles while others may target specific ones or different resources.

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

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

No annotations are provided, so the description must carry the full burden. It only states the basic action without disclosing side effects, prerequisites (e.g., simulator must be booted, app installed), error behavior, or whether the notification is simulated or real. This is insufficient for safe agent decision-making.

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

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

The description is a single, 14-word sentence that is front-loaded with the action. Every word adds value, and there is no redundancy or fluff.

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

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

For a tool with three simple parameters and no output schema, the description covers the core action, target, and method. It does not mention prerequisites or side effects, but given the tool's simplicity, these omissions are minor. The description is generally complete for its complexity level.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add additional meaning beyond what the schema already provides, meeting the baseline of 3. The example in the payload description is helpful but is part of the schema, not the tool description.

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

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

The description uses a specific verb ('Send'), clearly identifies the resource ('push notification to an app on a simulator'), and specifies the method ('via APNs payload JSON'). No sibling tool overlaps with this functionality, so it is well-differentiated.

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

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

The description states the action but provides no explicit guidance on when to use this tool vs. alternatives (e.g., app_launch, app_install). There are no sibling tools for push notifications, so usage is implied, but the description lacks any 'when to use' or 'when not to use' instructions.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states that the tool 'generates' a subclass, but omits critical details: whether it overwrites existing files, whether it requires a valid outputPath directory, side effects on the file system, or that it generates a .swift file. The description is too sparse to inform an agent about the tool's actual behavior.

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

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

The description is a single 7-word sentence with no fluff or redundant information. It is concise but at the expense of completeness. It earns a 4 for efficiency, though it lacks detail that would make it more useful.

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

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

Given the tool's complexity (code generation with file creation, default attributes, no output schema), the description is insufficient. It does not explain the output format, default behaviors, or error conditions. The schema covers parameter structure but not the tool's overall effect. The description leaves significant gaps for an AI agent.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters (name, attributes, outputPath) with their types and descriptions. The description adds no additional meaning beyond the schema, such as explanations of default attribute behavior or the generated file format. Baseline 3 is appropriate given the high schema coverage.

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

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

The description 'Generate a Core Data NSManagedObject subclass with attributes' uses a specific verb ('Generate') and specifies the resource ('Core Data NSManagedObject subclass'). It clearly distinguishes from sibling scaffold tools like scaffold_view, scaffold_viewmodel, and scaffold_widget, which target different code artifacts.

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

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 does not mention prerequisites (e.g., existing Core Data model), context (e.g., Xcode project), or scenarios where it is inappropriate. No exclusions or comparisons with sibling tools are given.

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

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 doesn't disclose side effects (does it overwrite existing files?), permissions needed, whether the preview is included by default based on the schema default, or what happens if the directory doesn't exist. The simple description lacks these behavioral details.

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

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

One concise sentence that captures the core functionality. Every word earns its place; no fluff or redundant information.

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

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

Given the simple interface (3 params, no output schema, no nested objects), the description is largely adequate. However, lack of behavioral details (overwrite behavior, project context) and usage guidance reduces completeness for a code generation tool. It covers the basics but leaves gaps.

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

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

Schema description coverage is 100% and the description mentions 'with optional preview provider' which aligns with the includePreview parameter, adding minimal value. The description doesn't elaborate on name or outputPath beyond what the schema says, so baseline 3 is appropriate.

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

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

The description clearly states it generates a SwiftUI View file with optional preview provider, using specific verb 'Generate' and specific resource 'SwiftUI View file'. This distinguishes it from siblings like scaffold_viewmodel and scaffold_coredata_model, though the purpose could be slightly more precise about what 'scaffold' entails.

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

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

The description doesn't explicitly say when to use this tool versus alternatives, but the distinction from siblings like scaffold_viewmodel, scaffold_coredata_model, and scaffold_widget is implied by the resource type. No guidance on prerequisites (e.g., project existence) or when not to use it.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects (e.g., file creation), required permissions, dependencies (like an existing Xcode project), or whether it overwrites existing files. The generation act is implied but not detailed.

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

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

The description is a single, short sentence that is front-loaded with key information. It is concise and focused, earning its place without extraneous detail.

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

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

Given there are only 2 parameters with full schema coverage and no output schema, the description is adequate but not complete. It does not mention what happens if the file already exists, what code conventions are used, or any prerequisites, leaving gaps for a generation tool.

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

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

Schema description coverage is high at 100% with the schema already describing 'name' as 'ViewModel name' and 'outputPath' as 'directory'. The description adds the '@Observable' detail but otherwise does not significantly augment parameter meaning beyond the schema.

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

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

The description clearly states the tool generates an '@Observable ViewModel class', using a specific verb ('Generate') and resource ('ViewModel class'). It distinguishes itself from sibling tools like 'scaffold_view' and 'scaffold_coredata_model' by specifying the exact type of artifact created.

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

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

The description does not explicitly state when to use this tool versus alternatives. However, the sibling tools include other scaffolds like 'scaffold_view' and 'scaffold_coredata_model', and the name and description imply this is for ViewModel classes in Swift/SwiftUI contexts, providing implied usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds context by explaining what each widget kind uses (TimelineProvider vs AppIntents). However, it does not disclose whether files are overwritten, naming conventions, or side effects like creating multiple files. This is moderate transparency.

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

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

The description is a single sentence under 25 words. It is front-loaded with the action and resource, and every word adds value. There is no redundancy.

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

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

With 3 parameters and no output schema, the description is functional but lacks detail about what files are generated, directory structure, or naming conventions. The kind explanation helps, but completeness is average for a code generation tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description expands on the 'kind' parameter by explaining the API behind each option, which adds meaning beyond the schema's 'Widget type' description. It does not enhance the other parameters, but this addition justifies a score above baseline.

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

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

The description clearly states the verb 'Generate' and the resource 'WidgetKit extension', and it distinguishes between 'static' and 'configurable' kinds. This differentiates it from sibling scaffold tools like scaffold_view and scaffold_viewmodel, which target different resource types.

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

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

The description implies when to use this tool (when you want to generate a WidgetKit extension) but does not provide explicit guidance on when to use it vs. alternatives. Among many scaffold siblings, no exclusions or comparisons are given. The internal differentiation between static and configurable is helpful but not external usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It explains the output format (MP4) and implies duration control, but does not state whether the recording is real-time, if there are limits on duration, or how the file is returned (local path vs. captured). There is no contradiction with annotations because 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.

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

The description is a single sentence that efficiently conveys the core action and output format. It is front-loaded with the action. However, it could be slightly longer to include basic usage guidance without losing conciseness.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description provides minimal context beyond the action. It does not explain return values, file location, or recording behavior (e.g., real-time delay, max duration). While the schema describes parameters, the agent may need more behavioral context to invoke the tool correctly.

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

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

Schema documentation coverage is 100% for the 3 parameters, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides. It mentions 'specified duration' but does not clarify details like default value or path auto-generation already in the schema.

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

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

The description uses a specific verb ('Record') and resource ('simulator screen'), directly states the output format ('MP4'), and clarifies the action is time-bounded ('for a specified duration'). This clearly distinguishes it from sibling tools like 'screenshot' or 'log_stream'.

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

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

The description implies usage for screen recording but does not provide guidance on when to use this tool versus alternatives like 'screenshot' for a single frame or 'log_stream' for video logs. There is no mention of prerequisites (e.g., simulator must be booted) or explicit when-not-to-use scenarios.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and format, but omits key behaviors: whether the simulator must be booted, what state is captured, where the file is saved when outputPath is not set (auto-generated path location is not explained), and whether there are any side effects. This is insufficient for the agent to predict tool behavior.

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

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

The description is a single sentence of 9 words, which is very concise. It efficiently states the main action. However, while concise, it sacrifices valuable context that could be added without becoming verbose. A score of 4 reflects good conciseness with room to include brief but important behavioral notes.

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

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

Given the tool's simplicity (2 params, no output schema), the description is still incomplete. It lacks necessary context such as simulator state requirements, where the output file is stored when not specified, and whether the tool is destructive or read-only. The presence of siblings like 'screen_record', 'simulator_shutdown', etc., makes it unclear when this tool is the right choice. The description does not provide a complete picture for tool selection and invocation.

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

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

Schema description coverage is 100% (both 'deviceId' and 'outputPath' have descriptions in the schema). The tool description adds no additional information about the parameters beyond what the schema already provides. Per guidelines, baseline 3 is appropriate when schema does the heavy lifting, and there is no extra value from the description.

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

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

The description 'Capture a screenshot from a simulator as PNG' uses a specific verb ('capture') and clearly identifies the resource ('screenshot from a simulator') and output format ('as PNG'). This distinguishes it from siblings like 'screen_record' (video) and other simulator actions, making the purpose immediately clear.

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

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, particularly 'screen_record' or other capture-related tools. There is no mention of prerequisites (e.g., simulator must be booted) or conditions that would make this tool preferable. The agent is left to infer usage context from the name alone.

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

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

With no annotations provided, the description correctly identifies this as a read-only listing operation (no side effects). The phrase 'available on this machine' adds useful context about scope, which is non-obvious from the tool name alone.

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

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

The description is a single, short, front-loaded sentence that precisely communicates the tool's purpose without any wasted words.

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

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

For a simple parameter-less listing tool, the description is largely complete. However, it could benefit from mentioning that it requires a signed developer identity to be present, or hinting at the output format (e.g., certificate details), though no output schema exists to clarify this.

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

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

Schema description coverage is 100% because there are no parameters. The description adds no parameter details, but none are needed. Baseline 4 is appropriate for a zero-parameter tool.

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

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

The description uses a specific verb 'List' and a clear resource 'code signing identities available on this machine'. It clearly distinguishes itself from sibling tools like provisioning_profiles or keychain_list.

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

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

The description implies a simple listing use case, but provides no guidance on when to use this tool vs. alternatives like provisioning_profiles for inspecting signing identities, nor any conditions (e.g., prerequisite of having a development team set up).

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

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

With no annotations provided, the description carries the full burden. It only states the tool boots a device but doesn't disclose behavioral traits such as whether the device must already exist, if booting is synchronous or asynchronous, or what happens if the device is already booted (e.g., error vs no-op). No side effects or state changes are described.

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

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

The description is a single, short sentence that is front-loaded and to the point. It uses minimal words to convey the core purpose. While it could be a bit more specific, it earns its place without unnecessary fluff.

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

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

Given the low complexity (1 parameter, no nested objects, no output schema), the description is incomplete. It doesn't explain the boot process, prerequisites, or post-conditions. As a state-changing operation (booting a device), more context is needed for proper agent use.

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

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

Schema description coverage is 100% with one parameter (deviceId) described as 'Simulator UDID or name'. The description adds no additional meaning beyond what the schema already provides. Since coverage is high, baseline 3 is appropriate.

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

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

The description clearly states 'Boot a simulator device so it can be used', which identifies the action ('Boot') and the resource ('simulator device'). It distinguishes this tool from siblings like simulator_list, simulator_create, simulator_shutdown, etc. However, it doesn't specify what 'boot' means compared to 'open' (simulator_open), leaving a minor ambiguity.

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

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. For instance, it doesn't explain when booting is needed instead of just opening the simulator (simulator_open), or whether booting is required before app_launch. No prerequisites or usage context are mentioned.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the tool creates a copy, implying a non-destructive read/write operation. However, it doesn't mention side effects like whether the clone is automatically booted, requires same runtime, or if original simulator data is modified. It adds some value by stating 'identical copy', but lacks deeper behavioral details. No contradiction with annotations since 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.

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

The description is a single sentence that conveys the core action and outcome with zero wasted words. It is front-loaded and efficiently structured. Every word earns its place.

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

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

Given the tool's moderate complexity (two required parameters, no output schema, no annotations), the description provides the basic purpose but leaves gaps. It doesn't mention return behavior (e.g., does it return the new simulator's UDID?), necessary prerequisites (e.g., source simulator must exist and likely be shut down), or any constraints (e.g., name uniqueness). The context signals indicate no output schema and simple params, so some completeness burden falls on the description.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (deviceId and newName). The description adds 'existing simulator' context which implies deviceId refers to a source, but it doesn't provide additional semantics beyond the schema's descriptions. Baseline of 3 is appropriate since the schema covers the parameters well.

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

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

The description clearly states the action 'Clone' and the resource 'an existing simulator', with the outcome 'create an identical copy'. This is specific and distinguishes the tool from siblings like simulator_create (which creates new simulators from scratch) and simulator_list (which lists existing ones). No ambiguity or tautology.

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

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

The description implies usage when a user wants to duplicate a simulator, but it does not provide any explicit guidance on when to use this tool versus alternatives like simulator_create or simulator_erase followed by creation. There is no mention of prerequisites (e.g., whether the source simulator must be shut down) or exclusions. The context from sibling names helps, but the description itself lacks explicit guidance.

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

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

No annotations are provided, so the description must carry the behavioral burden. It states the action (create) implying a write/mutation operation, which is appropriate. However, it does not disclose whether this requires specific permissions, the effect of name collisions, or any cleanup needed. The description adds marginal behavioral context beyond 'Create' 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.

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

The description is a single, focused sentence that efficiently communicates the action and key parameters. It is not overspecified or verbose. However, it could be slightly more front-loaded by placing the core action ('Create a new iOS simulator') at the very beginning, though the current structure is still clear and compact.

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

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

For a create tool with 3 simple required parameters, no output schema, and no annotations, the description is minimally adequate but not comprehensive. It lacks details on expected outcomes, potential side effects (e.g., does creation block? is it immediate?), or error conditions. Given the complexity of iOS simulator internals (runtime availability, disk space), the description leaves gaps.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description merely restates the schema's purpose ('specified device type and runtime') without adding new semantics like valid value patterns or constraints beyond examples. Baseline 3 is appropriate—the schema does the heavy lifting, and the description offers no additional insight.

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

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

The description uses specific verbs and resources ('Create...iOS simulator with specified device type and runtime'), clearly distinguishing the action from sibling tools like simulator_boot, simulator_delete, or simulator_clone, which have different purposes. However, it does not explicitly differentiate from simulator_clone, which may also create a simulator instance.

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

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

The description implies usage context (creating a new simulator) but provides no guidance on when to use this tool versus siblings like simulator_list_runtimes or simulator_list_device_types, which are likely prerequisites. No exclusions or alternatives are mentioned, forcing the agent to infer context 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.

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 reveals that 'unavailable' triggers removal of all unavailable devices, but does not mention irreversibility, potential errors (e.g., deleting a booted device), or permission requirements. For a destructive tool, this is minimal.

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

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

The description is two concise sentences, front-loaded with the core action and the special case. Every word earns its place with no fluff or redundancy.

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

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 covers the primary use case and the important special value. It slightly lacks distinction from the sibling tool 'simulator_erase', but overall it is sufficiently complete given the tool's simplicity.

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

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

The schema already provides 100% coverage of 'deviceId' with a description of 'Simulator UDID or "unavailable"'. The description adds meaningful semantics by explaining that passing 'unavailable' removes all unavailable devices, which is not evident from the schema alone.

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

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

The description clearly states 'Delete a simulator device' with a specific verb and resource. It also explains the special value 'unavailable' for removing unavailable devices, which adds clarity and distinguishes the tool's scope.

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

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

The description provides clear context for the primary use and explicitly describes the special 'unavailable' case for bulk deletion. It does not explicitly mention when not to use the tool or name alternatives, so it stops short of a 5.

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

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. The description implies a destructive operation ('erase all content and settings'), which is transparent about the mutating nature of the tool. However, it doesn't mention what specific content/settings are affected (e.g., apps, data, preferences), whether the simulator must be booted or shutdown, or what the outcome is (e.g., returns to factory state).

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

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

The description is a single concise sentence that conveys the essential purpose without unnecessary words. It is front-loaded with the key action 'erase'. It earns its place but could benefit from slight expansion without losing conciseness.

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

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

Given the tool's destructive nature and lack of output schema, the description is incomplete. It doesn't document return values (e.g., void vs. confirmation), error conditions (e.g., invalid deviceId, simulator not available), or preconditions (e.g., simulator shutdown required). The single-parameter schema is simple, but the critical behavioral context is missing.

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

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

Schema description coverage is 100% with a single parameter 'deviceId' described as 'Simulator UDID'. The description 'Erase all content and settings from a simulator' adds no additional parameter semantics beyond what the schema already provides. The parameter is self-explanatory, so this is adequate but not additive.

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

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

The description 'Erase all content and settings from a simulator' clearly specifies the verb 'Erase' and the resource 'simulator', using phrasing familiar to iOS developers (similar to 'Erase All Content and Settings' on a device). It distinguishes itself from sibling tools like simulator_delete (which removes the simulator entirely) and simulator_shutdown (which just powers it off), but doesn't explicitly differentiate.

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

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

The description provides no guidance on when to use this tool versus alternatives like simulator_delete or when not to use it. It doesn't mention prerequisites (e.g., the simulator must be shutdown first) or scenarios where this is appropriate. There is no mention of side effects like data loss.

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

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

No annotations are provided, so the description must carry the behavioral burden. It states the tool lists simulators (a read operation), but does not disclose any side effects, permissions needed, or behavior when the optional filter is used. Adequate but not detailed.

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

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

A single, front-loaded sentence of 8 words with no filler. Every word contributes value. Highly concise.

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

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

For a simple list tool with one optional parameter and no output schema, the description is functional but sparse. It does not mention what additional fields (e.g., UDID, name) are returned, leaving the agent without full context of the response. Could be improved.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema-provided parameter description; it only echoes that state is included in the output. No enrichment of parameter semantics.

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

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

The description clearly states the verb ('List') and resource ('all iOS simulators'), and specifies that state information is included. This distinguishes it from siblings like simulator_list_runtimes and simulator_list_device_types.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., when needing to see available simulators before booting). The context of sibling tools provides implicit differentiation, but the description lacks direct usage advice.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states a read operation without mentioning any side effects, authorization requirements, rate limits, or prerequisites (e.g., whether a booted simulator is needed). The description is minimal.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every part of the sentence contributes to understanding the tool's purpose.

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

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

Although the tool is simple, the description does not specify the output format (e.g., list of strings, objects with properties). Without an output schema, more detail about the return value would improve completeness. It adequately covers the operation but lacks output context.

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

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

The tool has zero parameters, so the description does not need to add parameter details. The input schema coverage is 100% (empty schema). The description adds no specific parameter semantics, but a baseline of 4 is appropriate given no parameters exist.

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

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

The description clearly states the action (List), the resource (simulator device types), and provides examples (iPhone, iPad, Apple Watch). This effectively distinguishes it from sibling tools like simulator_list (which likely lists devices) and physical_device_list.

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

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

While the tool's purpose is straightforward with no parameters, there is no explicit guidance on when to use this versus alternatives like simulator_list or simulator_list_runtimes. Usage is implied, but the description does not provide context for selection.

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

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 describes a read-only listing operation, which implies no side effects. For a simple list tool, this is sufficient transparency, though it could mention whether runtimes from Xcode or third-party sources are included.

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

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

The description is a single, front-loaded sentence with no wasted words. It concisely communicates the purpose and scope.

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

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

For a parameterless list tool with no output schema, the description is nearly complete. It could optionally mention that runtimes correspond to Xcode SDK versions or that output includes version identifiers, but the current text is adequate for an agent to understand what it returns.

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

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

The tool has zero parameters and schema coverage is 100%, so the schema provides no ambiguity. The description adds value by naming the specific runtimes listed, which helps the agent understand the output scope without needing param details.

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

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

The description states 'List available simulator runtimes' with specific examples (iOS, watchOS, tvOS, visionOS), which clearly identifies the verb, resource, and scope. It also distinguishes from sibling tools like 'simulator_list' which lists devices, and 'simulator_list_device_types' which lists device type templates.

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

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

The description implies this is for discovering runtime options before booting or creating simulators, which is clear context. However, it does not explicitly state when not to use it or name alternatives for related tasks like checking installed versions.

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

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

No annotations are provided, so the description must fully disclose behavior. It merely says 'Open Simulator.app and display the specified device,' which implies it launches an app and selects a device, but it does not state whether this is a blocking call, whether it requires the simulator to be installed, or if it fails silently for uninstalled runtimes. The behavioral traits are underspecified.

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

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

The description is exceptionally concise at 8 words, with no filler. However, it may be too concise—it omits critical behavioral details that could be added without sacrificing brevity. Still, it front-loads the action and avoids redundancy.

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

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

Given the single parameter and lack of output schema, the description should cover setup, execution, and expected outcome. It lacks mention of fallback behavior (e.g., if device is not found), error handling, or typical use cases. For a tool with 42 siblings, this incomplete context hinders correct agent selection.

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

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

The input schema covers 100% of parameters with a single 'deviceId' described as 'Simulator UDID'. The description adds minimal value by linking the parameter to 'display the specified device'. Since schema coverage is complete and the description reinforces the parameter's role, a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Open' and the resource 'Simulator.app', and specifies that it 'display the specified device' via a deviceId. This distinguishes it from sibling tools like simulator_boot (which boots without necessarily opening the app interface) and simulator_list (which lists devices). The purpose is clear but could be slightly more specific about what 'display' entails.

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

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 vs alternatives such as simulator_boot or simulator_list. It does not specify prerequisites (e.g., the device must already exist or the simulator must be installed) or mention that this tool should be used before launching apps. With 42 sibling tools, this lack of context makes it harder for an AI agent to select correctly.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action ('shutdown') without explaining side effects (e.g., whether state is saved, if running apps are terminated, or if the simulator can be rebooted later). The agent is left guessing about the tool's consequences.

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

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

The description is a single sentence with no wasted words. It is front-loaded and efficient, earning its place.

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

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

For a simple tool with one optional parameter and no output schema, the description is adequate but not exemplary. It lacks details about return value, success indicators, or error cases. Given the low complexity, a 3 is reasonable.

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

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

Schema description coverage is 100% (1 parameter with full description). The description adds no new meaning beyond the schema, which already states 'Simulator UDID or "all" (default: "all")'. 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.

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

The description specifies a clear verb ('Shutdown') and resource ('simulator or all simulators'), distinguishing it from siblings like simulator_boot, simulator_delete, and simulator_erase. It is unambiguous and unique among the sibling tools.

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

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 vs alternatives such as simulator_erase or simulator_delete. There is no mention of prerequisites, warnings (e.g., data loss), or scenarios where shutdown is appropriate versus other actions.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. The description only says 'Resolve SPM dependencies', implying a write/mutation operation but does not explain side effects (e.g., downloads, lockfile updates), required permissions, or whether it's safe to run repeatedly. This is a significant gap for a tool that likely modifies project state.

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

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

The description is a single concise sentence that clearly states the core function. It front-loads the action and avoids unnecessary words. Could be slightly improved by adding brief context about use cases.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description should provide more context about return values, side effects, or prerequisites. It is minimally viable but not complete. For instance, it doesn't indicate whether the tool outputs logs or errors, or how long resolution might take.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The description adds no extra parameter guidance beyond what the schema provides, but the schema itself is well-documented. Parameters are optional, and the description doesn't clarify interactions (e.g., if both scheme and projectPath are needed). However, with full schema coverage, a score of 4 is justified.

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

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

The description states the verb 'Resolve' and resource 'Swift Package Manager dependencies for a project', which is clear. However, it doesn't distinguish itself from sibling tools like spm_update or spm_show_dependencies, which are closely related package management operations. The purpose is adequate but lacks sibling differentiation.

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

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 (e.g., spm_update vs. resolving), nor does it mention prerequisites like requiring SPM dependency files. It is a single statement without usage context or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool outputs, but does not reveal whether it is read-only, requires network access, modifies state, or has side effects. For a tool that reads project configuration, 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.

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

The description is a single sentence, which is concise, but it lacks necessary detail. It is front-loaded with the action, but the brevity comes at the cost of completeness. A more informative description of similar length could include usage hints or output shape.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description minimally covers what it does. However, it does not explain the structure of the dependency tree output, whether it shows transitive dependencies, or what happens if projectPath is omitted (e.g., current directory). This leaves an agent with unanswered questions.

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

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

Schema coverage is 100% (the single parameter 'projectPath' has a description in the schema: 'Project directory containing Package.swift'). The description adds no additional meaning beyond the schema. According to the rubric, high schema coverage yields a baseline of 3, and the description does not improve upon it.

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

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

The description clearly states the verb 'Show' and the resource 'Swift Package Manager dependency tree', and specifies the output format 'as JSON'. This distinguishes it from sibling tools like spm_resolve (which resolves dependencies) and spm_update (which updates packages), making the purpose immediately clear.

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

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 does not mention prerequisites (e.g., whether the project must be resolved first), nor does it suggest cases where another tool like spm_resolve would be more appropriate. The agent must 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.

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

No annotations are provided, so the description must fully disclose behavioral traits. It only says 'update dependencies to latest allowed versions', but does not explain whether it modifies Package.resolved, requires network access, handles version conflicts, or is a safe operation. For a mutation tool, 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.

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

The description is a single sentence, concise and to the point. It could be slightly improved by front-loading the key action, but it is efficient and free of unnecessary words.

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

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

Given the tool's complexity (one parameter, no output schema, no annotations), the description is too minimal. It does not mention return values, side effects, or constraints. A user or agent would need additional context to use this tool safely.

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

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

Schema description coverage is 100% (the single parameter 'projectPath' is described as 'Project directory containing Package.swift'). The tool description adds 'latest allowed versions' which provides some context, but does not add significant meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'update' and the resource 'Swift Package Manager dependencies', specifying 'latest allowed versions'. It distinguishes from sibling tools like spm_resolve (which resolves without updating) and pod_update (which updates CocoaPods).

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

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 does not mention prerequisites (e.g., needing a Package.swift), when to prefer spm_resolve, or when updates might fail. The context signals show many sibling tools, but the description offers no differentiation.

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

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 accurately indicates a non-destructive reset operation (no data loss as it resets visual state). However, it does not disclose what the 'default values' are or confirm if any state is lost (e.g., all custom overrides cleared). It adds moderate context beyond the schema.

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

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

The description is extremely concise—one sentence with no fluff. Every word serves a purpose, front-loading the action and result. It is appropriately sized for a simple tool.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description adequately covers its purpose. No output schema exists, but the tool likely returns a success status. The context from sibling tools helps infer its use. It could mention that the simulator must be booted, but for a reset operation with one param, it is largely complete.

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