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 return contents, the popup branch, and the caveat that a preview may show an interstitial instead of the requested page. It omits failure modes such as unreachable URLs, timeouts, or auth-walled pages, which matter for a navigation call.

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

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

Three tight sentences, front-loaded with the action and result, with no filler. Slightly telegraphic in the popup clause, but every sentence carries actionable 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?

An output schema exists, so the return-value prose is a bonus rather than a necessity, and the description adds the non-obvious parts: readiness flag semantics, input labels for smart_type, and the interstitial risk. Only the error/edge-case behavior is missing.

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

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

Schema description coverage is 0% and the single 'url' parameter is undocumented in both schema and description — no guidance on absolute vs relative URLs or scheme requirements. The parameter is largely self-evident from its name, so this is a real but modest gap rather than a blocking one.

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 ('Open a URL') and immediately characterizes the payload (title, readiness, input labels, short page preview), so an agent knows both the action and the observable result. It is clearly the navigation entry point among click/type/scroll siblings.

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

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

Explicitly routes downstream: use handle_popup to inspect/resolve a popup, skip wait_until_ready when ready is true, and pass the returned field label into smart_type. Each condition names the sibling alternative and the trigger for using it.

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

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

With no annotations, the description carries the burden and does disclose key behavior: auto popup/page targeting, popup prevention via container=popup, and return fields moved/at_end. It still omits safety/read-only status, side effects, permissions, and whether scrolling is animated or instant.

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

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

Three tight sentences with no wasted text. The core behavior is front-loaded, followed by return values and the popup-specific 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?

Adequate for a simple scroll tool with an output schema, since return fields need not be explained in depth. However, it leaves gaps around pixels and direction semantics and does not provide alternative-tool guidance, which matters given 0% schema description coverage and no annotations.

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 three parameters. The description explains container and auto behavior, but says nothing about the meaning or effect of pixels or direction, leaving two of three parameters without descriptive semantics beyond their enum/default values.

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') and adds scope detail: it scrolls without visual inference, auto-selects an active popup/terms panel, otherwise the page. It clearly contrasts with visual-based siblings implicitly, but does not name scroll_until_visible or another sibling explicitly.

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

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

Provides clear usage context for container=popup to prevent scrolling the underlying page, and explains the auto behavior. However, it does not state when to use this tool instead of scroll_until_visible, nor does it give explicit exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden: it declares the tool read-only and discloses the fallback path to D1 vision when accessibility data is unavailable. It does not discuss permissions or rate limits, but the read-only and fallback behavior are the key traits for this inspection tool.

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

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

Two sentences, front-loaded with the core purpose and followed by usage guidance. The return list is dense but earns its place, and there is no filler.

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

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

The output schema already describes the return shape, so the description need not repeat it. Given no parameters and a read-only inspection role, the description covers purpose, usage, and fallback behavior sufficiently, though it could mention when inspection is unnecessary.

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 is no parameter semantics to explain; the description correctly does not invent any. Baseline 4 applies for a parameterless tool, and nothing in the description contradicts 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?

The description states a specific verb (inspect), a specific resource (foreground app), and enumerates what it reads: platform requirements, accessible controls, and detected drawing canvas. It is clear enough to distinguish from the mouse/click/draw siblings, though it does not explicitly differentiate from visual_assert or wait_until_ready.

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 actionable downstream guidance: use exact labels from this tool in smart_click/smart_type for the fast path, and fall back to D1 vision when accessibility is unavailable. It does not state explicit exclusions or when not to call desktop_inspect, but it provides clear usage context.

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

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

With no annotations, the description must carry the full burden. It usefully discloses that strokes lift the brush between polylines and that canvas_bounds defaults to auto-detecting the Paint/browser canvas, but it omits whether browser mode requires a prior browser_open, what happens if coordinates fall outside bounds, and any preconditions for input focus.

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

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

Three tight sentences, front-loaded with the action, followed by input format and then the default-detection note. No filler, though the stroke-format sentence is dense and could be split for scanning.

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

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

Output schema exists, so return values need no explanation, and the core mechanics and point format are covered. The gap is the undocumented `mode` and `duration` parameters, which matter for choosing desktop versus browser targeting.

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. It does explain the two accepted forms of the required `points` argument and the default behavior of `canvas_bounds`, but leaves `mode` (desktop vs browser) and `duration` (drawing speed) completely undocumented in both schema and prose.

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

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

States a specific verb and resource ('Draw on a canvas by dragging the left mouse button') and clarifies the input shape. It implicitly contrasts with draw_shape by describing freeform polylines, but never names that sibling, so differentiation stays inferential.

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

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

