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

With no annotations, the description carries the full burden; it does disclose a display precondition and an empirically failing method, which is genuinely useful behavioral context. It omits what happens when there is no back history, whether it blocks until the page transition completes, and how it interacts with the timing parameters.

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: the primary action and its precondition come first, then the method caveat. The parenthetical recovery steps are actionable rather than 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 six-parameter, annotation-free navigation tool with no output schema, the description covers the critical precondition and one method caveat but leaves the whole timing/settling family (ms, timeout, stable_for, wait_change) undocumented, forcing the agent to guess defaults and blocking behavior.

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

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

Schema description coverage is 17% — only 'settle' is documented in the schema. The description adds real meaning for one parameter by explaining that method=swipe uses the left-edge gesture and did not navigate in testing, but ms, timeout, stable_for, and wait_change remain unexplained in both schema and description.

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

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

States a specific verb and target (taps the toolbar back arrow in Safari), so the agent knows exactly which control is actuated. It implicitly separates itself from generic tap/swipe siblings, but never names them, so the differentiation is inferred rather than explicit.

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 a concrete precondition (toolbar must be showing) and two recovery actions (scroll up a little, or tap the bottom bar first). It also warns that the swipe alternative did not navigate in testing, effectively steering the agent to method=button. No other sibling alternatives are named.

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

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

No annotations are provided, so the description must carry behavioral disclosure, but it omits important context such as read-only behavior, whether clear deletes messages, how limit truncates results, and what wait affects. It does disclose the temporal scope 'since the inspector attached,' which is useful but insufficient for a tool with a clear parameter.

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 compact sentence with no wasted words and the resource plus scope are front-loaded. The parenthetical return fields are concise and useful.

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

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

For a four-parameter tool with no annotations and no output schema, the description is too thin. It mentions return fields but omits the meaning of clear, limit, wait behavior, and any pagination or volume constraints.

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%, with page and wait documented but clear and limit undocumented. The description does not compensate by explaining any parameter semantics; its parenthetical '(level, text, url)' describes return fields rather than input parameters.

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 identifies the specific resource (console messages), the temporal scope (since the inspector attached), and the returned fields (level, text, url). It is clearly distinct from network-oriented siblings, though it does not explicitly contrast with tools like log_tail or inspector_raw.

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 no explicit guidance on when to use this tool versus siblings such as log_tail, network_log, or inspector_raw. The only implied usage is retrieving page console output, leaving alternatives and exclusions unstated.

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. 'Query' implies read-only and the description usefully enumerates the info payload (tag, text, attributes, rect in CSS px, visible) and that html returns outerHTML, which is real behavioral context. However, it says nothing about whether it returns the first match or all matches, selector-miss behavior, or how page/wait affect execution.

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 dense sentences, front-loaded with the verb and resource, followed by the mode enumeration. No filler, though the parenthetical mode list is slightly run-on and could be more scannable.

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 five parameters, zero required, no annotations, and no output schema, the description should explain result shape and matching semantics. It partially does for info/html/text, but leaves limit, multi-match behavior, and empty-result behavior entirely unaddressed—gaps an agent will hit on first 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 40%: page and wait are documented in the schema, the what enum is listed but the description adds genuine meaning for each mode and its default fields. selector is only implied by 'by CSS selector,' and limit is completely undocumented in both schema and description, leaving its meaning (match cap? byte cap?) unresolvable.

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: 'Query the DOM by CSS selector.' An agent knows this reads page markup, not that it runs arbitrary script (js) or dumps raw inspector data (inspector_raw). It stops short of naming or contrasting those overlapping 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?

No when-to-use or when-not guidance, and no routing among the many overlapping siblings (js, inspector_raw, tap_css, tap_element). Usage is only implied by the phrase 'by CSS selector'; an agent must infer that this is the read-only DOM inspection path.

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 synthetic event mechanism, notes that it is fast but not equivalent to real typing, and lists missing behaviors (key events, keyboard, autocorrect, composition). It does not cover failure behavior, focus requirements, or what happens with disabled/readonly fields, so it is not fully exhaustive.

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 zero waste. The core behavior and the key limitation are front-loaded, and the alternative tools are named immediately after the caveat.

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 field-fill operation with rich schema coverage, the description covers what the tool does and how it differs from typing tools. Minor behavioral gaps such as focus requirements or error handling are not addressed, but the essential selection 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 high at 83%, so the schema already explains selector, value, page, wait, index, and change. The description adds no parameter-specific details beyond what the structured schema provides, making the baseline 3 appropriate.

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

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

States a specific action (set the value of a field) and the exact mechanism used (native setter followed by input and change events). It also distinguishes itself from the typing siblings by naming keyboard_show and type_text, so an agent can choose correctly without opening another 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 says when to use this tool: when the goal is to set a field so the framework notices, and speed matters. It also says when not to use it, because it lacks key events, keyboard interactions, autocorrect, and composition, and names keyboard_show and type_text as the alternatives.

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 full behavioral burden; it does disclose the return payload (pid, thread count), which is genuinely useful. It does not state the negative result (empty result vs. error when the process is absent), whether the call is read-only, or what the `timeout` does before giving up.

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 question and followed by the return shape. Every clause earns its place; the process-name examples directly reduce caller ambiguity.

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-style probe with no output schema, the description covers identity, examples, and the returned fields. The remaining gap is failure/timeout semantics, which matters for a tool that can plausibly be used as a polling primitive.

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 explain both parameters. It adds real value for `name` via concrete examples, but says nothing about `timeout` — its units, default, or whether it polls until the process appears.

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 check ("Is a process running") on a specific resource (a named process in the guest) and adds return content (pid and thread count). No sibling in the list performs process inspection, so no differentiation is needed, but the description does not explicitly say so.

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 question form and the example process names (MobileSafari, wi_relay), which show the expected lookup style. There is no explicit statement of when to call this versus e.g. `settle` or `wait_for`, and no prerequisites such as needing an attached/started guest.

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 and delivers essentially nothing. It does not say whether the call blocks, how long the hold lasts by default, what ms/settle/timeout/stable_for/wait_change do or default to, or what it returns — all critical for a timing-sensitive gesture in an automation loop.

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?

