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

With no annotations at all, the description carries the full burden and does real work: it discloses the side effect (installation onto the device), the return value (bundle ID), and that signing relies on the project's own settings so no signing parameters are needed. It leaves out failure modes such as signing errors or build duration, which keeps it from a 5.

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?

Three short sentences, front-loaded with the verb and resource, then scope, then return value, then signing behavior. Nothing is repeated from the schema except a brief reinforcement of the install default.

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?

No output schema exists, and the description compensates by naming the returned bundle ID. Defaults and the single required parameter are covered via the schema. The remaining gap is the unexplained project-vs-workspace choice and no note on what a failed build 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?

Schema coverage is 83%, with the device fallback chain and the install default already documented in the schema. The description only echoes the install default and does not clarify the mutually exclusive project vs workspace parameters, which is the main ambiguity an agent faces here.

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?

States a specific verb and resource ('Build an Xcode project/workspace scheme') and adds two scope facts an agent needs: it installs by default and returns the bundle ID. It stops short of naming siblings, so the overlap with install_app is left for the agent to infer.

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 parenthetical '(by default) install it' implicitly signals that install_app is a narrower alternative, and the device parameter's schema description documents the selection fallback chain. However, there is no explicit when-to-use/when-not guidance or statement of prerequisites such as needing a configured scheme.

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. It does well on the return contract — one element per line, field order, coordinate units in points — but says nothing about prerequisites, cost/latency, or what happens when no foreground app or alert exists. The includeOffscreen behavior is also left undisclosed.

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: resource first, then the line format, then the practical payoff about coordinates. Every clause — including the alert-merge and points-unit notes — carries information an agent needs; nothing is padding.

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 must — and does — describe the return format in enough detail to parse it. Remaining gaps are moderate: the undocumented includeOffscreen flag and no statement of session/driver prerequisites for a tool that reads the live foreground app.

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 75%, just under the threshold where the schema alone suffices, so the description is expected to compensate a little. It adds nothing about the parameters themselves — format=json/text behavior, bundleId override, and includeOffscreen are documented only in (or, for includeOffscreen, not at all 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 names the exact resource (accessibility tree of the foreground app, plus system alerts) and the output shape, so an agent knows precisely what it gets back. It does not explicitly distinguish itself from the visual alternative (screenshot) or from tap_element, but the resource is specific enough to differentiate in practice.

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?

Usage is only implied: the closing note that coordinates 'can be passed to tap' tells the agent this is a pre-tap inspection step. There is no explicit when-to-use/when-not guidance, no mention of screenshot as the alternative for visual layout, and no stated prerequisite (e.g. that the driver/session must be active).

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, but it only states the gesture and coordinate unit. It omits effects (e.g., zoom/selection), timing requirements, error behavior, and whether the device parameter changes targeting.

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 definition is a single front-loaded sentence with zero wasted words. It is appropriately sized for a simple gesture 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?

The tool is simple and the schema fully documents its three parameters, so the description need not explain return values. However, with no annotations and no usage guidance, the description leaves gaps around when to choose this gesture and what the interaction does.

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%, including detailed x/y and device descriptions, so the schema already explains all parameters. The description reinforces the coordinate unit ('points') but adds no meaning beyond what the schema provides.

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 a specific action (double-tap) at a specific target (coordinates in points), which distinguishes it from tap and tap_element. It does not explicitly name or differentiate from siblings, but the purpose is 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?

There is no guidance on when to use double_tap instead of tap, tap_element, long_press, or other interaction tools. The agent must infer the choice entirely from the tool name.

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. It usefully discloses the line format ('<timestamp> App[pid:tid] [category] message'), which tells the agent what the payload looks like, but omits whether reads accumulate from launch, whether buffer size is bounded, and only implicitly signals that clear discards data. Adequate but leaves real behavioral gaps for a no-annotation 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?

Two sentences, both load-bearing: the first gives purpose and the precondition, the second gives the exact output shape. Nothing is wasted and the critical constraint is front-loaded.

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?

No output schema exists, so the description must convey the return shape, and it does via the sample line format; the schema covers paging via lines and filtering via grep. Minor gaps remain around buffer lifecycle and whether output is joined text or an array, but nothing that would cause a mis-call.

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 80% and the schema already documents grep, clear, lines, and device well, so the baseline is 3. The description's line-format detail does help the agent construct the category regex for grep (e.g. \[network\]), which is a modest value-add 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?

States a specific verb and resource ('Read console output captured from an app') and names the precondition (started with launch_app captureLogs=true), which no sibling provides. An agent can immediately distinguish this from screenshot, describe_ui, or list_apps.

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 makes the precondition for use explicit: the app must have been launched with captureLogs=true. It does not state what to do when that precondition is unmet or mention any alternative tool, but no sibling offers log access, so the routing risk is low.

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 disclosure burden, and it is a mutation tool on a device. It says nothing about whether an existing install is overwritten, whether the device must be booted/connected, signing or provisioning requirements, failure modes, or what is returned. Only the file type accepted is disclosed.

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 front-loaded sentence with zero filler and the artifact scoping up front. Its brevity is efficient but tips into under-specification rather than crispness.

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 device-mutating install with no annotations, no output schema, and one undocumented parameter, the description should cover device targeting, overwrite behavior, and prerequisites. None of that is present, so an agent cannot predict the outcome of a call from the definition 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?

Schema coverage is 50%, and the description compensates partially for the undocumented 'path' parameter by naming the accepted artifact types (.app or .ipa). It adds nothing on path format (absolute vs relative, host vs device path), and the well-documented 'device' parameter is left entirely to 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?

States a specific verb (Install) and resource (a built .app/.ipa onto the device), and the word 'built' hints at the build_app → install_app sequence. It does not name or differentiate from close siblings like uninstall_app or launch_app, so it stops short of a 5.

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

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

Usage is only implied: 'built' suggests the artifact must exist first and the target is a device, which weakly routes the agent after build_app. There is no explicit when-to-use / when-not guidance and no mention of what to do instead if the app is already installed (uninstall_app) or how it relates to launch_app.

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 exist, so the description carries the full burden. It does disclose two real behaviors beyond the schema: the app is brought to the foreground, and when captureLogs is set, console output is buffered for get_app_logs (an explicit handoff to a sibling). It omits error/precondition behavior (app not installed, already running) and what is returned.

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?

Two sentences, zero filler, with the primary action front-loaded and the secondary logging behavior following. Nothing here is redundant with the schema.

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 6-parameter, no-annotation, no-output-schema tool with a nested environment object, the description covers the core action and one parameter's side effect but leaves launch arguments, environment injection semantics, and return value unexplained.

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 33%, so some description compensation is required. The description explains captureLogs' effect and its link to logLevel ('console output'), which is genuinely additive since captureLogs itself has no schema description. However, device, arguments, environment, and the bundleId format remain undocumented anywhere.

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?

Specific verb+resource: 'Launch (or relaunch) an app in the foreground' tells the agent exactly what the tool does, including the relaunch semantic. It doesn't distinguish itself from siblings like install_app or open_url, so it stops short of 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?

No guidance on when to use this versus install_app, open_url, or whether terminate_app should precede a relaunch. The parenthetical '(or relaunch)' implies a usage path but never states it as 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 exist, so the description carries the full burden. It discloses the significant dev-signed-app constraint, but says nothing about whether the app must be installed or running, whether output is recursive, or how large listings behave.

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?

Two short sentences, both earning their place; the core action is front-loaded and the constraint follows. No filler or repetition of the tool name.

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 no output schema and no annotations, the description should say more about the return shape (file names? sizes? paths?) and the required app state. The dev-signed caveat is the one behavioral piece covered; the rest of the picture 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 coverage is 67%: device and subdirectory are documented, but bundleId is not. The description marginally enriches subdirectory by naming Documents, Library and tmp as valid containers, but adds nothing about bundleId or the device fallback chain 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?

States a specific verb and resource ('List files in an app's data container') and clarifies scope with example container directories. It does not distinguish itself from the nearest sibling, pull_file, which also deals with on-device files, so an agent must infer the difference.

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 clause 'Works for development-signed apps only' gives a real precondition for use, which is implied guidance. However, there is no explicit when-to-use vs. pull_file or list_apps, and no statement of what happens with a release-signed bundle.

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 disclosure burden, yet it only adds the word 'installed'. It does not say whether the result contains bundle identifiers or display names, whether system apps are excluded by default, or what happens when no device is connected or multiple devices match.

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 with zero waste. It is efficient, but the terseness edges toward under-specification rather than optimal density.

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 two fully documented optional parameters, so the schema covers the mechanics. However, with no output schema the description should at least indicate what a listed app looks like (identifier vs. display name), since downstream calls like launch_app or uninstall_app depend on that form.

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 the two parameters are already documented, and the description adds nothing on top. Notably it omits the behavioral default for includeSystem (system apps excluded unless set), which is meaningful for callers even though the schema documents the field.

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?

States a specific verb and resource ('List apps installed on the device'), which is immediately actionable. It does not differentiate itself from adjacent siblings such as list_devices or list_app_files, so an agent must infer the boundary from names alone.

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 versus list_devices or list_app_files, and no mention of prerequisites (e.g., that a device must be selected or connected). The agent gets a purpose but no routing rules.

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 carry the whole burden; 'List' conveys read-only and 'known to this Mac' hints at local tooling scope, and it discloses that connection state and the default marker are returned. It omits what happens when no devices are connected and gives no indication of the discovery mechanism or failure modes.

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

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

Two short sentences, front-loaded with the verb and resource. The second sentence ('The device tools use by default is marked') is grammatically awkward and slightly slows parsing, but nothing is redundant.

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 has to convey the return value; it names connection state and the default marker but not the device identifier format or ordering, which an agent needs when chaining into select_device. Adequate but with a visible 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly adds no parameter prose.

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?

States a specific verb and resource ('List physical iPhones/iPads known to this Mac') plus the extra payload ('with connection state'), which distinguishes it from list_apps and the app-manipulation siblings. It falls short of 5 only because it doesn't explicitly contrast with select_device, the closest conceptual sibling.

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 mention of a default-marked device implies a discovery-then-select workflow, so an agent can infer this is the entry point before calling select_device. But no explicit when-to-use, prerequisites, or named alternative is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and omits details like the effect of duration, what a long press might trigger (e.g., context menus), or any side effects.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the essential 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 tool's simplicity and the fully described schema, the description covers the core action adequately. However, for a UI interaction tool, it lacks usage context and behavioral details that would help an agent decide when to invoke it.

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 the input schema already documents all parameters. The description adds 'coordinates (points)' which aligns with the schema but does not provide additional semantics beyond what is already specified.

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 a specific verb ('press and hold') and resource ('coordinates'), making the core action clear. However, it does not explicitly differentiate this tool from siblings like tap or double_tap, which also involve pressing at coordinates.

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 long_press versus alternatives such as tap or double_tap. The description offers no context about scenarios that require a long press.

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. It does add that custom schemes and universal links are supported, which is useful behavioral context, but it says nothing about mutating side effects, what happens on an invalid or unhandled URL, whether a session must be running, or what is returned.

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 with no filler; the parenthetical adds real information rather than padding. Nothing could be removed without losing meaning.

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 no annotations and no output schema, the description should cover prerequisites and outcome behavior for a side-effecting device action, but it does not. An agent cannot tell whether it needs a driver session, what constitutes failure, or what the call 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?

Schema coverage is 50%: the 'device' parameter is well documented in the schema with a clear default-resolution chain, while 'url' has no schema description. The description compensates partly by defining url as a URL or deep link with custom-scheme/universal-link forms, but offers no format, encoding, or validation guidance.

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 names a specific verb and resource ('Open a URL or deep link') and clarifies the accepted forms (custom scheme or universal link), which genuinely distinguishes it from launch_app. It stops short of explicitly contrasting itself with the app-launch sibling, but an agent can infer the difference.

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 statement of when to use this instead of launch_app or tap (e.g., to trigger a deep link into an installed app), nor any prerequisites such as the device being booted or a driver session being active. Usage is only implied by the verb.

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 behavioral burden and only discloses that 'home' navigates to the home screen. It says nothing about what volumeUp/volumeDown do, whether a driver/session must be active, whether the action is reversible, or what errors occur for unsupported buttons.

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?

Two short sentences, front-loaded with the core action, and the second sentence adds useful behavioral context. It is efficient, though the terseness borders on under-specification rather than pure 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?

For a device-control tool with no annotations and no output schema, the description is thin: it omits volume-button semantics, session/driver prerequisites, and any indication of success or failure behavior. The schema's device default helps, but the tool's overall contract is not sufficiently described.

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 only 50%, and the description compensates for just one of the three enum values ('home'). The volumeUp and volumeDown enum values remain undocumented, and the description adds nothing about the 'device' parameter beyond the schema's own substring/default explanation.

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?

States a specific verb and resource ('Press a hardware button'), which distinguishes it from screen-level siblings like tap and tap_element. However, it only explains the 'home' value and never mentions that volumeUp and volumeDown are also valid targets, so the purpose is clear but incompletely framed.

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 explicit guidance on when to use this versus alternatives such as tap, tap_element, or set_volume, despite obvious overlap with set_volume for volume changes. The hardware-button framing implies usage but gives no exclusions 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that small text files are returned inline and that polling/waiting is supported, but says nothing about error behavior, permissions, or what happens for large files (only inferable from the schema's destination default).

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?

Two compact sentences with the core action front-loaded and no filler. Efficient and well-structured.

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 no output schema and no annotations, the description should explain results more fully. It notes small text files come back inline but leaves unclear what happens to non-text/large files (written to destination) and how failures surface.

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 83% (high), so the baseline is 3. The description's mention of waiting-for-appearance and 'after the last launch_app' loosely maps to waitSeconds and modifiedAfter, adding some meaning, but the schema already documents these params thoroughly.

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?

States a specific verb (copy) and resource (a file out of an app's data container to the Mac), which clearly distinguishes it from list_app_files, the sibling that enumerates rather than extracts. The distinction is implicit rather than named, so not a full 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 implies usage through the waiting modes ('wait for the file to appear, or to be written after the last launch_app'), but never explicitly says when to choose pull_file over list_app_files or other siblings. Guidance is implied, not stated.

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 present, the description carries the full burden: it discloses only that it records the built-in Mac mic and returns a WAV path. It omits whether the call blocks for the full duration, whether macOS microphone permission prompts can occur, where the file is written, and whether prior recordings are overwritten — all material for a capture 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?

Two short sentences, zero filler, with the action and scope front-loaded and the return value stated second. Nothing is wasted.

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 capture tool with no output schema, the description covers what it does and what it returns, which is close to sufficient. It could mention the 300-second cap and permission/blocking behavior to be fully self-contained.

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 50%: audioDevice is already documented in the schema, while 'seconds' has no schema description. The description compensates partially by framing 'seconds' as a recording duration and by tying the tool to 'the Mac microphone' (reinforcing the audioDevice default), but gives no format or range guidance.

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?

States a specific verb and resource ('Record the Mac microphone') plus the duration semantics and the return value ('Returns the WAV path'). No sibling tool (tap, screenshot, list_devices, etc.) overlaps with audio capture, so an agent can identify it immediately.

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 parenthetical '(e.g. to capture what the device plays)' gives a concrete use context that clarifies why an agent would choose this over screenshot/describe_ui. It names no alternatives or exclusions, so it stops short of full routing guidance, but the intent is clear.

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, so the description carries the full burden. It usefully discloses the default scaling behavior and the resulting coordinate correspondence, but says nothing about what is actually returned (image payload, dimensions), whether it fails on a non-booted device, or any cost/latency of full-res capture.

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?

Two short sentences, purpose front-loaded, with the behavioral caveat second. No filler, nothing repeated from the schema.

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-annotation, no-output-schema tool, the description covers the coordinate semantics well but leaves the agent guessing about the return value and about session/device readiness requirements, which matter for calling it correctly in a device-control workflow.

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 earns above that by making the implicit default explicit — that scaling to screen points is the default state of fullRes=false and why it matters (pixel coords equal tap coords). It does not discuss the device parameter's fallback chain, but the schema already documents that fully.

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?

States a specific verb and resource ('Take a screenshot') immediately, with an added scope note about output scaling. It does not differentiate itself from the overlapping sibling describe_ui, which also returns visual state, but the core 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?

The coordinate-equivalence note implies the intended workflow (screenshot before tap), but the description never says when to use this versus describe_ui or list_devices/select_device, and gives no prerequisites such as needing a started session.

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 and does disclose the underlying gesture (swipe from screen middle) and directional semantics. It says nothing about what happens at the end of scrollable content, whether the call waits for the gesture to settle, or what is returned — meaningful gaps for a no-annotation 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?

One sentence, front-loaded with the action, with the disambiguating detail about direction placed where it is needed. No filler or repetition of schema content.

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?

No output schema exists, so the description should cover behavior and return expectations, and it only partly does. It is adequate for invoking the tool but leaves end-of-content behavior and result reporting unstated for a 3-parameter interaction 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 coverage is 67%; the 'amount' and 'device' parameters are already documented in the schema, but 'direction' has only an enum and no description. The description supplies exactly that missing meaning ('down' reveals content further down), adding genuine value beyond the structured fields.

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?

States a specific verb (scroll) and resource (content) plus the mechanism (swiping from the middle of the screen), and clarifies the ambiguous 'down' case. It implicitly separates itself from the generic sibling 'swipe' via the middle-of-screen gesture, though it never names swipe directly.

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 direction gloss ('down' reveals content further down) tells the agent how to pick a value, which is real usage guidance. However, there is no statement of when to prefer this over swipe, tap_element, or describe_ui, and no preconditions (e.g., content must be scrollable).

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 load and does disclose key state behavior: the choice is session-scoped and shared across every agent hitting the server, which is a non-obvious side effect. It does not say what happens on an unknown device or an ambiguous name substring, so error behavior remains undisclosed.

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?

Three tight sentences, front-loaded with what the tool does, then the multi-agent caveat, then the clearing instruction. No filler and nothing important buried at the end.

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 single-optional-parameter tool with no output schema, the description covers effect, lifetime, sharing scope, and reset. The only real gap is failure semantics for a nonexistent or ambiguous device identifier, a minor omission 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?

Schema coverage is 100%, so the parameter is already documented as 'Device UDID or name substring; omit to clear'. The description adds genuine meaning beyond the schema by explaining how the stored value is consumed by later calls that omit 'device', which the schema does not convey.

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?

States a specific verb (choose) and resource (device) plus the exact effect: it sets the default device for later calls that omit 'device'. That is clearly distinct from siblings like list_devices or install_app, so an agent can identify it without opening the schema.

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

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

Explicitly gives when-to-use (set a default for subsequent calls), when-not-to-use (parallel agents on different devices should pass 'device' per-call instead), and how to undo (omit 'device' to clear). All three routing questions an agent could have are answered in the description itself.

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. 'Rotate' implies a state-changing operation, but the description does not disclose whether a device must be selected or connected, whether running apps are affected, whether the change is persistent, or whether orientation support varies by app or device.

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. For a simple orientation-setting action, this is appropriately concise, though brevity contributes to the gaps scored elsewhere.

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 annotations, no output schema, and only half of its parameters are described in the schema. The description does not compensate by explaining device selection behavior, orientation semantics, prerequisites, or expected effects, leaving important context for an agent incomplete.

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 only 50%. The optional device parameter is well documented in the schema itself, while the required orientation parameter has an enum but no explanation of the values or effects. The description adds almost no parameter-level meaning beyond the word 'interface'.

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 a specific verb (rotate) and resource (the device's interface orientation). No sibling tool in the list covers orientation control, so it is clearly distinguishable from the surrounding device-interaction 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?

It says what the tool does but gives no guidance on when to use it, when not to use it, prerequisites such as an active device connection, or any alternative approach. The agent must infer usage entirely from the name and schema.

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 and does well: it discloses that the operation works by emitting button presses (a real side effect on device volume), that it verifies each step against the system volume indicator (implying a multi-step, non-instant operation), and that the achieved level is quantized to 1/16 on iOS. It stops short of stating failure modes or whether the device must be unlocked/foregrounded.

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?

Three tight sentences: what it does, how it does it with its precision caveat, and what it returns. Front-loaded with the action and no 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?

For a two-parameter tool with no output schema, the description covers the return value ('final level') and the precision limitation, which are the two things an agent most needs. Remaining gaps — behavior when the target can't be reached exactly, and any device-state prerequisites — are minor.

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 the baseline is 3, but the description adds real information beyond the schema: the schema presents 'level' as a continuous 0–1 number while the description reveals it is effectively quantized to 1/16 steps. That changes how an agent should choose and interpret the value.

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?

States a specific verb and resource ('Set the device's media volume') and goes further by naming the mechanism (volume button presses) and the verification method. An agent can tell this apart from the sibling press_button tool, which is a raw input primitive, without opening either schema.

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?

Usage is implied by the mechanism description — this is the high-level way to reach a target volume rather than pressing buttons manually — but there is no explicit when/when-not statement and press_button is never named as the alternative for cases where this approximation isn't good enough. The context is inferable but not stated.

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 and does well: it warns that the first run builds the runner and that iOS will prompt for a passcode, which is critical context an agent would otherwise be surprised by. It omits what happens if the driver is already running (no-op vs error) and any timing/timeout expectations.

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?

Two tight sentences with zero waste; the core action is front-loaded and the caveats follow. Nothing is redundant or padding.

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 two-param tool with no output schema and no annotations, the description covers the essential surprises (auto-start, first-run build, passcode prompt). It could be slightly more complete by stating idempotency behavior when already started or what a successful start means for subsequent UI tools.

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 both 'device' and 'rebuild' are already fully documented in the schema, including device fallback resolution. The description adds no further parameter guidance and doesn't connect the build-on-first-run behavior to the 'rebuild' flag.

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?

States a specific verb and resource ('Start the on-device XCUITest driver') and implicitly contrasts with stop_driver in the sibling list. An agent can tell immediately what this tool does and what it targets.

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 parenthetical 'UI tools start it automatically' tells the agent it usually doesn't need to call this explicitly, which is a real usage signal. It stops short of explicitly naming stop_driver or saying when a manual start is warranted (e.g., after stop_driver or before a batch of UI 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 carries the full burden. It does not disclose that stopping the driver halts device control, whether in-flight sessions are affected, whether it is reversible via start_driver, or what errors occur if no driver is running.

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 with no filler. It is efficient, though its brevity reflects under-specification rather than disciplined concision.

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 state-changing tool with no annotations and no output schema, an agent still needs to know that this disables subsequent device operations and how to restore functionality. None of that context is present.

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 device parameter's fallback chain (select_device, env var, single USB device) is fully documented in the schema. The description adds nothing beyond it, which meets the baseline for fully-covered schemas.

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?

Clearly states the specific verb and resource: stopping the on-device driver. The counterpart sibling start_driver makes the scope inferable, but the description never explicitly differentiates itself from it or from terminate_app-style 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?

No indication of when to call this versus leaving the driver running, or what should precede/follow it (e.g., session teardown). The only implied guidance comes from the sibling name start_driver, not the description itself.

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, yet it discloses nothing about side effects (inertial scrolling, unintended app state changes), required device selection, or default gesture timing. The only behavioral hint ('points') is ambiguous about units and coordinate space (screen vs. app).

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 single sentence is efficient and front-loaded with the verb, but its brevity reflects under-specification rather than tight writing — nothing beyond the bare action is stated.

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 6-parameter gesture tool with no annotations and no output schema, the description omits coordinate semantics, duration/default timing, device targeting, and the return/observable result. It is not complete enough for an agent to invoke it 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 only 33% (duration and device are documented in-schema; the four coordinate params are not). The description's '(points)' is the sole clue for fromX/fromY/toX/toY and does not clarify units, coordinate origin, or screen-vs-device space, so it fails to compensate for the coverage gap.

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 verb+resource ('Drag from one point to another') identifies a swipe/drag gesture, which is meaningfully distinct from siblings like tap and long_press. However, it never states the tool's scope (gesture on the currently selected device/screen) or how it differs from scroll, leaving the purpose only loosely defined.

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 when-to-use or when-not-to-use guidance. The agent must infer on its own that swipe is for drag gestures and that scroll might be preferred for list navigation, with no explicit routing between these overlapping siblings.

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 exist, so the description carries the full behavioral burden and does not deliver: it never says this injects input into a live device, how the target device is resolved, or that recordAudio changes the timing/environment of the tap. The recordAudio mechanics are described only in the schema, not here.

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 with no waste. It is efficient, though its brevity borders on under-specification for a device-input 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 mutating device-input tool with no annotations, no output schema, a device-selection fallback, and a nested audio-recording side effect, one sentence about coordinates leaves critical context unaddressed at the tool 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 coverage is 100% and every parameter, including the nested recordAudio object and device resolution, is fully documented in-schema. The description's only added semantics is the '(points)' unit hint, which the schema already repeats for x and y.

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?

States a specific verb (tap) and resource (screen coordinates) with the unit qualifier 'points'. It implicitly separates itself from tap_element by specifying coordinates rather than an element, but never names the sibling explicitly.

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

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

Usage is only implied: the coordinate-based phrasing hints at raw-position tapping versus element-based alternatives like tap_element, long_press, or double_tap, but no when/when-not guidance or alternatives are stated.

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, and it does disclose two real behaviors: it blocks until the element appears and it taps the element's center rather than an arbitrary point. It says nothing about what happens on timeout (error vs. silent no-op), nor about the scroll-retry and audio-recording modes that meaningfully change what the call does.

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 with no filler: lookup criteria first, then wait, then tap target. It is efficient, though for a 10-parameter tool with a nested recordAudio object it is arguably thinner than the surface area warrants.

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?

Ten parameters, a nested audio-recording object, and a scroll-and-retry mode, with no annotations and no output schema, yet the description covers none of the failure semantics or the side-channel features. For a tool this complex, one sentence leaves the agent to discover significant behavior from 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already explains exact/index/scrollDirection/recordAudio in detail. The description adds no interpretation of its own — notably it doesn't explain precedence among id/text/type or how index interacts with the match scoring.

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 names a specific verb (tap) and resource (element located by text/identifier/type), and adds the lookup-and-wait behavior that distinguishes it from a raw coordinate tap. It never names its closest siblings (tap, wait_for_element, double_tap), so the differentiation is inferable rather than stated.

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?

Usage is only implied: 'waiting for it to appear' suggests it fits flaky/off-screen elements better than a plain tap, but there is no explicit when-to-use, when-not-to-use, or pointer to wait_for_element/double_tap/long_press as alternatives. An agent must infer the choice from the sibling names 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 behavioral burden. "Force-quit" implies a forceful termination that may lose unsaved state, but the description does not state permissions, reversibility, effects on running app data, or what happens if the app is not running.

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

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

The description is front-loaded and free of filler. It is extremely terse, but its brevity is not caused by redundant or poorly ordered 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?

For a mutation tool with no annotations and no output schema, the description is too thin. It omits required-parameter meaning, device targeting behavior, and the effect of force-quitting on the app or its data.

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 only 50%, and the required bundleId parameter has no schema description. The description does not explain that bundleId identifies the app to terminate or how the optional device parameter affects targeting, so it fails to compensate for the coverage gap.

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 a specific verb and resource: force-quit an app. This is clear enough to distinguish it from open_url, install_app, and launch_app, though it does not explicitly contrast with uninstall_app.

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 such as launch_app or uninstall_app, nor are there prerequisites or exclusions. The phrase "force-quit" implies forced termination, but no explicit usage conditions 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 the burden. It usefully discloses the focus prerequisite and the newline-to-return behavior, but says nothing about whether text is appended to existing content, what happens when no field is focused, or any error/return behavior.

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

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

Two short sentences, front-loaded with the action and its prerequisite, then the one formatting gotcha. Nothing wasted and nothing buried.

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 4-parameter, no-annotation, no-output-schema tool, the schema already covers device selection and the submit/deleteCount options, and the description covers the focus precondition and newline behavior. The main remaining gap is append-vs-replace semantics, which is only hinted at by deleteCount.

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 75% and the schema documents device, submit, and deleteCount well. The description adds genuine semantics the schema lacks: the text parameter's newline handling ("Use \n for return"), which is non-obvious and affects how the agent constructs the payload.

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?

Specific verb (type) plus resource (focused text field), which cleanly separates it from tap/tap_element (used to focus) and from press_button. It doesn't name a sibling explicitly, but the parenthetical prerequisite does the routing work implicitly.

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?

"(tap the field first)" gives a concrete precondition for correct invocation, effectively pointing the agent at tap_element/tap before calling this. No explicit when-not cases or named 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. It does notably disclose that the app's associated data is destroyed, which is the single most important behavioral fact for this destructive operation. However, it omits whether the action is reversible, required permissions/device state, and what happens if the bundle is not installed.

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 short sentence with zero waste, front-loading the verb and the (slightly surprising) data-destruction caveat. Nothing to trim and nothing buried.

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 and no annotations, so the description is the only source of behavioral context, yet it says nothing about return values, failure modes, or device-precondition requirements. Combined with an undocumented required bundleId, it is adequate but clearly incomplete for a destructive two-parameter 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 coverage is only 50%: the 'device' parameter is richly documented in-schema, but 'bundleId' has no description and the tool description adds nothing about its expected format (e.g., 'com.example.app'). With a low coverage ratio the description should compensate for the undescribed required parameter, and it does not.

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?

A specific verb ('Uninstall') plus a precise resource ('an app') and target ('from the device'), which contrasts cleanly with the sibling install_app. The parenthetical 'and its data' adds useful scope info. It stops short of explicitly naming install_app as the inverse operation, so sibling differentiation is implied rather than stated.

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 stated when-to-use guidance, no prerequisites (is the app required to be installed? does the driver need to be running?), and no mention of alternatives or confirmation semantics. The purpose implies usage, but nothing in the text helps an agent decide when to prefer this over terminate_app or a reinstall flow.

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 and no output schema, the description carries full behavioral burden but only says it waits. It never states what happens on timeout (error vs. false), whether it polls or re-queries, or that it can scroll the UI to find lazy-loaded rows — the latter is only visible in the schema. The gone=true inversion is the one genuinely useful 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?

A single short sentence with the primary behavior front-loaded and the alternate mode parenthesized. Nothing is wasted or buried.

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 schema is rich enough to enumerate selectors, timeout and scroll options, but for a 10-parameter tool with no annotations and no output schema, the description should at least cover failure/timeout semantics and return behavior. As written, an agent cannot predict what a failed wait yields.

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 90%, so the schema already explains id, text, type, index, timeout, scrollDirection and maxScrolls. The description adds meaning only for the undocumented 'gone' flag and for 'exact' vs. text matching, so it sits just above baseline without materially enriching the parameter set.

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?

Specific verb and resource: 'Wait until an element appears (or disappears with gone=true).' An agent can immediately tell this is a polling/blocking lookup rather than a snapshot or an action like tap_element. It does not explicitly name a sibling alternative, so it stops short of 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?

Usage is only implied: the word 'Wait' signals this is for elements that may not be present yet, and gone=true covers the disappearance case. There is no statement of when to prefer this over describe_ui or tapping, and no note about preconditions such as a started driver or selected device.

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