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

The description adds useful behavioral detail beyond the annotations: it explains that an existing running window is focused first, otherwise a known executable or Start Menu application is launched. It also lists supported aliases, which helps predict behavior. It does not cover failure modes for unknown applications, but the annotations already provide safety and idempotency 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 three sentences, front-loaded with the key distinction, and contains no filler. Each sentence contributes either purpose, behavior, or parameter guidance.

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 one-parameter local application launcher with annotations and an output schema, the description is sufficient. It explains the dual focus/launch behavior, identifies the local-app scope, and gives concrete alias examples.

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

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

The input schema fully documents the single required parameter, so the baseline is 3. The description adds value by supplying a broader set of concrete aliases such as explorer, cmd, powershell, calculator, edge, and chrome, which goes beyond the schema examples.

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: it opens or focuses a local application, either by focusing an existing window or launching a known executable/Start Menu app. This clearly distinguishes it from the browser-oriented sibling tool.

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 identifies itself as the 'Fast path for local applications,' which gives clear context for when to use it versus browser_open. However, it does not explicitly name browser_open or state exclusions such as web URLs or unknown executables.

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

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

Annotations already declare openWorldHint/idempotentHint/readOnlyHint, but the description adds real value beyond them: platform-specific launch behavior (default browser, Edge, Chrome on Windows) and the fact that cloud mode uses an embedded Playwright browser that blocks private addresses by default. It does not cover failure/timeout behavior or whether navigation waits for load.

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, each carrying distinct information (purpose/scope, Windows routing, cloud-mode behavior), with the fast-path framing front-loaded. 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?

With an output schema present, return values needn't be explained, and the description covers the key differentiators of platform and cloud mode. Minor gap: no note on what happens with the browser parameter off Windows or on failure.

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%: url is documented in-schema, while browser has only an enum with no description. The description partially compensates by mapping the browser choice ("default browser, Edge, or Chrome"), but only in the Windows context — it never says what browser does in cloud/Playwright mode, so the gap is only half closed.

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?

Opening a known absolute http(s) URL is stated as a specific verb+resource, and "Fast path" plus "without screenshots or mouse movement" implicitly separates it from the computer_observe/mouse_screenshot loop. It stops short of naming a sibling tool outright, which keeps it out of the top band.

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?

"Known http:// or https:// URL" is a usable precondition and "fast path" implies direct navigation over screenshot-driven interaction. However, it never states when NOT to use this (e.g., when the page needs to be inspected or clicked, use computer_observe/mouse_click) and names no alternative.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety profile is covered. The description adds value by detailing the returned context and noting Windows-specific coverage, which goes beyond what annotations supply. Minor gap: no note on latency or that the capture is non-blocking.

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 core action, with the return-content enumeration in the middle and usage guidance last. Efficient overall; "return richer context" is slightly vague but the following sentence clarifies it.

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

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

With no input parameters and no output schema, the description carries the burden of describing return values, which it partially does by listing window, taskbar, monitor and application details. A note on response format or whether additional platform differences exist beyond Windows would make it fully 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly avoids inventing 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?

States a specific verb (Capture) and resource (active desktop/browser) and enumerates the returned context (active window, taskbar rectangles, monitors, visible application windows). It is clear what the tool does, though it never explicitly distinguishes itself from the sibling mouse_screenshot, which likely also captures the surface.

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 explicit timing guidance: "Use this before visual targeting and again for verification." That tells the agent when in a workflow to call it. It lacks explicit exclusions or a named alternative (e.g., mouse_screenshot), so it earns a 4 rather than a 5.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds genuinely new context: the mandatory intent contract and the fact that destructive, bulk-submission, and close-all actions surface an explicit user prompt before proceeding. It also clarifies that the click only happens after an optional move when coordinates are null. It does not describe failure behavior or how the click is confirmed as landed.

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

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

Three sentences, front-loaded with the operation and followed by the mandatory-intent rule and the safety escalation. Every sentence contributes, with only minor redundancy between 'intent is mandatory' and the schema's own constraint.

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

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