Four words with no waste, but the brevity here is under-specification, not conciseness. There is no front-loaded purpose statement covering target, duration, or blocking behavior, so nothing useful is established before the reader runs out of 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?

A 7-parameter timing-sensitive gesture with no annotations and no output schema needs a description to explain duration control, settling semantics, and return behavior. The description covers none of it, leaving the four most cryptic parameters completely opaque.

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 43%, and the description explains zero parameters. Four parameters (ms, timeout, stable_for, wait_change) have no schema description and no description text, so an agent cannot tell from either source how to control hold duration or post-gesture settling; only 'settle' and the 0–1 bounds on x/y are documented 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?

"Touch and hold" names a recognizable touchscreen long-press gesture, which does distinguish it from tap/swipe in the sibling list. But it only restates the tool name with one added word and says nothing about the target (normalized x/y coordinates) or the duration, so the purpose stays at the level of a gesture label.

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 when-to-use guidance at all: nothing about choosing hold over tap, swipe, tap_px, or wait_for, and no mention of whether it is for long-press menus versus steady contact. The agent must infer the selection rule purely from the one-word 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?

No annotations exist, so the description carries the full burden, and it discloses only the physical gesture. It says nothing about platform constraints, whether this backgrounds the app or kills it, what happens if the gesture is unsupported, or the meaning of the four synchronization parameters that govern when the tool 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?

A single short sentence with the effect front-loaded before the mechanism. It wastes no words, though the colon-and-imperative phrasing reads as end-user instruction rather than tool documentation.

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 four parameters, no annotations, and no output schema, this description is far too thin: it omits the return/settle behavior implied by the parameters and says nothing about platform applicability or post-gesture state, leaving the agent unable to call it reliably.

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 25% — `settle`, `timeout`, `stable_for`, and `wait_change` are all undocumented except a one-liner on `settle`. The description adds no semantics for any of these wait/settle controls, so an agent cannot tell how to tune them or what default behavior to expect.

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

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

The description states the effect ("Leave the app") and the gesture that produces it ("swipe up from the bottom edge"), which resolves the ambiguity of the name "home_screen" for an agent that might otherwise expect a screen-read operation. However, it is phrased as an imperative instruction to a human rather than as a tool capability, and it never distinguishes itself from siblings like `swipe` or `back` that could achieve a similar outcome.

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 call this versus `back`, `swipe`, or `tap`, and no conditions under which it should not be used (e.g. app without a home gesture, Android vs iOS). The agent must infer usage entirely from the one-line effect description.

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 two most important behavioral facts: closing terminates the connection, and the next inspector call reconnects automatically. It does not say whether any browser/page state is lost or what happens if no connection is open, leaving a small 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?

Two short sentences, the primary effect front-loaded and the follow-on consequence second. Every clause carries information; 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?

For a zero-parameter, no-output-schema lifecycle tool, the description covers what it does, the exclusivity constraint that motivates it, and the reconnect behavior that follows. An agent has enough to call it correctly without further context.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-like inputs are mentioned, which is consistent with the empty 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 ("End the inspector connection") rather than restating the name, and adds the scoping rule "a page takes one frontend at a time." It is clearly distinguishable from inspection siblings like inspector_pages or inspector_raw, though it never names an alternative tool to contrast with.

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 "the next inspector call reconnects" implies the operation is reversible and safe to invoke whenever the frontend slot should be released, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. Usage is inferable rather than 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: it discloses the runtime prerequisite and the return shape (title, url), implying a safe read. It says nothing about what happens when no pages are available, whether the call blocks, or how the `wait` parameter affects timing.

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 return fields, then the prerequisite. No padding, though the second sentence could be slightly tighter.

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 naming the returned fields is valuable, and the prerequisite is covered. Missing is any handling of the undocumented `wait` parameter or what an empty page list looks like, so it is only adequately complete for a 2-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%: `all` is documented in the schema, but `wait` is undocumented in both schema and description, and the description adds no meaning to either parameter. It does not 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?

States a specific verb and resource ("List the pages that Safari offers to the Web Inspector") and names the returned fields, which separates it from inspector_raw. It does not explicitly contrast with that sibling, so it falls 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?

The description gives a prerequisite ("Safari must be running with a page open") and points to safari_ready as the way to satisfy it, which is useful routing. However, it never says when to use this versus inspector_raw or the other inspector tools, and gives no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the result is returned, but does not disclose that raw protocol commands may mutate page state, require specific permissions, or have destructive/irreversible effects. A raw escape hatch needs stronger safety and side-effect context.

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

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

The description is a single front-loaded sentence with zero waste. It immediately communicates the core action and gives useful examples.

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 only 40% schema description coverage across five parameters, the description is too thin. It does not explain parameter expectations, side effects, or return shape enough for an agent to invoke arbitrary protocol commands safely and correctly.

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

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

Schema coverage is only 40%, and the description adds meaning only for the method parameter via examples. It does not explain the params object shape, timeout semantics, or how method and params interact, leaving most parameters undocumented in both schema and description.

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

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

The description states a specific verb and resource: send any Web Inspector protocol command to the page and return the result. The examples (Page.getCookies, DOM.getDocument, Debugger.enable) make the scope concrete, though it does not explicitly distinguish itself from sibling tools like js or dom.

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 raw command tool versus higher-level siblings such as js, dom, or inspector_pages. The only implied usage is that it accepts arbitrary protocol commands, with no exclusions or prerequisites 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 behavioral burden. It discloses that the expression runs in the page and returns JSON, but does not state whether arbitrary JS can mutate or break the page, whether promises are awaited by default, or what permissions or side effects apply.

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 short and front-loads the core action. The second sentence is terse and somewhat cryptic, but it avoids waste.

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?

