iphone-control

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

No annotations are supplied, so the description has to carry the behavioral burden, and it does: it declares the 20-step cap, fail-fast semantics on the first error, reporting the failing step number, and the nested wait limit of 5 seconds. It does not state the return shape in detail — for example, whether the partial results of already-run steps are included or that side effects of earlier steps persist — which is a real gap for a sequence executor.

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 core contract — order, single call, 20-step cap, stop-on-error — is front-loaded in the first line, and the remaining lines each add a distinct rule. The tool list is long but necessary; nothing is pure repetition, though the `then` line is terse enough to be slightly ambiguous.

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 six-parameter orchestration tool with no annotations and no output schema, the description covers the step structure, tool whitelist, step and wait limits, and the side-return family. It leaves error-reporting granularity and whether prior steps' effects persist after a failure unstated, which would matter for a batch executor.

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 five top-level parameters (then, then_filter, then_region, then_settle, reuse_elements) are documented in the schema, so the baseline would be 3. The description earns more because the schema defines `steps` only as a generic object array, and the description supplies the actual item shape {"tool": …} along with the full set of allowed tool names and a note that `then` matches the other action tools.

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 gives a specific verb and resource: it runs several operations in sequence in a single call, with a hard cap of 20 steps, and halts on the first error. It also lists the exact sub-tools it accepts, which cleanly distinguishes it from the individual sibling tools such as iphone_tap and iphone_swipe.

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 states the condition for use ("适合确定的连续操作" — deterministic consecutive operations) and the condition to avoid it ("每步的结果不确定…时,还是一步步来" — when the result of each step is unknown). That covers both directions explicitly and points to the stepwise alternative without leaving the agent to infer 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 disclosure burden. It reveals one genuinely useful trait, that `app` accepts either a Bundle ID or a display name, but says nothing about behavior if the app is not installed, whether an already-running instance is reused versus cold-launched, what permissions or device state are required, or what the default call returns.

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, front-loaded with the core action, with no redundant wording. The identifier-format detail is placed immediately after the action, which is the right position for it.

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 the description does not explain what a plain call with the default `then=none` returns. For a 5-parameter tool with conditional side-effect behaviors, that leaves an important gap, although the schema itself documents the optional follow-up parameters thoroughly.

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 80%, so the baseline is 3, and the description adds real meaning for the one undocumented parameter: `app` accepts either a Bundle ID or a display name such as 「设置」 or 「微信」. The `then`-family parameters are already well documented in the schema, so no repetition is needed.

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: "启动 App 并切到前台" (launch app and bring it to foreground). It also clarifies the accepted identifier forms for `app`, which lets an agent tell it apart from siblings like iphone_terminate_app or iphone_open_url. It stops short of naming an alternative tool explicitly, so no sibling differentiation is spelled out.

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 use case (start an app and put it in the foreground) is self-evident from the verb, and the schema's `then` parameter documentation describes the follow-up behaviors. However, there is no explicit statement of when to prefer this over iphone_open_url or iphone_batch, and no prerequisites such as the device being unlocked or the app being 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 supplied, so the description carries the full burden. It does disclose the return shape (name + Bundle ID) and the effect of include_system=True, but it says nothing about whether the call is read-only, how long it takes, whether pagination or a result cap applies, or what an empty result means.

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 core purpose front-loaded and the parameter note following. Nothing could be removed without losing 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?

For a single-optional-parameter read tool with no output schema, this covers what it does, what it returns, and the one flag's behavior. Missing only a note on result volume or ordering, which is minor at this complexity.

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 0% — the boolean parameter has no description in the schema — so the sentence 'include_system=True 时列出系统 App' is the only source of meaning. It successfully explains the flag and, by implication, that the default excludes system apps, though it does not spell out that default explicitly.

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 ('列出已安装的 App') and names the returned fields (名字和 Bundle ID), so an agent can tell it apart from action siblings like iphone_launch_app or iphone_list_elements. It never explicitly contrasts itself with those siblings, which keeps it from 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: an agent infers it should call this before iphone_launch_app to discover Bundle IDs. There is no explicit 'use this when...' statement, no mention of when to prefer iphone_list_elements, and no prerequisite notes.

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 supplied, the description carries the full behavioral burden and does so well: it discloses that only text-bearing elements are listed, that on-screen decisions are coordinate-based, and that elements hidden behind dialogs can still appear — a genuine trap the agent is warned about. It says nothing about result ordering or what happens when more than `limit` elements match, which is the remaining behavioral 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?