An output schema exists, so return values need no explanation, and the description covers the action semantics, coordinate handling, and the confirmation gate for risky actions. What remains thin is post-click behavior (waiting for UI response, failure reporting) and any mention of target_description, which is the only unaddressed field.

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%, so the description carries real weight: it explains that x/y are conditional (despite being listed as required with null allowed), that button is a single left/right choice, and that clicks covers single or double. target_description is not mentioned at all, and 'left double click' slightly understates that the schema permits clicks=2 with the right button, leaving a gap for an agent to resolve.

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

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

The description opens with a specific verb and effect ('Move to x/y if supplied, then perform one left/right click or a left double click'), which tells an agent exactly what the call does relative to siblings like mouse_move or mouse_drag. It stops short of naming those siblings, so the differentiation is implied by the move-then-click phrasing 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?

It states a hard requirement for the intent argument and flags which classes of action trigger an explicit user prompt, which implies when this tool is sanctioned. However, it never says when to pick mouse_click over mouse_move, mouse_drag, or a double-click alternative, and offers no explicit 'do not use for' 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?

Annotations already declare destructive/non-idempotent/open-world, but the description adds genuinely new context: the motion is a curved human-like path, and high-risk semantic intent triggers an explicit user prompt, which tells the agent a confirmation gate exists and can block the call. It does not clarify what the drag might destroy or what a denial returns.

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

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

Two short sentences, no filler, with the core action front-loaded and the mandatory-parameter constraint immediately after 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 7-parameter, destructive, open-world input tool with an output schema, the description covers intent gating and motion style but omits how the button choice affects behavior, what target_description is for, and what happens after a prompt is denied.

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 57%, so the schema documents the coordinates but leaves `button` and `target_description` bare. The description adds real meaning only for `intent` (mandatory, risk-evaluated), leaving two parameters undocumented in both places.

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 (drag) and the resource/scope (from one point to another) plus a distinctive behavioral trait (human-like curved path). It is distinguishishable from mouse_move and mouse_click by virtue of the press-and-release drag semantic, though it never names those siblings explicitly to draw the contrast.

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 drag versus the obvious alternatives (mouse_move + mouse_click, or mouse_scroll for wheel-based dragging). The only conditional statement is the high-risk-intent prompt, which is behavioral, not usage routing.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the movement follows a human-like curved path, coordinate spaces differ between browser and Windows, and out-of-range targets are clamped.

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 no filler. It front-loads the core action and then adds the two important execution details: coordinate space and clamping 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?

An output schema exists, so the description need not explain return values. Given the two-parameter schema and the available annotations, the description provides sufficient context for correct invocation, though it could say a bit more about practical edge cases or timing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining that browser coordinates are CSS viewport pixels and Windows coordinates are physical desktop pixels, plus the clamping behavior for out-of-range targets.

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

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

The description uses a specific verb and resource: it says to move the active mouse cursor along a human-like curved path. It is clear what the tool does, though it does not explicitly contrast itself with siblings such as mouse_drag or 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?

The description implies the tool is for cursor movement, but gives no explicit guidance on when to use it versus mouse_drag, mouse_click, or mouse_position. There are no stated exclusions or alternative-routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing that two distinct cursor contexts exist (virtual browser vs real Windows), which the annotations do not convey. It does not explain which context is reported or how the two are disambiguated.

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. Every clause (virtual browser cursor, real Windows cursor) carries information the agent would not otherwise have.

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 an output schema present and annotations covering the safety profile, the description needn't explain return values. It is nearly complete; the only gap is not clarifying how the virtual vs real cursor distinction is resolved or under what configuration each applies.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly avoids inventing 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?

States a specific verb (Read) and resource (cursor position), and clarifies the scope by naming both possible targets: the virtual browser cursor or the real Windows cursor. An agent can distinguish this from mouse_move or mouse_click without consulting schemas.

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 (when you need the current pointer coordinates) but gives no explicit routing guidance against siblings such as mouse_status or computer_observe, which could plausibly overlap. No prerequisites or exclusions are stated, leaving selection partly 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?

Annotations already cover safety and idempotency, and the description adds useful behavior: it identifies the capture surfaces and says the text output includes image/viewport dimensions and coordinate space. It does not explain how the active surface is selected or any other limitations.

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

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

