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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: it returns a probability rather than a definitive answer, and there is no output schema to otherwise convey that. Cost/latency caveats for look live only in the schema, so the description is not fully self-sufficient.

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: what it does and returns, the verification use case, then the mode switch. Front-loaded with the core capability and 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?

With five parameters, one enum, and no output schema, the description covers the essential contract: a probability answer about current on-screen text plus the visual-mode switch. It leaves the source/window/threshold parameters entirely to the schema, which is acceptable at this coverage level but slightly thin for a tool whose accuracy depends on which window is read.

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 enum and look semantics are already well documented in the schema. The description's look=true clause largely restates that schema text rather than adding new nuance, and it says nothing about source, window, or threshold. Baseline 3 is 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?

Names a specific action (ask a yes/no question about on-screen text) and the return type (probability), which is more precise than a generic 'observe'/'check screen'. It never names a sibling tool to contrast with, so the agent must infer that this differs from observe or screenshot rather than being told.

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 usage context: verifying whether the previous step succeeded. It also gates a mode (look=true when the subject is the picture itself: in-game, images, colors). It stops short of stating when NOT to use this tool or naming the alternative action tool for those cases.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavior beyond that: no mention of whether it waits for the target to be actionable, what happens on a miss, whether held clicks fire continuously, or whether the call blocks.

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

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

It is a single front-loaded clause with no filler, which is structurally clean. However, one sentence is too thin for a six-parameter action tool, so brevity here reads as under-specification rather than economy.

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 six optional parameters, no required args, no output schema and no annotations about side effects, the description should explain targeting precedence, what a click requires from prior calls, and the outcome. None of that is present, so an agent must reverse-engineer behavior from parameter names.

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%, with `id`, `hold` and `count` documented in-schema while `x`, `y` and `button` are not. The description's "coordinates or element id" usefully signals that x/y and id are alternative targeting modes, but it says nothing about hold, count or mouse button, leaving that half to the schema alone.

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 action and its two targeting modes: click by coordinates or by element reference. An agent can tell it apart from siblings like move, drag and scroll, though it does not explicitly contrast with check, which is the nearest overlapping verb.

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

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

There is no when-to-use guidance at all: nothing says to prefer `id` over x/y, nothing says to call observe/find first, and nothing distinguishes a plain click from `check` or a double click. Usage is only inferable from the parameter names in the schema.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — not whether it needs focus, whether the drag is visible, or how timing/button affect behavior. No contradiction with annotations.

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 characters are technically concise, but this is under-specification rather than economy. There is no waste, yet nothing is front-loaded because there is nothing to load.

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 GUI automation tool with six parameters, four of them required and none documented by the schema, demands far more than "press and drag." The agent cannot determine coordinate semantics, button defaults, or drag duration from this definition.

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% across six parameters. The description does not explain that x0/y0 is the start point and x1/y1 the end point, whether coordinates are screen or window relative, what values 'button' accepts, or what 'seconds' controls.

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?

"按住拖动" (press and drag) names a specific action and implicitly distinguishes itself from the sibling "move" by indicating the button is held down. However, it never states that it drags from one point to another, nor what it operates on (desktop, window, element).

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 instead of the sibling tools move, click, or scroll, and no prerequisites or exclusions are mentioned. The agent must infer everything from the name alone.

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

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses latency (about 0.3s vs 2–5s for look), that look mode two-passes the screenshot (coarse window box, then zoomed detail), that screenshots are sent only to Jev and not into the caller's context, and that look requires an official key (status jev_images=true). It leaves open what is returned on failure or when confidence falls below min_confidence.

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 capability is front-loaded in the first clause, followed by the fast path, the visual path, and the fallback in a logical escalation order. It is a dense run-on paragraph with several chained qualifiers, but almost every clause carries 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 9-parameter tool with no output schema, the description explains the main modes and confidence semantics but does not say what the response contains (element handle, coordinates, ranked candidates, failure shape) or what the remaining parameters do. An agent can invoke it but may be unsure how to consume or retry the result.

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

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

At 67% schema description coverage the description still carries extra meaning: it explains the click=true behavior and its confidence gate, the semantics of confidence as a post-zoom probability for look mode, and region's role as a look-mode search restriction. The `count` and `button` parameters remain undocumented in both description and 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 concrete verb and resource: describe the target in one sentence and Jev selects the matching UI element and returns a confidence. It also distinguishes the fast text/tree path from the visual path and names `screenshot` as an escape hatch. It does not distinguish itself from the sibling `click` or `observe` tools, which overlap in intent.

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?