Three sentences, each with a distinct job: what it returns, how filtering works, and a correctness caveat. Front-loaded and free of filler, though the filter sentence chains several ideas with slashes and parentheses and could be split for faster scanning.

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 read tool with no output schema and no annotations, the definition covers the important ground: return shape, filter semantics, and the occlusion pitfall. The undocumented `limit` parameter is the one thing an agent could get wrong — it cannot tell whether a missing element means 'not on screen' or 'truncated at 150'.

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 0%, so the description must compensate for both parameters. It documents `filter` thoroughly — which fields are matched, case-insensitivity, and sample values — but `limit` is never mentioned at all, leaving its default of 150 and its effect on truncation unexplained.

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 opening clause states a specific verb and resource ('列出屏幕上带文字的界面元素') and enumerates the four fields returned (类型、标签、中心点坐标、尺寸), so an agent knows exactly what comes back without an output schema. It also implicitly distinguishes itself from iphone_screenshot by dealing in element metadata rather than pixels, though it never names the sibling explicitly.

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

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

The filter line gives a concrete use case with real examples (SearchField, Button), and the closing note routes the agent to the screenshot tool when element geometry looks unreliable. It stops short of stating when not to use this tool (e.g. when waiting for a state change, which belongs to iphone_wait_for).

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?

由于没有提供任何注解，描述必须承载全部行为披露负担，但它只说明了动作。它没有提到长按持续多久，也没有说明长按会触发什么（上下文菜单、拖拽开始等），并且没有说明重复长按同一位置会有什么影响。

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?

整个描述是一句话，没有冗余措辞，但它过于简短，而不是精确；其简洁是以遗漏而不是以效率实现的。

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?

一个接受 7 个参数、没有注解也没有输出 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 的描述覆盖率约为 86%，因此 then、then_filter、then_region 和 then_settle 已经由 schema 本身充分说明。描述没有为其中任何参数补充含义，因此在 schema 承担主要说明工作时，按基线 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?

该描述明确给出了具体动作和资源——在屏幕坐标处执行“长按”——并且“长按”这一措辞将其与 iphone_tap 区分开。它没有明确提到任何同级工具，但动作本身在语义上已经清楚。

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?