The description is two efficient sentences with the core capture surfaces front-loaded and no wasted wording. Every sentence contributes directly to understanding or usage.

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 zero-parameter screenshot tool with rich annotations, the description covers the main surfaces and the coordinate metadata needed for downstream mouse actions. A minor gap remains around how the active surface is determined or exactly what visual payload is returned.

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 schema semantics are minimal by definition. The baseline for a no-parameter tool is 4, and nothing in the description is needed to clarify 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 uses a specific verb, "Capture," and names the resources: active local browser tab, cloud browser, or full Windows desktop. It is clear but does not explicitly distinguish itself from siblings such as computer_observe or browser_open.

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 provides clear usage context: use the returned metadata to map a visual target into mouse tool coordinates. It does not state when not to use this tool or name alternatives, so it falls 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?

Adds real context beyond the annotations: the confirmation gate for high-risk intent, the mandatory intent argument, and the click-to-notch ratio. It does not disclose whether x/y reposition the cursor as a side effect, nor the 20-click cap, but the safety profile is already carried by readOnlyHint=false/destructiveHint=false.

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 what the tool does, then the unit of measurement, then the mandatory-argument rule. No filler; every sentence carries information an agent needs.

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

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

An output schema exists, so return values need no explanation, but with six parameters at 0% schema coverage the description leaves the optional x/y override and target_description unexplained, and the max of 20 clicks undocumented. Adequate for the core call, incomplete for the full parameter surface.

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

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

Schema coverage is 0%, so the description must compensate; it explains 'clicks' (wheel notch unit) and 'intent' (mandatory, may trigger confirmation), roughly two of six parameters. It says nothing about x/y or target_description, and the schema itself mislabels y as a 'Horizontal coordinate', which the description does not resolve.

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 up or down') and pins the effect to 'the current cursor location', plus a concrete unit ('one click is one wheel notch'). It is clearly distinguishable from mouse_move/mouse_click by the wheel-scroll framing, though it never names a sibling 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 only conditional guidance is 'intent is mandatory; high-risk semantic intent is confirmed first', which is a precondition rather than when-to-use/when-not guidance. Nothing tells the agent how to decide between scrolling and, say, mouse_move-then-click or computer_observe to reach off-screen content; that is left 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description still adds value by clarifying the absence of side effects ('does not move the mouse') and by naming the state it surfaces, though it says nothing about failure modes or staleness semantics of the fields.

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

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

Two sentences, both earning their place: the first front-loads the returned state, the second kills the most likely misread. No filler or restatement of the name.

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

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

With no parameters, an output schema present, and annotations covering the safety profile, the description needs only scope and side-effect clarity, which it provides. The only gap is the missing cue for when in a workflow to invoke it.

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

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

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate and it correctly spends no words on arguments.

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 verb ('Read') and enumerates the exact resources inspected: routing state, companion freshness, viewport, platform, failure count. The closing sentence 'This does not move the mouse' explicitly distinguishes it from the action siblings mouse_move/mouse_click/mouse_drag.

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

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

Usage is only implied: the field list suggests a diagnostic/pre-flight check before acting, but the description never says when to call it or which sibling to reach for otherwise (e.g. mouse_position for 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?

Annotations only declare it is a non-read-only, idempotent, non-destructive write; the description adds real detail about scope of effect — pending queued actions are discarded, any held button is released, and a stop signal is pushed to the browser companion. It does not say what happens if nothing is pending (silent no-op vs error), which is the remaining 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?

One sentence, front-loaded with 'Immediately', and every clause names a distinct effect of the stop. Nothing is repeated from structured fields.

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 an output schema present the description needn't explain return values, and the annotations carry the safety profile. For a zero-param emergency tool this is nearly complete; only the behavior when no action is in flight is 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?

Zero parameters, so there is no parameter semantics to document; baseline 4 applies. Nothing in the description misleads about inputs.

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

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

Uses precise verbs (cancel, drain, release, send stop) against concrete resources (current mouse action, queued actions, held buttons, browser companion). No sibling tool overlaps this 'halt everything' semantics, so an agent can identify it without opening a 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?

The adverb 'Immediately' and the emergency-stop title imply the usage context (abort a live action or clear a stuck queue), but the description never states when to prefer it over siblings such as mouse_status or computer_observe, nor any precondition for calling it.

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