Clear routing rules are given for the modes: default text/name matching, add look=true for icons/game visuals/images/colors, escalate to `screenshot` if that fails. What is missing is guidance on when to call `find` versus the sibling `click` tool, given that click=true makes this tool perform clicks directly.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds nothing beyond them: it does not say what happens if the window is minimized, absent, or ambiguous, and it does not state whether focus steals input or fails silently. For a side-effecting window action, that gap is meaningful.

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 short sentence with zero waste and the action is front-loaded. It borders on under-specification given what it omits, but nothing in it is redundant.

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

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

The tool is simple, has one parameter with full schema coverage, and has no output schema, so there is little that must be explained. Still, for an action with side effects on window state, the description should say more about failure modes and ordering relative to windows or click.

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 window parameter's accepted forms (title fragment, app name, or hwnd from windows) are already documented in the schema. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

The description states a concrete action on a specific resource using a verb and resource (切到前台 / window), which an agent can easily distinguish from siblings such as click, move, or windows. It does not explicitly differentiate itself from the sibling status, but its purpose is clear.

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

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

The description gives no guidance on when to use focus rather than windows or status, no prerequisites, and no exclusions. An agent must infer that this is the call used to activate a window before sending input to 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?

Annotations (readOnlyHint=false, destructiveHint=false) correctly signal a non-read, non-destructive action, and the description adds real behavioral context beyond them: the IME interception of character keys and the game-walking use of hold. It stops short of explaining which window receives the keystroke (focus dependency) or what the call returns, but the essential behavior is disclosed.

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

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

Front-loaded with the action and examples, then parameter meanings, then the sibling redirect — three tight sentences with no wasted wording. Every clause 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?

For a simple input-simulation tool with no output schema, the description covers purpose, all parameters, and the alternative tool, which is nearly everything needed. The one gap relative to the sibling set is not mentioning the `focus` dependency, i.e., that the target window must be focused first.

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 carry all parameter meaning, and it does: `keys` is a key or combination with examples, `hold` is seconds held down, `times` is repeat count. Units and intent are clear for all three; only edge cases (e.g., valid key names) are left implied.

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

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

States a specific verb and resource — press a key or key combination — with concrete examples ("ctrl+s", "esc", "w") and Mac variant. It explicitly distinguishes itself from the sibling `type` for text entry, so an agent can tell the two apart 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 explicit routing: character keys go through the input method, so use `type` for entering text. It also clarifies the purpose of `hold` (walking in games) and `times` (repeat count), telling the agent when those options apply rather than leaving it to guesswork.

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=false, destructive=false, openWorld=false, so the safety profile is covered. The description adds that relative mode rotates the in-game camera, which is meaningful state-changing context, but it omits whether motion is instant or animated, what coordinate space absolute x/y uses, and any dependency on prior 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?

Two short sentences with the core action front-loaded and the parameter caveat immediately after. No filler, though the brevity leaves gaps that are penalized in other dimensions rather than being 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 4-parameter input tool with no output schema and sparse schema descriptions, the description covers the trickiest case (relative movement for camera control) but should also specify the absolute coordinate frame and default behavior for `relative`. It is minimally sufficient but not complete.

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

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

Schema coverage is only 25% (only id documented), so the description must compensate. It does clarify the crucial x/y semantics in relative mode, but leaves absolute-mode coordinates undefined and does not state the default for `relative` or how id interacts with x/y when both are supplied.

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+resource ("移动鼠标" / move the mouse), which is unambiguous and clearly distinct from siblings like click, drag, and scroll. It does not explicitly name a sibling to contrast with, but the purpose is immediately clear.

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

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

It supplies one useful conditional use case: relative=true is for turning the game camera. However, it gives no guidance on when to move the cursor versus using click/drag directly, nor any prerequisites such as needing a target window in focus first.

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 readOnlyHint and openWorldHint; the description adds substantial behavior beyond that — toggles report on/off state, dropdowns report current value and expanded state, duplicate-named controls are tagged with their group, offscreen items appear without coordinates, and clicking by id auto-scrolls first. This is exactly the kind of semantics an agent needs before deciding to observe-then-click.

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 what the tool returns, then layers behavior details in a compact single paragraph with semicolon-separated clauses. Dense but every clause carries information; it would read better as a short bullet list given the number of distinct behaviors.

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

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

No output schema exists, so the description carries the burden of describing return content, and it does so well (fields, state attributes, coordinate presence/absence). Remaining gaps are `limit`/`region` semantics and ordering/pagination, which matter less for a zero-required-parameter read 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 40%, and the description compensates for `filter` by explaining its semantics (text filtering, multiple terms separated by `|`). However `limit` and `region` are documented in neither the schema nor the description, leaving two of five 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 verb and resource — reading out UI elements (name, type, center coordinates) in a window — and immediately distinguishes itself from the sibling `screenshot` with "不经过截图". An agent knows exactly what it gets back 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?