描述中没有说明何时应使用长按而不是 iphone_tap 或 iphone_swipe，也没有说明前提条件（例如是否要求前台有 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 are provided, so the description carries the full burden. It usefully discloses that the system default handler is used and that web pages land in Safari, but says nothing about failure behavior, whether the calling app is backgrounded, or whether the device must be unlocked.

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 filler, and the Safari behavior is placed immediately after the core action. It is efficient but so terse that it omits information the agent needs.

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 5-parameter tool with no output schema and no annotations, the description still gives the key mental model: system-handled URL open with web content in Safari, and the schema covers the optional follow-up capture options. Only the url format contract and failure mode are 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 80%, so the schema largely documents the optional then/then_region/then_filter/then_settle chain. The description adds no meaning to the required url parameter, such as accepted formats (https:// vs shortcuts:// vs custom schemes), which is the one thing an agent could get wrong 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 (打开/open) and resource (链接或 URL Scheme) plus the concrete effect that web pages open in Safari. It does not explicitly distinguish itself from sibling iphone_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 implied by naming URL/URL-Scheme as the input, which separates it loosely from app-launching siblings. There is no explicit when-to-use or when-not-to-use statement and no naming of the alternative tool (iphone_launch_app) for non-URL intents.

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 deliver one genuinely non-obvious behavior: when a passcode is set, operations after lock auto-unlock. It omits other relevant traits — that home backgrounds the running app, that volume presses are silent/side-effecting, and it never mentions the `then` post-action chaining that is the tool's main efficiency feature.

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 compact sentence with the key list front-loaded and no filler; the parentheticals earn their place by explaining each button. It is arguably too terse given the omitted `then` chaining, but there is no wasted wording.

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 5-parameter, no-annotation, no-output-schema tool, the description covers the core action and one important side effect, but says nothing about what comes back when `then` is used, nor about how the key press affects the foreground app. Adequate minimum viable, not 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 already 80%, but the description still adds meaning for the required `button` values (home = 回主屏幕, lock = 锁屏 + auto-unlock consequence) rather than just restating the enum. The optional then/then_filter/then_region/then_settle parameters are 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+resource (按硬件键 / press a hardware button) and enumerates the four allowed keys, which cleanly distinguishes it from touch siblings like iphone_tap, iphone_long_press and iphone_swipe. It does not explicitly say 'this is not a screen tap', but the hardware-key framing 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?

Usage is only implied by parenthetical glosses: home is for returning to the home screen, lock is for locking. There is no explicit when-to-use/when-not guidance (e.g. use lock before iphone_launch_app, or prefer iphone_terminate_app over home for killing an app), so the agent must infer 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 carries the full burden and does well: it discloses that the image is scaled to point size, that pixel coordinates map directly to tap/swipe, that zoom crops from the original high-res capture, and that the magnification factor is returned in text. It omits any note on latency or capture side effects, but for a read-only screenshot the disclosure is substantial.

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?

Front-loaded with the core action, then the zoom guidance, then the coordinate-conversion formula. Dense but every sentence carries operational value; the coordinate math could be slightly tighter but 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?

There is no output schema, so the description correctly explains the return value (magnification factor in the text) and how to interpret it. Combined with the coordinate-mapping rule, an agent has enough to call and use the tool correctly; only edge cases like capture failure are unaddressed.

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 meaning: the four params are in points, they define a zoom region, and the returned magnification must be used to convert image coordinates back to screen points (x + pixel/magnification). That conversion rule is not in the schema and is essential for correct use.

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 opens with a specific verb+resource ("截取当前屏幕" / capture the current screen) and immediately clarifies the coordinate semantics. It is the only screenshot tool among the siblings, so no explicit disambiguation is needed, and an agent can tell exactly what it produces.

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 gives a clear conditional for the optional region parameters: use x/y/width/height when small icons or text are hard to see. It does not discuss when to prefer this over iphone_list_elements or other inspection siblings, so it stops short of full alternative routing.

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 supplied, the description carries the full burden, and it does disclose the important behavior: this is a pure read ('查看') with no side effects, and it enumerates the exact data points returned. It does not describe the response format or any latency/failure modes (e.g. what happens if WDA is not connected), which keeps it short of 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?

A single sentence with the core purpose front-loaded and the return fields listed after a colon. No filler, no 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?

There is no output schema, so the description must document the return values itself, and it does so by naming all four status fields. What is missing is the shape/format of the response and how an unready or locked device is reported, which an agent would need to act on the result.

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 there is no parameter semantics to explain; the baseline for a parameterless tool is 4. Nothing in the description misleads about inputs.

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 gives a specific verb+resource ('查看连接状态' – view connection status) and enumerates exactly what status is reported: WDA readiness, lock state, foreground app, and screen size. This clearly distinguishes it from the action siblings (iphone_tap, iphone_swipe, iphone_screenshot) without needing to name them, though it does not explicitly call out that 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?

No explicit statement of when to call this versus alternatives, but the content makes the intended use obvious: it is the pre-flight/health-check tool an agent calls before driving the device. Usage is implied rather than stated, so it lands at minimum-viable.

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 does little: it never says whether the swipe is instant or flings with inertia, what coordinate space the points live in (screen points vs pixels), or that the swipe acts on whatever is currently on screen. The 'then'-chaining behavior is only disclosed in the schema, not the description.

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 with the core action first and the directional tip second; nothing is wasted. It is terse to the point of being sparse, but every sentence 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 9-parameter gesture tool with conditional follow-up behavior and no annotations or output schema, the description covers the action and one scrolling recipe but omits gesture dynamics, coordinate frame, and screen-state assumptions. The schema fills in the 'then*' parameters, which keeps this from being inadequate.

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 44% and the four coordinate parameters have empty schema descriptions, so the description's note that from_y > to_y means swiping up adds real meaning beyond the schema. However it leaves seconds (gesture duration) and the x-axis untouched, so it only partially compensates 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: swipe from one point to another, with point coordinates. It is clearly distinguishable from siblings like iphone_tap and iphone_long_press by the gesture type, though it never names those siblings 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?

It gives one concrete usage recipe (to scroll down, make from_y large and to_y small), which is genuinely helpful directional guidance. It offers no when-not guidance, no prerequisites (app must be foreground?), and no comparison to alternative gestures such as tap or press_button.

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 supplied, so the description carries the full burden, and it discloses almost nothing: it does not say whether the tap waits for the UI to settle, what happens on out-of-bounds coordinates, or that extra data can be returned in the same call. The only behavioral hints (settle timing, chained element/screenshot returns) live in the schema, not the description.

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?

It is a single front-loaded clause with zero waste, but for a 6-parameter tool with chained post-action returns it is undersized rather than tight. Brevity here costs information rather than saving it.

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, no output schema, and six parameters including a non-trivial chained-return mechanism, the description should explain the settle-and-return behavior and the coordinate-space assumption. It leaves an agent unable to predict that a tap can also yield elements or a screenshot.

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 x, y, then, then_filter, then_region and then_settle in detail. The description adds nothing beyond repeating the point unit already present in the schema, so baseline 3 applies.

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: tapping screen coordinates in points. It implicitly distinguishes itself from the coordinate-based siblings (iphone_tap_element, iphone_swipe) by naming coordinates as the target, though it never names an alternative 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?

There is no when-to-use guidance at all: nothing says to prefer iphone_tap_element when a selector is available, or when coordinate tapping is the right fallback. The agent must infer the routing decision 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?

With no annotations supplied, the description carries the full burden and does disclose non-obvious runtime behavior: match resolution order, hit-point adjustment when the element center is covered by a floating bar or keyboard, and the safe decision not to tap at all when fully occluded. It does not state what happens on zero matches (error vs. silent no-op) or whether success is confirmed, which keeps it below 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?

The behavioral rules are front-loaded and dense with no filler; the index note is correctly split into its own line. It is compact for the amount of decision-relevant content it carries, with only minor terseness (no explicit no-match outcome) as the cost.

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?

Six parameters with no output schema and no annotations demand a lot, and the description covers the two parameters the schema leaves undocumented plus the occlusion/matching edge cases that most often cause wrong taps. The main residual gap is failure semantics on no match, which matters for an agent deciding whether to retry or fall back to iphone_tap.

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%, and the description genuinely adds meaning for the unlabeled `text` parameter (matching semantics) and for `index` (0-based, ordering consistent with iphone_list_elements), which the schema leaves bare. The remaining then_* parameters are documented in the schema itself, so the description neither repeats nor extends them. Baseline 3 fits given the split 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 first line names a specific verb+resource: tap an element by matching its text, with an exact-match-then-substring-match resolution order. That is far more precise than the bare name. It stops short of a 5 because it never contrasts itself with sibling iphone_tap (coordinate tap) or says which to prefer when a label is unknown.

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 matching priority (exact label/name first, then substring) plus the occlusion rule (tap an uncovered sub-region, skip entirely if fully covered) tells the agent how the tool behaves in edge cases, which implicitly guides use. However, there is no explicit when-to-use/when-not guidance against iphone_tap, iphone_list_elements, or iphone_long_press, so the agent must infer routing.

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 conveys that the process is ended (a destructive action) but gives no detail on what happens if the app isn't running, whether it is a hard kill or background, or any side effects on app state or user data.

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 then the key parameter detail; no wasted wording.

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 five-parameter tool with no annotations, no output schema, and a significant 'then' chaining feature (returning elements/screenshot to save a call), the description is too thin. The core purpose is covered but the post-action chaining behavior and preconditions are left undocumented.

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 description adds genuine meaning for the 'app' parameter (Bundle ID vs display name), which the schema leaves as a bare string. However, it says nothing about the four 'then*' chaining parameters, so it only partially compensates and relies on the 80% schema coverage for the rest.

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: ending an app process, and clarifies the app parameter accepts either a Bundle ID or display name. It is clearly distinguishable from iphone_launch_app, though it doesn't explicitly name the 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?

Usage is implied by the name and verb (terminate a running app), but there is no explicit when-to-use guidance, no mention of iphone_launch_app as the complementary tool, and no preconditions such as the app needing 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?

With no annotations, the description carries the full burden, and it does: it discloses read-back verification, automatic padding of a few missing trailing characters, and an error mode where a mismatch aborts the Enter press. These are non-obvious mutation semantics that an agent could not infer from 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?

Three short clauses, front-loaded with the target and prerequisite, then the submit behavior, then the verification/error contract. No filler and 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 six-parameter mutation tool with no annotations and no output schema, the description covers the essential call contract and failure mode. It leaves unstated what happens when no field is focused, which an agent would need to know to recover from a failed 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 coverage is 67%, and the description adds meaning to the undocumented `submit` parameter by tying it to pressing Enter and to the verification behavior. It does not elaborate on `then`, `then_filter`, `then_region`, or `then_settle`, but those already have schema descriptions, so the remaining gap is small.

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 ('在当前获得焦点的输入框里输入文字') plus a critical scope constraint: the target must already be focused, so this tool does not tap. That distinguishes it cleanly from iphone_tap and iphone_tap_element without needing to name 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?

It gives an explicit prerequisite ('需要先点中输入框'), which tells the agent to call a tap tool first, and it gives the condition that triggers submission (submit=True, 末尾按回车). The guidance is actionable even though no sibling is named 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?

With no annotations, the description carries the full burden and does well: it discloses the return-on-match behavior, the timeout-error failure mode, and a non-obvious matching exclusion (text inside input fields is ignored). It omits what a successful match returns (the element, its identifier, a boolean) and whether the timeout failure is an exception versus a status value.

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 clause states the action, followed by parenthetical examples, then the return/timeout contract and the exclusion. No filler sentences; every clause (examples, immediate-return, timeout error, sibling replacement, input-field exclusion) carries distinct 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?

For a blocking-wait tool with no annotations and no output schema, the description should state what comes back on a successful match, since structured fields cannot. It covers timing, failure mode, and matching rules, but the return contract is left implicit ('出现就立即返回' — returns, but what?).

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% — only `timeout` is documented ('最多等几秒(不超过 30)'). The description compensates for the undocumented `text` parameter by defining it as a substring match against element text and excluding input-field content, which is meaningful added semantics. Baseline 3 for the schema gap balanced against that contribution.

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: wait for a UI element containing given text to appear, returning as soon as it does and erroring on timeout. The scope note ('input field text doesn't count') sharpens the target of the wait, and 'replaces repeated screenshot polling' distinguishes it from the iphone_screenshot/iphone_list_elements siblings without naming them 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?

Gives concrete triggers ('page loaded', 'popup appeared') and an explicit alternative it supersedes ('代替反复截图轮询'), which routes the agent away from a screenshot-poll loop. It does not say when NOT to use it (e.g. for elements with no visible text, where iphone_list_elements would be the fallback), so it stops short of full when/when-not coverage.

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