Usage is only implied by the mechanism description; there is no explicit 'use this instead of draw_shape/mouse_drag' guidance or prerequisites. An agent must infer when freeform paths beat shape primitives.

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

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

With no annotations the description carries the full burden, and it does disclose a genuinely useful behavioral trait: it auto-detects canvas_bounds and centers the shape when coordinates are omitted. However it is silent on prerequisites (focused browser/desktop window), what mode does, and what happens with invalid coordinates.

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 with the shape enumeration up front and the auto-detection fallback following. The long shape list is functional rather than wasteful; no 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 an 8-parameter tool with zero annotation and zero schema-description coverage, the description omits too much: whether x/y is the shape's top-left or center, what width/height measure, and what duration controls (draw speed?) are all unaddressed. The output schema relieves it of explaining return values, but the input semantics gap is significant.

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 only partially does: it explains coordinates being optional, canvas_bounds auto-detection, and centering. It says nothing about width, height, duration, or mode, leaving four of eight parameters meaning-free for the agent.

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 (draw) and resource (shape), and enumerates the exact shapes allowed, which is strong evidence of scope. It never mentions the sibling draw_path or mouse_drag, so an agent must infer which drawing primitive to use from the shape enumeration alone.

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

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

The description implies use ('by dragging the mouse on the sheet') and notes a fallback behavior when coordinates are omitted, but gives no explicit when-to-use / when-not guidance against draw_path, mouse_drag, or smart_move. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries the full burden; it discloses meaningful behavior: never assumes consent, handles consent iframes, scrolls terms to unlock buttons, and reject does not fall back to accept. It also explains output statuses, though it omits explicit no-popup/error behavior and detailed side effects of accepting.

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 is front-loaded in the first sentence, and the remaining sentences each add safety, behavior, or output semantics. It is dense but efficient, with no filler.

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

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

Given no annotations and 0% schema coverage, the description covers purpose, behavioral caveats, and output statuses well. It still leaves max_scrolls and explicit no-popup/error handling unspecified, so it is not fully complete for a low-schema-coverage tool.

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

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

Schema description coverage is 0%, so the description must compensate. It names the four action values and explains the safety implication of reject, but never mentions the max_scrolls parameter, leaving one of two parameters semantically uncovered.

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 specific verbs (inspect/accept/reject/dismiss) and resource (popup), and explicitly covers consent iframes and disabled buttons. It is clearly scoped to popup handling, distinguishing it from generic siblings like smart_click and mouse_click.

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 usage guidance: use the user's requested choice, inspect is the default framing, and reject never falls back to accept. It does not explicitly say when not to use it or when a generic sibling should be used instead.

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 on the most non-obvious trait: this drives the real OS pointer, not a synthetic DOM event, and in browser mode it moves the real pointer first before clicking in the viewport. That is material side-effect disclosure an agent could not infer from the schema. It stops short of stating behavior when x/y are null (presumably click at the current position) or any failure/timeout 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 short sentences, zero filler, with the core action and the pointer type front-loaded and the sibling routing pushed to the end. Each sentence adds distinct information: what it does, how modes differ, where to go instead.

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 output schema covers return values and there are no annotations, so the description's job is mode/coordinate semantics and sibling routing, both of which it handles for a five-parameter mutation tool. The remaining hole is that button and double_click are undocumented in both description and schema, which for a click tool is a notable but not fatal gap.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for x/y by assigning them coordinate spaces (global screen coordinates in desktop mode, controlled-tab viewport in browser mode) and implies the mode enum. However, 'button' and 'double_click' are never mentioned, leaving two of five parameters documented nowhere.

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+resource ('Click the real desktop pointer') and immediately delimits the two operating modes, including the coordinate space each uses. It explicitly names two sibling tools (smart_click, handle_popup) with the conditions that select them, so an agent can route 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?

It names the alternatives and their selection criteria: smart_click for semantic targets, handle_popup for an explicit consent choice, and a hard requirement that browser mode needs x/y in the tab viewport. What is missing is guidance on when NOT to use this at all (e.g. preferring smart_click for anything addressable) and what happens when coordinates are omitted.

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

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

With no annotations, the description carries the full burden, and it does disclose the core behavioral model: an intermediate mouse-down state, smooth interpolation, and release. It omits anything about failure modes, focus requirements, whether coordinates are screen- or viewport-relative, and how mode=desktop vs mode=browser changes behavior — significant gaps for an OS-level input tool.

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

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

Two tight sentences. The action sequence is front-loaded and the use cases follow as secondary context. No filler.

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

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