Gives concrete situational guidance: `source=auto` reads the UI tree first and falls back to OCR for games/self-drawn UIs, `popup=true` surfaces open menus, `offscreen=true` surfaces unscrolled items. It stops short of explicitly saying when to prefer `screenshot` or `find` instead, so the alternative-selection rule 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: all coordinates are defined against the non-zoom screenshot, so a zoomed capture must not be used for coordinate reference, and zoom is explicitly view-only for small text. That is exactly the kind of trap an agent would otherwise fall into.

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

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

Three short clauses, zero redundancy, with the most error-prone constraint (coordinate reference frame) front-loaded. Every sentence earns its place.

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

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

For a three-parameter, all-optional capture tool with no output schema, the description covers the risky semantics: coordinate frame, region behavior, and zoom's limited purpose. Only the default capture behavior when window is omitted is left to the schema, which handles 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 67%, with region and window already documented in the schema. The description compensates for the remaining gap by defining the coordinate reference frame (non-zoom screenshot), clarifying that region means partial capture, and pinning down zoom as original-resolution viewing only. This adds meaning well beyond the bare types.

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 concrete verb+resource ('截图' / screenshot) and immediately qualifies scope with 'region 截局部'. It is clear what the tool does, but it never contrasts itself with nearby state-reading siblings like observe, find, or check, so the agent must infer when a screenshot is the right call.

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 conditional guidance for the zoom and region parameters ('zoom=true 按原始分辨率截（只用来看清小字）'), which is real when-to-use advice at the parameter level. However, there is no statement about when this tool should be preferred over observe/windows/status, and no 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?

Annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral detail — that dy>0 means downward and the unit is grid cells — but says nothing about whether scrolling targets the page or a specific element, whether it is animated or how far a unit actually travels.

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

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

Two short sentences with the core meaning front-loaded and no filler. The terseness borders on under-specification for a five-parameter tool, but nothing written is wasted.

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

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

For a tool with five parameters, zero required fields, low schema coverage and no output schema, the description is far too thin. An agent still cannot tell whether x/y target an element or the viewport, what dx does, what the defaults are, or what the call returns.

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

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

Schema coverage is only 20% (only id is documented, as an alternative to x/y), so the description must carry the load. It clarifies dy's sign and unit but leaves x, y, dx, their defaults, and whether the unit applies to dx as well completely unexplained.

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

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

"滚轮" (scroll wheel) names a specific action, and the dy direction convention makes the intent unambiguous versus siblings like click, move, drag or key. It stops short of stating what is being scrolled (page vs. element under the cursor), so it is clear but not fully differentiated.

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 scroll versus observe/screenshot/find, nor any prerequisite such as needing a prior observe for the id parameter. The only usable hint is the sign convention for dy, which is direction semantics rather than when-to-use 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?

With readOnlyHint=true and openWorldHint=false already declaring the safety profile, the description's added value is the idle_seconds signal and the associated 'don't steal the mouse' policy, which is genuine behavioral context. It says nothing about cost, latency, or freshness of the reported values, so it is useful but not rich.

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 first lists the returned signals, the second front-loads the actionable constraint. No filler and no repetition of the tool name.

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

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

There is no output schema and no parameters, so the description carries the burden of explaining what comes back, which it largely does by enumerating the four fields and naming idle_seconds explicitly. It stops short of giving types or units (e.g. resolution format, idle_seconds granularity).

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 is 4; there is no parameter meaning for the description to carry. The prose does describe the conceptual outputs (idle_seconds, foreground window), which partially substitutes for the absent output schema.

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

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

The description names the resource (machine status) and enumerates the specific fields returned: resolution, coordinate system, foreground window, and idle_seconds. This lets an agent separate it from sibling state-readers such as screenshot, windows, focus, and observe, though the opening is a bare noun phrase rather than an explicit verb.

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

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

It gives an explicit when-to-use rule — check idle_seconds before acting — plus a concrete exclusion: don't take over the mouse while the user is actively using the computer. It doesn't name which sibling to call instead (e.g. observe or screenshot) when idle, so it falls short of full alternative routing.

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

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