This is a powerful arbitrary-JS-execution tool with no annotations, no output schema, and four parameters. The description is too sparse to cover key risks and behaviors such as mutation side effects, promise handling, page targeting, and wait semantics.

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 explains 'expression' as a JavaScript expression and loosely references the page context. However, with only 50% schema description coverage, it does not clarify the 'wait' or 'await_promise' parameters, and 'await_promise' has no schema description at all.

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: run a JavaScript expression in the page and return its value as JSON. It partially distinguishes itself from sibling tools by noting 'no screenshot or typing,' but it does not clarify its relationship to tools like dom or inspector_raw.

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 phrase 'no screenshot or typing' hints that this tool is not for visual capture or text entry, implying its use for direct JS evaluation. However, it names no alternatives and gives no explicit when-to-use or when-not-to-use guidance against the many sibling browser tools.

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

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

No annotations are provided, so the description must carry the behavioral burden. It states the action but does not disclose blocking behavior, timeout semantics, what "settle" or "wait_change" do, whether the call is synchronous, or what happens on 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?

A single front-loaded sentence with no wasted prose. The button enumeration duplicates the schema enum but is compact and harmless.

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 input tool with no annotations and no output schema, the description is far too sparse. It omits timing/blocking behavior, undocumented parameter meanings, and guidance relative to input siblings such as tap and back.

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 17%; only "settle" is documented in the schema. The description repeats the enum values from the schema but does not explain the five undocumented parameters (ms, timeout, stable_for, wait_change), which are critical for timing-sensitive input.

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 ("Press") and resource ("hardware button") and enumerates the valid button names, making the action clear. It does not explicitly differentiate from siblings like tap or back, but the hardware-button framing is reasonably distinctive.

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?

Provides no guidance on when to use this tool versus tap, back, home_screen, or other input siblings. There are no prerequisites, exclusions, or contextual hints about appropriate scenarios.

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

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

With no annotations, the description carries the burden and mostly does: it discloses the full side-effect sequence (opens keyboard, optionally fills value, waits, screenshots, then closes the keyboard by default and re-checks viewport recovery). That is real behavioral context an agent needs. It stops short of saying whether focus/tap is required to open the keyboard or what happens on failure/timeout.

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?

Content is front-loaded — what it does, what it reports, then what it returns and how it cleans up. Dense but nearly every clause carries information; only the run-on construction around the return/cleanup step costs it a point.

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 7-parameter, no-annotation, no-output-schema tool, the description covers the sequence, the return artifacts (report plus screenshot) and the default cleanup. What is missing is the meaning of 'index', error/timeout behavior, and the report's shape — enough to keep it from a 5.

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 86%, so the schema already documents hide, page, wait, value, selector and settle_s; the description only reinforces 'value' (fills the field to trigger suggestions) and 'selector' (the field). The 'index' parameter has no description in either the schema or the description, leaving a real 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 names a specific verb and resource (open the keyboard on a field) and a specific outcome (report occlusion of the field, fixed bars, suggestion popups). It is clearly not a plain show/hide/state tool, distinguishing it from siblings keyboard_show, keyboard_hide and keyboard_state, which only manipulate or read keyboard state without an occlusion report.

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 rather than stated: the mention of 'suggestion popups' and 'optionally puts a value in the field first, to bring up suggestions' tells the agent this is the tool for keyboard-occlusion audits, and the 'hide' behavior hints at the after-state check. But there is no explicit when-to-use or when-not against keyboard_state / keyboard_show / screenshot, and no prerequisites (e.g. that a page must be loaded) 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 burden and does well: it discloses that recording must be installed via action=start, that a navigation destroys the recorder, and that read returns accumulated events with a skip offset. It omits permission/auth needs and any buffering limits, but the key lifecycle gotcha is stated.

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, front-loaded with what is recorded, then the action semantics. The event-type list is long but each term adds precision rather than 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 5-parameter tool with no output schema and no annotations, the description gives the shape of returned events ("with the viewport numbers at that moment") but leaves clear, page, and wait unexplained and provides no guidance on event volume or return format. Adequate but with clear gaps.

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

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

Schema coverage is only 40%, and the description compensates for two parameters: action values and since ("how many to skip"). It says nothing about page, wait, or clear — clear is completely undocumented in both schema and description, leaving a notable gap for a destructive-sounding 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 (record) and a concrete resource (keyboard/focus/input/composition/resize/scroll events), enumerating exactly what is captured. It is distinguishable from siblings like console_messages or network_log, though it doesn't explicitly 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?

The description explains the lifecycle of the three actions (start installs, read returns with since-skip, stop removes), which implies usage, and warns a navigation removes the recorder. However, it never says when to choose this over keyboard_state, keyboard_check, or console_messages, so the agent must infer fit.

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 burden well: it discloses that the call waits for viewport recovery, that method=return may submit a form (a real side effect), and that tap_outside targets CSS pixel coordinates defaulting to the left edge. It omits failure behavior (e.g. what happens if no keyboard is open) and the response shape.

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 purpose sentence is front-loaded and the method glossary follows in priority order. The method enumeration is a long run-on that could be bulleted, but every clause carries 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 six-parameter, annotation-free tool with no output schema, the description covers the decision-relevant surface (method semantics, coordinates, waiting). Gaps around timeout, page/wait behavior, and error/return semantics keep it from being fully self-sufficient.

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 33%, and the description compensates by defining all four `method` enum values with distinct semantics and by specifying the units and default for x/y. It leaves `timeout` wholly unexplained, and page/wait are only covered by the schema itself.

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 ("Close the keyboard") plus the scope of the operation ("wait for the viewport to recover"), and the method enumeration immediately makes it distinguishable from siblings like keyboard_show and keyboard_state.

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?