An output schema exists, so return values need not be described. However, for a 7-parameter tool with 0% schema coverage and no annotations, the description leaves three parameters and the desktop/browser distinction unexplained, which is a real completeness gap for an agent trying to invoke it 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 description coverage is 0%, so the description must compensate. It only explains the four start/end coordinates; button (which button is held), mode (desktop vs browser), and duration (which governs the smoothness implied by "drag smoothly") are completely undocumented, and mode in particular is a behavior-changing enum an agent cannot infer.

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 sequence and resource: move to start point, press, drag, release at end point. This differentiates it from mouse_click and mouse_move by the press-hold-release semantics. It does not explicitly distinguish itself from draw_path or draw_shape, which overlap heavily in the drag/gesture space.

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?

"Ideal for Paint tools, sliders, selections, and drag-and-drop" gives positive usage contexts, which is more than nothing. But there is no when-not guidance and no mention of siblings like draw_path or smart_move, leaving the agent to infer which drag-like tool to pick when several qualify.

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 well by explaining that the tool only moves without clicking, that desktop mode uses global screen pixels, and that browser mode uses viewport pixels while syncing the real OS pointer on visible browsers. It omits details such as hover-event side effects, permissions, and duration behavior.

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

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

The description is compact and front-loaded: purpose first, then mode-specific coordinate behavior, then the alternative tool recommendation. Every sentence adds useful information without repetition.

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?

An output schema exists, so return values do not need description coverage. The main gaps are the undocumented duration parameter and the absence of side-effect or error-condition details, but the core behavior and usage routing are otherwise 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 description coverage is 0%, so the description must compensate. It clarifies the coordinate semantics for x and y in both modes and explains the mode enum, but it does not explain the duration parameter at all, leaving part of the four-parameter surface undocumented.

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: moving the mouse pointer without clicking. It distinguishes the two modes and names the sibling tool smart_move as the alternative for target-description-based movement.

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 explicitly says to prefer smart_move when only a target description is known, and it gives clear guidance for choosing desktop versus browser mode based on the coordinate system and visible browser syncing. This is enough to route an agent between moving by known coordinates and moving by 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 add real context: the 0.80 visibility threshold, stepwise scrolling, and popup scoping. It is silent on what happens when the threshold is never reached, how max_scrolls interacts with the loop, and whether scrolling is reversible.

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

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

Two short sentences, zero filler, with the core behavior and threshold front-loaded ahead of the sibling routing advice.

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?

An output schema exists so return values needn't be explained, but for a four-parameter inference-driven UI action with no annotations, the missing failure semantics and undocumented parameter meanings leave gaps an agent would need to guess at.

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, but it never explains mode (browser vs desktop), direction, max_scrolls, or the format expected for target_description. Only the popup/browser scoping hints at any parameter's effect.

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 ('scroll in steps') with the exact success criterion (visual P(visible) >= 0.80), which immediately distinguishes it from deterministic scrolling siblings. An agent can tell what this does and how success is measured without opening the schema.

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

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

Explicitly points to browser_scroll as the alternative and gives the selection criterion ('deterministic scrolling without inference'), plus notes scroll scoping to an active popup. It stops short of an explicit 'use this tool when...' statement, leaving the inverse condition to be inferred.

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 immediate clicking, ambiguity handling, fallback behavior, and that the result reports method and UI change, but it omits side effects, permissions, and browser-vs-desktop mode differences.

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, front-loaded with the primary click behavior, and every sentence adds actionable information about fallback, ambiguity, or reporting. There is no filler.

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

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

For a 3-parameter tool with no annotations, the description is under-specified. It covers the core click behavior and ambiguity fallback, but does not explain the mode or double_click parameters, and provides no safety or permission 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?

Schema description coverage is 0%, so the description must compensate. It clarifies target_description via 'uniquely named visible DOM target' but does not explain the mode enum (browser/desktop) or double_click, leaving two of three parameters undocumented.

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: click a uniquely named visible DOM target, with a fallback to D1 vision. It implies a smart-targeting behavior distinct from raw mouse_click, but does not explicitly name sibling tools, so it falls short of full sibling differentiation.

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

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

It gives clear usage conditions: use when the target is uniquely named and visible, avoid when duplicate names make it ambiguous, and fall back to D1 vision otherwise. It does not explicitly compare with coordinate-based mouse_click, leaving one alternative 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?

With no annotations, the description carries the burden well: it discloses that desktop mode uses accessible controls or D1 vision with the real OS pointer, browser mode moves both the tab mouse and real OS pointer, and that movement is blocked on low confidence or stale targets. It does not cover permission requirements or side effects of pointer movement, but the core behavior is well explained.

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 three tight sentences with the core action front-loaded and mode-specific behavior following. Every sentence adds relevant information without redundancy.

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

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