The annotations state that the tool is non-readOnly and non-destructive, but the description adds the important behavior: it stops immediately and reports the step reached when find is uncertain or wait/check fails. It also states that a trailing observe returns the elements it read, and it documents how the pause parameter is applied after each mouse or keyboard action.

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 dense but efficient: the core behavior comes first, followed by the step format and an example, then the failure and return semantics. The op list refers back to sibling tools instead of repeating the tool names, which is a saving.

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 are only two parameters and no output schema, so the remaining burden is the step structure and the failure behavior. Both are covered. The main omission is the overall shape of the return value when the batch succeeds or fails early.

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 schema coverage is only 50%; the steps array is typed only as a generic object and has no schema description. The description compensates by defining each step's shape ({"op": <tool name>, ...that tool's params}) and by providing a concrete four-step example. It does not enumerate every valid op or its required 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 states a specific verb and resource: it executes a batch of operations in one call and deliberately avoids returning midway to ask. It is clearly distinguishable from the atomic siblings (click, type, find) because it batches 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 gives explicit usage guidance: "适合路径明确的多步操作", and it excludes screenshot from valid ops. However, it gives no guidance on when not to use it, for example when later steps depend on the result of an earlier one.

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 this is a non-read-only, non-destructive, non-open-world action, so the safety profile is covered. The description adds genuinely useful mechanism detail: two distinct input paths exist and the paste path goes through the system clipboard. It omits the consequence of that mechanism (clipboard contents are overwritten) and does not say where the text is delivered (currently focused control).

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 clauses, front-loaded with the primary action, and each clause maps to a real parameter. Nothing is wasted, though the terseness borders on telegraphic and a single added sentence about the focus requirement would cost 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?

For a simple three-parameter tool with annotations covering safety and no output schema, the essentials are mostly there. What an agent still cannot infer is the precondition (a focused input must exist) and the side effect of the clipboard mode, both of which matter for correct invocation in a GUI automation flow.

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 carries the burden, and it explains the semantics of `paste` and `enter` but leaves `text` undocumented (its format, length limits, or escaping behavior) and never states that both flags default to false. Two of three parameters gain meaning; the core required one does not.

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

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

The description states a specific action and resource: input text, with the added note that Chinese characters are supported. It does not distinguish this from the sibling tool `key`, which is the most likely point of confusion (typing a string vs. sending key combos), so differentiation is left to inference.

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 two clauses give conditional guidance on the optional flags (paste=true for clipboard path, enter=true to submit afterward), which implies when to pick each mode. However, there is no statement of prerequisites, e.g. that a target window must already be focused via `focus`, and no explicit when-not guidance versus `key`.

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=true and openWorldHint=false, so safety is covered. The description adds real behavioral context — polling loop, 10s default, 120s ceiling — but never says what happens on timeout (false result vs. error) or what the call returns, which matters for a blocking poll.

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 mechanism and its limits come first, the usage cue second. No filler, and the anti-pattern (repeated screenshots) is packed into the same clause rather than a separate sentence.

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 polling tool with no output schema and 43% coverage, the description leaves notable holes: return value on success vs. timeout, and the role of interval and threshold. The core loop and timeout bounds are covered, so it is adequate but not complete.

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

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

Schema coverage is only 43%, and the description compensates partially: it explains that 'question' is a yes/no predicate and supplies the default and maximum for 'timeout', which the schema leaves undocumented. However, 'interval' and 'threshold' get no meaning from either source, 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?

States a specific verb and mechanism: repeatedly inspect the screen until a yes/no question holds or a timeout fires. Defaults (10s, max 120s) are included, and the closing clause distinguishes it from the screenshot sibling by saying it replaces repeated screenshots.

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

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

Gives concrete usage conditions — waiting for loading, waiting for a popup — and implicitly routes the agent away from manual repeated screenshots. It does not name an explicit when-not case or name a sibling tool like observe or check, which keeps it short of a 5.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the visible-window scope and the exact fields returned in each entry, which matters since no output schema exists. It omits ordering and whether minimized/hidden windows are excluded, keeping it below a 5.

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

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

A single sentence with the action front-loaded and the return fields compactly parenthesized; every token earns its place and nothing is repeated from the schema.

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

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

For a trivial zero-parameter read tool with annotations and no output schema, listing the returned fields is exactly the context an agent needs. Minor gaps remain around result ordering and whether the list is filtered to normal windows, but nothing essential 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool applies, with no contradictory parameter language present.

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

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

The description gives a specific verb+resource ('list visible windows') and even enumerates the returned fields (title, process, position, foreground status), so an agent knows exactly what it gets. It does not explicitly distinguish itself from siblings such as 'focus', which operates on the same domain, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisite (e.g. that 'focus' requires a window target that this tool supplies), and no exclusions. The intended use case is only inferable from the enumeration semantics.

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