Explains the choice among the four methods with real user-facing semantics (blur = page-level, done = Safari's Done button, return = keyboard key that may submit a form, tap_outside = a page coordinate). It does not say when this tool is preferable to alternatives such as waiting via `wait` or checking via keyboard_state first, so it stops short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden, and it does so well: it discloses the concrete side effects (scrolls the field into view, computes its screen position, performs a real tap) and the synchronous completion condition (waits until the visual viewport shrinks). It leaves out what happens on timeout failure or whether the tap requires the page to be 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?

Two dense sentences, front-loaded with the purpose and the non-obvious iOS rationale, followed by the mechanism and return. No filler sentences.

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?

Covers mechanism, side effects, and the wait condition for a six-parameter tool, which is nearly everything an agent needs. The residual gap is that 'returns the state' is not defined (presumably the keyboard_state shape) and failure/timeout behavior is unstated, and there is no output schema to fall back on.

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 all six parameters are already documented in the schema, setting the baseline at 3. The description only loosely implies the scroll and timeout parameters through its prose ('scrolls the field into view', 'waits until the visual viewport has shrunk') without adding format or default detail 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 ('Open the keyboard on a field') and immediately distinguishes itself from scripted alternatives by explaining that calling focus() does not work on iOS. An agent can tell this apart from siblings like tap_css, fill, or js without opening any 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?

Makes the operative context clear: use this when the keyboard must actually be up and JS focus() is insufficient (explicitly iOS). It does not, however, name sibling alternatives such as keyboard_state for read-only checks or keyboard_hide for dismissal, so the routing is good but not exhaustive.

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 burden and does well: the interrogative 'Returns...' framing makes clear this is a passive read with no side effects, and it discloses the exact payload (viewport, focused field visibility, overlapping elements, fixed/sticky bars) plus units in CSS px. It does not explicitly state that it is non-mutating or how long a read takes, 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?

The core question is front-loaded in the first sentence and the return payload follows. The second sentence is a long enumeration, but since there is no output schema, each listed field earns its place; only minor trimming would improve 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?

For a zero-required-parameter read with no output schema and no annotations, the description supplies everything an agent needs: what it reports, the shape of the return, the meaning of behindKeyboard, and the unit (CSS px). Parameter details are fully covered by the 100%-covered schema.

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

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

Schema description coverage is 100% and both parameters (page, wait) are documented in the schema, so the baseline of 3 applies. The description adds no additional meaning about the page index or the wait timeout, relying entirely on the schema for parameter behavior.

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 frames a specific query resource (keyboard up/tall/coverage) and enumerates exactly what is returned: layout and visual viewport, focused field visibility, interactive elements and popups under the keyboard, and fixed/sticky elements with a behindKeyboard flag. It is clearly a read/state inspection tool, but it never distinguishes itself from the nearby keyboard_check and keyboard_events siblings, leaving an agent to 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 question-style phrasing ('Is the keyboard up, how tall is it, and what does it cover?') strongly implies the use case: diagnosing keyboard occlusion and layout. However, there is no explicit when-to-use, when-not-to-use, or routing statement against keyboard_check, keyboard_events, or keyboard_show/hide, so the guidance is only implied.

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, yet it says nothing about the default number of lines returned, whether the log is read-only or cleared, or how the guest must be in a running state for this to work. Only the read-like framing ('Last lines of...') implicitly signals a non-mutating retrieval, which is thin coverage for an unannotated 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?

A single front-loaded sentence with no filler, which is appropriate for a simple tool. The nominal phrasing ('Last lines of...') is slightly less crisp than a verb-first construction but costs little.

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

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

There is no output schema, so the description should indicate what the returned log tail looks like (raw text vs. structured entries) and its default size, but it does not. For a log-inspection tool with zero annotation and zero output-schema support, these omissions leave real ambiguity about what the agent gets back.

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 explain both parameters. It only hints at the purpose of 'pattern' (regex filtering) and never states its regex dialect or whether matching is case-sensitive; 'lines' is not mentioned at all and its default is undisclosed.

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 specific resource (guest console log) and the operation (returning the last lines), which is more informative than the tool name alone. However, it never distinguishes itself from the sibling console_messages, which sounds like it addresses the same log, so an agent cannot tell which to pick.

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 no guidance on when to use this versus console_messages or inspector_raw, both plausible sources of console output. The only usage hint is 'optionally filtered by a regex', which describes the parameter, not when to choose the tool.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only says it loads an address without typing; it does not disclose side effects, whether the current page is replaced, timeout behavior, or any browser-state prerequisites.

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

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

The description is very short and front-loaded, but it is cryptic and relies on comparison to another tool rather than directly explaining behavior. It is concise without being sufficiently structured for correct invocation.

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 three-parameter navigation tool with no annotations and no output schema, the description is substantially incomplete. It omits page selection, timeout semantics, side effects, and the relationship to open_url, leaving important invocation context unstated.

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%, with only the 'page' parameter documented in the schema. The description mentions 'address' but does not explain the 'url' or 'timeout' parameters, nor does it add meaning beyond the schema.

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

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

The description states a specific action and resource: loading an address. It is clear enough as a navigation operation, but it does not explain how 'navigate' differs from the sibling 'open_url' beyond the vague phrase 'same as open_url (no typing).'

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 references open_url but does not say when to choose navigate over open_url or type_text. There is no guidance about prerequisites, page selection, or timeout usage, so the agent must infer the intended usage.

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 an important behavioral trait: results are bounded to the window since the inspector attached, implying buffered state and that prior history is unavailable. It does not say whether the call drains or preserves the buffer, how ordering works, or how results are capped.

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 sentence with no filler. The telegraphic, fragmentary style ('Requests of the page since...') sacrifices a little clarity for brevity, leaving the sentence grammatically incomplete.

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?

Listing the returned fields compensates somewhat for the absence of an output schema, and the attach-time scoping is stated. But with no annotations, one undocumented parameter, and no information on pagination or buffer behavior, an agent cannot fully predict the result shape or limits.

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 67%: 'page' and 'wait' are documented in the schema, but 'limit' has no description anywhere. The tool description itself never mentions any parameter, so it adds no meaning over the schema and leaves the limit semantics entirely undefined.

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?

It names a specific resource (the page's network requests, with the returned fields: url, method, status, mime type, failures), which clearly separates it from siblings like console_messages or inspector_raw. The phrasing is a noun fragment rather than a verb+resource statement, so it reads as a data listing rather than an action, but the intent is unambiguous.

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

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

The scope constraint 'since the inspector attached' implies this is a session-scoped capture buffer, which is useful context. However, there is no explicit when-to-use guidance, no mention of alternatives (e.g., console_messages for logs, inspector_raw for raw protocol data), and no statement about what happens if the inspector is not attached.

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 two execution paths, that Safari may be started as a side effect, and the rough latency (~3 s vs. minutes). It omits failure modes and what happens to existing tabs or the current page state.

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

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

Two dense sentences, front-loaded with the action and its fallback; nothing is filler. The compressed phrasing ("No typing. typing=true types it...") is slightly terse but readable.

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 annotations and no output schema, the definition leaves notable holes: timing/pacing parameters are unexplained, there is no mention of return value or error behavior, and no relation to the `navigate` sibling. Adequate but 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 20% (only `page` is documented). The description meaningfully explains `typing=true` including its cost, which compensates for one gap, but `delay_s` and `timeout` are undocumented in both schema and description.

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

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

States a specific verb and resource ("Open an address in Safari") and even discloses the two internal mechanisms used (inspector vs. SpringBoard). It does not distinguish itself from the sibling `navigate`, which an agent may reasonably consider interchangeable, so it falls 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?

Gives clear conditional context: the ~3 s inspector path applies when a page exists, otherwise SpringBoard starts Safari. It also contrasts the default no-typing behavior against `typing=true`, with an explicit cost warning ("minutes"). No guidance on when to prefer this over sibling `navigate`.

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 a one-sentence description, the full burden is on the description, which discloses almost nothing. It does not mention whether reload discards unsaved state, whether it bypasses cache by default (despite an `ignore_cache` parameter), or how long the page should be waited for. The only clue is the word 'reload' itself, which implies navigation but not behavior.

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

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

The single sentence is front-loaded and free of waste, but its brevity reflects under-specification rather than efficiency. There is no structural layering to help the agent understand when or how to invoke 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?

For a three-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain page selection, cache behavior, wait semantics, or what happens on reload. The agent must infer all behavioral details 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 coverage is 67%, with `ignore_cache` undocumented in both schema and description. The description does not explain the default page selection or wait behavior beyond what the schema already says. It adds no value over 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?

The description provides a clear verb+resource comb ('reload' and 'page'), but it doesn't distinguish from sibling tools like `navigate` or `open_url`. The phrase 'the page' is also ambiguous when a `page` index parameter exists, leaving the agent to infer which page is affected.

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 `navigate`, `open_url`, or `back`. No context, prerequisites, or exclusion criteria 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the mechanism and side effect (SpringBoard opens the URL, which starts Safari) and the default URL, but omits timeout behavior, failure modes, permission needs, and what happens if Safari is already 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?

Two sentences, front-loaded with the purpose and mechanism, with little wasted text. The phrase 'a page the inspector lists' is slightly ambiguous, but the description remains efficiently 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?

Given no annotations, no output schema, and 0% schema description coverage, the description provides enough context to attempt the launch after boot/restore. It still leaves `timeout` undocumented and does not describe failure or return behavior, so it is only adequate rather than 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 0%, so the description must explain both parameters. It explains `url` and its about:blank default, but never mentions `timeout`, leaving the agent without units or behavioral meaning for that parameter.

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 action: launch Safari at a given URL through SpringBoard, with about:blank as the default. It distinguishes itself from tap/typing flows and mentions inspector-listed pages, but does not explicitly contrast with siblings such as open_url or navigate.

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 a clear timing condition: call after the VM has booted or a snapshot is restored. However, it does not state when not to use it or how it differs from open_url, navigate, or reload, leaving alternatives to inference.

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. It discloses the output format, base resolution, and default scaling, but does not mention read-only safety, device readiness requirements, latency, or whether it has 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 unnecessary words. It efficiently conveys the core output and scaling behavior.

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

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

For a simple one-parameter screenshot tool with no output schema or annotations, the description covers the essential output and scaling behavior. It could be more complete by noting read-only safety or return representation, but it is largely sufficient for correct invocation.

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

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

The only parameter, scale, has 0% schema description coverage, so the description must compensate. It does so by stating the default value (2) and that the screen is scaled down by this factor from 1125x2436, adding meaning beyond the schema's min/max bounds.

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

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

The description clearly identifies the resource and output format: a PNG of the phone screen. It adds resolution and scaling details, though it does not explicitly name a capture verb or differentiate itself from siblings beyond the unique screenshot concept.

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 inspector_raw or other visual inspection tools. The description only states what the output is, leaving usage context implicit.

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 only discloses that amount defaults to 0.4. It says nothing about whether scrolling waits for rendering, what settle/wait_change/stable_for do together, or whether the call blocks until the timeout.

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 tight sentence with the core behavior and the two most-used parameter semantics front-loaded. Nothing is padded, though the parenthetical format slightly buries the default value.

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, annotation-free interaction tool with no output schema, the description leaves the timing/settling parameters entirely unexplained, which is exactly the complexity an agent needs help with.

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 17%, so the description must compensate; it does explain direction's enum values and amount's units (fraction of screen) and default. However, four of six parameters (timeout, stable_for, wait_change, and the interaction of settle) remain undocumented in both schema and description.

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

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

States a specific verb (scroll) and resource (the page) plus the axis vocabulary, so the action is unmistakable. It does not distinguish itself from near-siblings like swipe or scroll_into_view, which also move the viewport.

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 scroll versus swipe or scroll_into_view, and no mention of preconditions such as needing a loaded page. The agent must infer tool selection from 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?

With no annotations, the description carries the full behavioral burden. It doesn't say whether this waits for the element to exist, what happens if the selector matches nothing, whether it mutates page state (scrolling), or how the 'page' and 'wait' parameters affect behavior. Only the block alignment semantics are implied.

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. However, it is terse to the point of under-specification rather than fully earned 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?

Five parameters, one enum, no annotations, and no output schema. The description explains only 'block' behavior and leaves page selection, wait semantics, and match indexing unexplained. It is not complete enough for a multi-parameter tool with no annotation coverage.

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%, so the schema documents page, wait, index, and selector. The description mentions the block values, which the schema already supplies as an enum, so it adds no new meaning. 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?

States a specific verb and resource: scroll an element into view, with the block alignment options listed. It is clear on its own, but it does not distinguish itself from the sibling 'scroll' tool, which is the obvious alternative an agent would consider.

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 when-to-use or when-not guidance. Nothing tells the agent why it would use this instead of 'scroll', 'tap_css', or 'js'. There are no prerequisites or exclusions 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 behavioral burden and does so well by disclosing the frame-comparison stability mechanism, the stable_for duration, and the timeout fallback. It does not clarify whether timeout is treated as an error or normal completion, but the core behavior is transparent.

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

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

The description is a single efficient sentence that front-loads the core behavior and includes only relevant details. There is no redundant or filler 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 simple two-parameter wait tool with no annotations and no output schema, the description covers the main mechanism. However, it leaves out default behavior, timeout units, and what a timeout result means, which are relevant for correct invocation and interpretation.

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. It meaningfully explains stable_for as a seconds-based stability threshold and timeout as an end condition, but it does not specify units for timeout, default values, or how the two parameters interact beyond the basic condition.

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 and condition: wait until the screen stops changing, defined as two equal frames lasting stable_for seconds, or until timeout. It is clear what the tool does, but it does not differentiate itself from related waiting tools such as wait or wait_for.

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 explains the waiting condition but gives no guidance on when to choose this tool over siblings like wait, wait_for, or screenshot. There are no explicit when-to-use or when-not-to-use instructions.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it delivers almost nothing behavioral. It does not say whether the call blocks until the gesture settles (that lives only in the settle param), whether gestures are rejected out of bounds, or what a returned result looks like. Only the canned gesture geometry is communicated.

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, gesture purpose front-loaded, zero filler. Every clause carries usable information about how to produce the intended screen change.

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 no annotations and no output schema, the description covers only geometry examples. Timing, settle behavior, failure conditions, and return semantics are absent, and with four extra timing params undocumented in the schema, the definition leaves real operational gaps.

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

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

Schema coverage is 56 percent and the four required coordinate params are described only by repeating their names ('x0', 'y0'...). The description does add real meaning by showing example values such as y=0.985 and 'left edge,' which signals the coordinates are normalized 0-1 fractions. It says nothing about ms, timeout, stable_for, or wait_change, leaving half the parameters undocumented in both sources.

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 (swipe) plus two concrete gesture recipes: 'up from y=0.985 to open or leave an app' and 'from the left edge for back.' That is enough for an agent to distinguish it from tap/hold/scroll, though it never explicitly contrasts itself with the sibling back and home_screen tools that serve the same outcomes.

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 gives concrete how-to recipes, which imply when to use this gesture (open/leave an app, navigate back), but there are no explicit exclusions or routing rules. With siblings named back and home_screen available, the agent gets no guidance on which of the three to prefer.

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 disclosure burden. It reveals the coordinate convention (fractions, origin top-left) but says nothing about post-tap waiting behavior, which the presence of settle/timeout/stable_for/wait_change suggests is configurable and important for correctness.

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 action, then the coordinate convention, then the alternative-tool pointer. Nothing is padded.

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 tool with no annotations and no output schema, the description covers the mandatory coordinates but leaves the timing/settling parameters and the return behavior unexplained. Adequate to call it, not adequate to tune 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 50%: x/y are described only as 'x'/'y' in the schema, so the description's 'fractions of the screen, 0,0 top left' is genuinely additive. But timeout, stable_for, and wait_change are undocumented in both the schema and the description, leaving half the parameters opaque.

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 action ('Tap') on an implicit resource (the screen at coordinates) and adds the coordinate system. It does not differentiate from sibling tap_px or tap_css, which are the closest competitors, so it falls 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?

'For a page element use tap_element' explicitly routes one common case to a sibling. However, no guidance is given for tap_px (pixel coordinates) or tap_css, leaving the agent to infer when normalized fractions are preferable to pixel values.

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 says nothing about what event is dispatched, whether it waits for the page/settle, what the return value is, or how the default page selection behaves — all relevant for a 4-parameter mutation-like interaction 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?

A single sentence with zero filler, and the coordinate-space qualifier — the most important information — is placed immediately after the verb.

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 point-tap tool the coordinate semantics are covered, but with no annotations, no output schema, and an undocumented default page/wait behavior, the agent still lacks the behavioral picture for reliable invocation.

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

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

Schema coverage is 50%: page and wait are documented in the schema, while x and y are bare numbers. The description usefully supplies the missing meaning for x/y (CSS pixels, layout viewport, getBoundingClientRect origin), which is real added value, but it says nothing about page or wait.

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 concrete verb (tap) plus the exact coordinate space ('CSS pixels of the layout viewport'), which is precisely what distinguishes it from the tap_px and tap siblings. However, it never names those siblings, so differentiation is inferred rather than explicit.

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 getBoundingClientRect parenthetical hints at when the coordinates come from, but there is no explicit guidance on choosing this over tap, tap_px, or tap_element, and no exclusions or preconditions 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 must carry the behavioral burden, and it does disclose something genuinely useful: the touch point is measured, so results hold regardless of Safari's bars or the on-screen keyboard. It says nothing about failure behavior when the selector matches nothing, whether it waits for the element, 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 sentence with the core action front-loaded and the parenthetical caveat placed after it. The parenthetical is informative rather than filler, though the phrasing is slightly wordy.

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 interaction tool with no annotations and no output schema, the definition covers the mechanics but leaves out error/edge-case behavior (missing element, multiple matches, interaction with the wait parameter) that an agent would need in order to call 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 coverage is 100%, so all five parameters (including page, wait, index, scroll) are already documented in the schema. The description's only added semantic is that the tap targets the element's center, which is a small but real supplement.

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: tapping the middle of a page element by CSS selector, with the notable detail that it produces a real touch at a measured screen position. It does not, however, distinguish itself from the closely-named sibling tap_css (or from tap/tap_px), so an agent cannot tell from the description alone which of these to pick.

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 over tap, tap_px, or tap_css, and no prerequisites or exclusions are stated. The only implicit signal is that it works on page elements rather than raw coordinates.

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 whole burden. It does not disclose that this is a synthetic input injection, what the tap does to app state, whether it blocks, or what the four timing parameters (settle, timeout, stable_for, wait_change) control; only the coordinate/scale behavior is conveyed.

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 tight sentence with the coordinate frame front-loaded and the critical constraint in a parenthetical. Nothing is wasted, though the brevity comes at the cost of omitting needed detail.

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

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

For a 7-parameter action tool with no annotations and no output schema, the description is far too thin: the wait/settle semantics, default behavior, and return values are all unaddressed, leaving an agent unable to reason about the four timing knobs.

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 14%, so the description must compensate and it only partially does: it clarifies that x/y are screenshot pixels and that scale must equal the screenshot's scale value, which is genuinely non-obvious. The remaining timing parameters (timeout, stable_for, wait_change, and partly settle) are left entirely undefined in both schema and description.

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

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

States a specific verb (tap) and a specific coordinate frame (pixels of a screenshot you took), which distinguishes it in spirit from the sibling `tap` and from `tap_element`/`tap_css`. It never names those alternatives outright, so the differentiation is inferred 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?

The phrase 'a screenshot you took' implies the workflow (capture, then tap in that image's pixel space) and the parenthetical tells the caller to match scale. There is no explicit when-to-use vs. `tap`, `tap_element`, or `tap_css`, and no statement of preconditions or failure modes.

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 well: it discloses the ~2.5 s/key cost, that events are real OS-level taps, the precondition that the keyboard must be visible, the supported character set, and that submit presses Go. It leaves out what happens with unsupported characters or on timeout, but the key behavioral traits an agent must plan around are present.

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-loads the mechanism and cost, then the character set, then the alternative — a sensible order with little waste. It is dense as a single run-on clause, but every element (speed, precondition, charset, submit, alternative) earns its place.

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

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

The core purpose, cost model and alternative are complete for a 7-param tool with no annotations and no output schema, but the five synchronization parameters (delay_s, timeout, stable_for, wait_change, settle) are never addressed, leaving an agent guessing about waiting and failure behavior.

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

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

Schema coverage is only 14% (1 of 7 params documented), so the description must compensate. It adds real meaning for text (the supported character set: lower-case letters, digits, space and . - / : ( ) ; $ & @ ") and for submit ('set submit to press go'), but delay_s, timeout, stable_for, wait_change and the described-only settle have no explanation anywhere — four timing/synchronization knobs remain opaque.

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 (type) plus the exact mechanism (tapping on-screen keyboard keys, real key events) and names the sibling it is not ('For fast input use fill'). An agent can distinguish this from fill and key 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?

Gives a hard precondition ('the on-screen keyboard ... must be showing') and an explicit alternative ('For fast input use fill'), which is the decision rule an agent needs. It stops short of saying exactly when the slow-but-real key events are required (e.g. apps that reject synthetic input), so the exclusion is implied rather than 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?

No annotations exist, so the description carries the full burden, and it delivers real behavioral facts: the operation takes a minute or more, produces GB-scale artifacts, and requires a VM launched with saveable=true. It does not say whether the VM is paused/resumed during the save or what happens if the precondition fails, so it falls short of fully covering a mutation with zero annotation support.

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

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

Three tight clauses ordered by importance: what it does, the operational cost, the restore route, then the precondition. No filler and every sentence adds information the agent cannot get 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?

Given no annotations, no output schema, and 0% schema coverage, the description covers motivation, cost, and prerequisites well but leaves the resume/timeout parameters and the post-save VM state undefined. Adequate to invoke correctly with the required parameter, incomplete for the optional ones.

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% for 3 parameters, so the description must compensate, but it only glosses 'name' as 'a named snapshot'. Neither the boolean 'resume' nor the integer 'timeout' is mentioned anywhere, leaving two of three parameters documented nowhere an agent can see.

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 ('Save') plus resource ('the whole machine state') and target ('a named snapshot'), which cleanly separates it from vm_snapshots (list) and vm_start (restore path). The parenthetical that files are GB-sized makes the operation's weight 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?

Explicitly names the restore counterpart with the exact call form vm_start(snapshot=name), and states the precondition 'Only works for a VM started with saveable=true'. What's missing is any guidance on when not to save (e.g. running vs stopped state), but the routing context 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?

With no annotations, the description carries the full behavioral burden. "List" weakly implies a read-only operation, but it does not state whether snapshots are per-VM, ordering, freshness, or whether an empty result is possible; there is no real disclosure of 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?

Three words, front-loaded with the verb, with no filler whatsoever. It is efficient, though the extreme terseness leaves room that could have been used for behavioral context.

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

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

For a zero-parameter list tool with no output schema, the description never indicates what a snapshot record contains or how results are shaped. It is minimally adequate to select the tool but incomplete for interpreting results.

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 and the schema is empty, so there is nothing for the description to clarify. Baseline 4 applies for a no-argument tool.

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

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

"List saved snapshots" pairs a specific verb with a specific resource, so the agent knows this enumerates existing VM snapshots. It does not explicitly name the related siblings (vm_save, vm_status), but the resource distinction is strong enough to separate it from those.

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 call this versus vm_status or vm_save, no preconditions, and no stated exclusions. The agent must infer from the name alone that this is the discovery step before restoring or starting from a snapshot.

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 that startup is backgrounded and slow (9-14 min vs 30 s for restore), which is decision-critical. It omits what happens on repeated invocation while running, and what state or handle 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 short sentences, front-loaded with what it does and followed by timing plus the required next step. No filler; each clause conveys operational 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 no-required-param boot tool with no output schema, the description covers what an agent needs to sequence correctly: it is long-running, backgrounded, and must be followed by safari_ready. Missing only failure/already-running behavior and any return value note.

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 every parameter is already documented with defaults. The description only adds meaning to the snapshot path by noting a restore takes about 30 s; it says nothing about cpus, seconds, saveable, or spinlock_timeout_us 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: "Boot HackiOS in QEMU in the background." An agent immediately knows this launches the VM rather than managing it. It doesn't explicitly differentiate from siblings like vm_status or wake, though the snapshot-restore alternative is mentioned.

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 clear sequencing ("Then call safari_ready") and decision-relevant context (9-14 min cold boot vs ~30 s snapshot restore), which tells an agent when to prefer a snapshot. It stops short of stating exclusions, e.g. what to do if the VM is already 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 and no output schema, the description bears the full disclosure burden, and it does say which four data points come back — genuinely useful since nothing else documents the return. However, it says nothing about whether the call is safe/read-only, whether it errors when the VM is not booted, or how the values are formatted.

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 compact sentence in which each clause maps to a distinct returned field, so nothing is wasted. The interrogative framing is slightly informal and defers the identification of the tool's action rather than front-loading 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?

For a zero-parameter diagnostic with no annotations and no output schema, the description covers the essential question of what information is returned. It falls short only on failure behavior and return formatting, which are minor at this complexity level.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The schema is an empty object and the description correctly implies no arguments are 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?

The description names the resource (QEMU/the VM) and enumerates the four facts it reports: running state, panic, touchscreen acceptance, and boot phase. It is clearly a status/diagnostic query and reads distinctly from siblings like vm_start, vm_stop, and vm_save, though it never uses an explicit verb ("report"/"return") and instead poses questions.

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 statement of when to call this versus alternatives such as wait_for, vm_start, or wait, nor any preconditions (must the VM be started?). The boot-phase clause faintly implies use during startup verification, but an agent must infer that entirely.

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. 'Stop QEMU' implies a mutation, but it does not disclose whether the stop is graceful or forced, what state is lost, whether it is idempotent, or what permissions are required.

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

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

The description is extremely concise and front-loaded with the action. However, the two-word fragment is so terse that it omits useful framing, such as what QEMU refers to in this context.

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 no parameters, the description must carry behavioral context for a destructive lifecycle operation. 'Stop QEMU' identifies the action but leaves out operational details an agent would need 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?

The tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is appropriate 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?

The description states a specific verb and resource: 'Stop QEMU.' It is clear enough to distinguish stopping from starting, but it does not explicitly frame QEMU as a VM or differentiate further from sibling lifecycle tools like vm_start or vm_status.

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, no prerequisites, and no exclusions. The name and sibling tools imply it is for stopping a VM, but the description itself provides no usage context.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the 60-second cap and the reason waits are needed, but omits whether the call blocks, what default duration applies when seconds is omitted, and what happens above 60 seconds.

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, front-loaded with the action and cap, and the parenthetical rationale earns its place by explaining why the tool exists.

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

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

For a simple one-parameter sleep tool, the description covers purpose and cap but leaves default behavior and sibling routing unspecified. Without annotations or an output schema, those omissions are noticeable.

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 explain the sole parameter. It implies the parameter is a duration in seconds capped at 60, but does not state whether it is optional, what default applies if omitted, or how values over 60 are handled, so compensation is only partial.

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 action ('Sleep') and scope ('up to 60 s'), with a rationale ('guest is slow; animations take time'). It does not distinguish this fixed sleep from siblings like wait_for or settle, so it is not a 5.

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

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

The parenthetical gives a use case (waiting for slow guest animations) but does not explicitly say when to choose this over wait_for/settle or when not to use it. Guidance is implied rather than 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 burden and does disclose the key trait: this call blocks, and it is bounded by a max 280 s timeout. However it doesn't say what happens on timeout (error, false return, partial state) or what is returned on success, which matters for a blocking primitive.

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 stating the blocking behavior, the phase values, and the timeout ceiling with zero 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?

No output schema and no annotations, so the description should ideally cover the return value and timeout-end behavior. It covers the phase domain and time bound but leaves the outcome of the call ambiguous.

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%, so the description must compensate, and it largely does: it enumerates the valid phase strings and gives a concrete max for timeout (280 s), effectively documenting both parameters. It stops short of stating a default timeout or units/behavioral meaning of the phase omitted case.

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 ('block until') and resource (a boot phase), and enumerates the phase values, so an agent can tell this is a boot-progress synchronization primitive rather than a generic wait. It doesn't explicitly differentiate from siblings like wait or settle, but the boot-phase framing is distinctive enough.

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

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

The description implies when to use it (waiting for boot progression) via the phase list, but never states when to prefer it over the sibling 'wait'/'settle' tools or what to do when no phase is given. Usage is inferable but not spelled out.

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 does disclose that the tool synthesizes input (a tap plus a home-key press), which is real value, but it never says what happens if the screen is already on, whether the home press navigates away from the current app, or what a failure/timeout looks like.

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

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

A single compact sentence with the purpose front-loaded and zero filler. The mechanism detail in the parenthesis earns its place, though the phrasing is terse enough to be slightly cryptic.

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 composite action with four parameters at 25% schema coverage, no annotations, and no output schema, the description leaves major gaps: parameter behavior, idempotency (safe to call when awake?), and timing/return semantics are all 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 25% — only 'settle' is documented — and the description explains none of the four parameters. The three timing parameters (timeout, stable_for, wait_change) are undocumented in both the schema and the description, leaving an agent to guess at the semantics of a timing-sensitive control call.

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 ('Wake the display') and even names the underlying mechanisms ('a tap and then the home key'), which lets an agent distinguish this composite action from the raw siblings tap, key, and home_screen. It stops short of explicitly naming those siblings as alternatives.

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 'it turns off after boot' implies the trigger context (use immediately after boot when the screen is dark), but there is no explicit when-to-use/when-not guidance, no statement about calling it when the display is already awake, and no pointers to the tap/key siblings as fallbacks.

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