An output schema exists, so return values needn't be explained. For a pointer-movement tool with no annotations, the description covers mode behaviors and the low-confidence/stale-target guard sufficiently; only permission or pointer-state side effects are missing, which is minor.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It gives useful context for the mode enum by describing desktop vs browser behavior, but leaves target_description's expected format and matching semantics vague ('described target'). This partially compensates but leaves a clear gap.

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

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

The description states a specific action ('move/hover without clicking') and resource ('described target'), clearly distinguishing it from click-oriented siblings like smart_click and mouse_click. Sibling differentiation is implicit rather than explicit, but the no-click constraint is 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?

It explains the difference between desktop and browser modes, which guides mode selection, and notes that low confidence or a stale target prevents movement. However, it never explicitly says when to use smart_move instead of siblings like mouse_move or smart_click, leaving the alternative-selection reasoning 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 burden and does well: it discloses that old text is replaced, that the exact value is verified before optional Enter, and that status and typed_verified should be checked before claiming success. It does not explain failure behavior or differences between browser and desktop modes.

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

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

Three dense sentences with the core action front-loaded, followed by targeting advice and verification guidance. There is little waste and each sentence adds operational 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?

The description is sufficient for the default browser typing path, especially since an output schema exists and return values need not be explained. However, for a four-parameter tool with no schema descriptions and no annotations, the unexplained mode parameter and desktop behavior leave a meaningful gap.

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

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

Schema description coverage is 0%, so the description must compensate. It maps well to target_description (accessible label from browser_open), text_to_type (text being filled), and press_enter (optional Enter), but it never mentions the mode parameter or the browser/desktop distinction.

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: fill a visible editable input, replacing old text. This clearly separates it from navigation and clicking tools, but it does not explicitly contrast itself with smart_click or other text-entry 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?

Gives actionable usage context: use a visible editable input, quote its accessible label from browser_open, and verify the exact value before optional Enter. It lacks explicit when-not-to-use guidance or a direct comparison to sibling tools such as smart_click.

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 add real value: the 64-question batching limit and the crucial 'answer=null means uncertain, not confirmation' semantics. However it omits whether the call captures a screenshot, which target is asserted against in browser vs desktop mode, and any cost/latency or side-effect profile.

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 dense sentences, front-loaded with the batching capability and the null-semantics warning. Minor deduction: 'typed_verified' is referenced without definition and is not one of this tool's parameters, which may momentarily confuse an agent.

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?

An output schema exists, so return-value explanation is not owed, and the null semantics cover the most important part of the response. Still, an agent does not learn the difference between browser and desktop mode or what visual source is being asserted against, which matters for a vision tool in a 14-sibling browser/desktop toolbox.

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 and largely does not. It clarifies the `questions` array's cap (64) and element type, but the `mode` enum (browser/desktop) is never mentioned, leaving half the parameters uninterpretable from either source.

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

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

The verb (evaluate) and resource (visual questions) are explicit, and the batching cap of 64 in one model call is a concrete distinguishing trait. It does not state that the questions are answered against a captured screen, so an agent must infer the screenshot/vision mechanism from the name, but the intent is unambiguous and separable from siblings.

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

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

It names preferred alternatives ('Prefer DOM field labels and typed_verified for typing') and an explicit when-not ('avoid repeated visual assertions for an already verified action'). What is missing is a positive trigger — the description never says 'use this when DOM inspection is unavailable/inconclusive'.

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 useful work: it warns that readiness does not confirm task success and does not rule out a captcha, which sets correct agent expectations about false positives. It omits what happens on timeout (error vs. partial result), which is the main remaining behavioral unknown.

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, the skip condition is front-loaded before the caveats, and nothing is padding. The only waste is the mode-name mismatch, which costs clarity rather than length.

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

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

An output schema exists so return shape needn't be explained, and the caveats cover the main conceptual trap. But for a two-parameter timing tool, the absence of any timeout semantics (unit behavior on expiry, whether it throws) and the mode/enum mismatch leave real 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 0%, so the description must explain both parameters. It gestures at 'mode' but with terminology (hybrid/vision) that does not match the enum values browser/desktop, and it says nothing at all about timeout_seconds (default 10, presumably a maximum wait). The parameter guidance is actively confusing rather than merely absent.

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?

Names a specific action (wait for readiness) and distinguishes two operating contexts, and explicitly separates itself from browser_open by referencing that tool's ready=true return. However, it uses 'hybrid mode' and 'vision mode' while the schema enum is browser/desktop, so the agent must guess the mapping.

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 an explicit skip condition ('Skip this call when browser_open returned ready=true') which is exactly the kind of when-not guidance that prevents redundant calls. It does not, however, say when vision/desktop mode should be preferred over browser mode.

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