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

With no annotations, the description carries the full burden. It helpfully explains the returned `keys_go_to` semantics (the window under your pointer when you own the pointer) and the focus state, implying a safe read query, but it never explicitly states read-only behavior, whether it has side effects, or any conditions under which the values are unavailable.

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 delivers the purpose, the meaning of the key return field, and the action guidance with no filler. Every clause 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?

An output schema exists, so return values need not be spelled out, yet the description usefully characterizes the primary field. With zero parameters and a focused, single-condition use case, the definition is nearly complete; only explicit behavioral traits are left uncovered by the absence of 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?

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool is 4. No parameter meaning is missing.

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 resource (the active window) and clarifies two distinct facts it reports: where keystrokes go and which window the user has focused. It is distinguishable from a plain window enumerator like list_windows, though it never explicitly contrasts itself with that sibling.

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

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

"Check this before typing" gives a clear, actionable usage condition tied to the type_text/key/hold_key siblings. It stops short of naming alternatives (e.g., list_windows) or stating when not to use it, so it is context rather than full routing 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 no annotations, the description carries the full behavioral burden. It does disclose two useful traits beyond the schema: that count produces multi-click gestures and that modifiers are held during the click. It omits whether the cursor is moved to (x, y) first, whether the call blocks, and what screenshot_after actually does, so coverage is partial.

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

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

Two short sentences, front-loaded with the core action and coordinate requirement, and every clause adds information. Nothing is padded, though it is too terse to cover the remaining undocumented parameters.

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 annotations, so the description must stand alone for a 6-parameter mutation tool. It adequately covers the click gesture but leaves screenshot_after, the button enum semantics, and whether coordinates are screen- or window-relative undefined, which matters in a multi-window desktop environment.

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 6 parameters, so the description must compensate. It meaningfully clarifies count (2=double, 3=triple) and modifiers (held during the click, with example values), but leaves button, screenshot_after, and the coordinate reference frame entirely 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?

"Click at (x, y)" names a specific action and its coordinate-based scoping, which separates it from element-based clicking. However it never names click_element (the obvious alternative for semantic element targeting) or explains how it differs from mouse_down/mouse_up, so the sibling differentiation is implicit rather than stated.

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

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

The description explains parameter values (count for double/triple click, modifiers) but gives no guidance on when to choose this tool over click_element, drag, or the mouse_down/mouse_up pair. With 17 siblings in a desktop-automation family, the absence of any routing or prerequisite guidance is a real gap.

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

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

With no annotations, the description carries the full burden. It usefully discloses the fallback chain for method=auto (AT-SPI action first, otherwise a real mouse click at the element center), which is real behavioral value. However it says nothing about side effects, focus changes, failure behavior when the element is not actionable, or what screenshot_after does.

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, front-loaded sentences with no filler. The core action is stated first and the method semantics follow immediately.

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 action tool with no annotations and no output schema, the definition covers the core mechanism but omits failure modes, permission/accessibility requirements, and the meaning of screenshot_after, leaving gaps an agent would need to resolve by trial.

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 explains the 'auto' value of method but leaves 'action' and 'mouse' implicit, and never explains that 'id' is a ui_tree node id or what 'screenshot_after' does. Partial compensation only.

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 (activate) and resource (ui_tree element), and the parenthetical clarifies the mechanism. It does not explicitly contrast itself with the sibling 'click' tool, which operates on raw coordinates, so an agent must infer the distinction.

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 works on elements obtained from ui_tree but never states when to use it instead of 'click', 'set_text', or the mouse_* primitives. No prerequisites (e.g., 'id must come from ui_tree') or exclusions are given.

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

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

No annotations exist, so the description carries the full burden. It implies a read-only query by saying 'Current' and usefully discloses that coordinates are in the screenshot frame, but it does not state that it is side-effect-free or whether it requires a visible/active session.

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, correctly sized for a zero-argument query tool.

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 unnecessary, and there are no parameters to document. The description is nearly complete for this simplicity, only missing explicit read-only framing.

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

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

The tool takes zero parameters and the schema is empty, so the baseline of 4 applies. There is nothing further the description could add on this dimension.

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 resource (mouse pointer position) and the coordinate frame it is reported in. That distinguishes it from siblings like mouse_move and click, though it does not name them.

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

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

No when-to-use guidance is given. An agent must infer that this is a read-side companion to mouse_move/click for verifying pointer location; no alternatives or conditions are stated.

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

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

With no annotations, the description carries the full behavioral burden. It hints that motion is interpolated ('move smoothly'), which is a genuine trait, but omits button state semantics, coordinate system/origin, timing/duration, and what screenshot_after does. For a low-level input-synthesis tool this is a significant 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?

A single, front-loaded sentence with zero filler that directly conveys the action sequence. It is well-sized for a terse gesture primitive, though its brevity overlaps with under-specification rather than pure 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?

For a 6-parameter input tool with no annotations and no output schema, the description leaves too much unsaid: coordinate origin, units, button default behavior, and the side effect of screenshot_after. An agent lacks enough context to invoke it confidently without reasoning from sibling conventions.

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 there are 6 parameters. The phrase 'start'/'end' loosely maps to the start_x/start_y and end_x/end_y pairs, but the description never mentions the button enum or screenshot_after, nor explains coordinates are integer screen pixels. It only partially compensates for the coverage gap.

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

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

The description gives a specific verb sequence (press, move, release) that clearly defines a drag gesture on a resource (screen coordinates). An agent can tell it produces a drag rather than a click or a scroll, though it never explicitly distinguishes itself from the sibling composite tools mouse_down/mouse_up/mouse_move.

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 drag versus composing mouse_down + mouse_move + mouse_up, nor versus click. No prerequisites, no context for choosing among the many pointer siblings. Usage must be fully 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?

No annotations are provided, so the description carries the full burden. It discloses the max duration (10 seconds) and implies automatic release after the given seconds, but does not explain failure modes, interruption behavior, or required permissions.

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 that includes the key constraint (max 10 seconds) and a usage example without any wasted words.

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

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

Given no annotations, no output schema, and 0% schema coverage for three parameters, the description is incomplete. It omits any explanation of `screenshot_after` and does not clarify whether keys are released automatically or what happens if the hold is interrupted.

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 all three parameters. It clarifies `seconds` (with a max of 10) and implies `combo` means key(s), but never mentions `screenshot_after`, leaving one parameter completely 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?

States a specific action (hold key(s) down) and the duration parameter. Distinguishes from the sibling `key` implicitly by emphasizing holding rather than pressing, but does not explicitly name the alternative 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?

Provides example contexts ('for games or key repeat') which imply when to use it, but does not explicitly compare with the sibling `key` or state when not to use it.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does not say which window receives the keystroke, whether an app must be focused first, whether the call waits for the target to react, or what expect_window actually verifies — behavior is deferred to type_text's documentation rather than stated.

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

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

It is short and front-loads the core purpose before the example list, with no filler sentences. The example enumeration is long but each entry carries real formatting information, so it earns its space.

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

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

With no annotations, no output schema, and 0% schema coverage across four parameters, the description should explain repeat, screenshot_after, and the window-targeting precondition. It only partially covers combo and hand-waves expect_window, so an agent cannot call this confidently in all cases.

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 all four parameters need the description's help. The description usefully documents the combo format with examples and mentions expect_window (though it outsources its meaning), but says nothing about 'repeat' or 'screenshot_after', leaving half the parameters 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?

The description gives a specific verb+resource ('Press a key or chord') and concrete examples ('ctrl+c', 'alt+F4', 'super') plus the accepted keysym format, which clearly delineates it from type_text and hold_key. It stops short of naming those siblings explicitly, so an agent must infer the boundary 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?

There is no explicit when-to-use guidance against siblings like type_text (for strings) or hold_key (for press-and-hold). The only routing signal is the implicit contrast between 'press a key' and typing text, plus a cross-reference that 'expect_window works as in type_text', which is a weak proxy for real guidance.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the returned fields (app, title, active/visible, box), which tells the agent what each window entry contains, but says nothing about ordering, filtering, permissions, or whether the list can be empty.

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

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

A single compact clause with the resource front-loaded and the returned fields enumerated compactly. It is telegraphic but wastes no words.

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

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

For a zero-parameter read-only listing tool with an output schema present, the description covers what is needed. The output schema handles the return structure, and the description adds the AT-SPI scope and a field preview, leaving only minor gaps like ordering.

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 to document beyond what the schema already covers; the baseline for a parameterless tool is 4.

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 (list) and resource (top-level windows) plus the scope 'known to AT-SPI'. It implicitly distinguishes itself from the sibling active_window by returning all top-level windows rather than the focused one, but never names that alternative explicitly.

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

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

There is no explicit guidance on when to use this tool versus alternatives like active_window, ui_tree, or screen_info. The usage is only implied by the name and the word 'Top-level'.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior (button stays held) but omits the key operational fact that a matching mouse_up is required to release, plus any error/state behavior if invoked repeatedly. Adequate for a simple primitive 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?

One front-loaded sentence with no filler; the action and the positional constraint are both stated immediately.

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 the input schema covers the button enum, so little is missing structurally. However, with no annotations and no mention of the required mouse_up pairing, the description under-specifies the lifecycle of the held button.

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?

One parameter ('button') with an enum and a default, and the description never mentions which button is pressed. The enum values and default are self-describing in the schema, so the description adds no meaning beyond it. Baseline 3 for an essentially self-documenting single parameter.

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

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

Clear verb+resource: 'Press and hold a mouse button' with the scope qualifier 'at the current pointer position.' An agent can distinguish it from click (instant press+release) and mouse_up (the release half). It does not explicitly name or route against siblings, but the semantics are unambiguous.

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

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

Usage is only implied: 'press and hold' hints that this is the opening half of a drag/selection sequence paired with mouse_up, and 'at the current pointer position' implies the cursor must already be placed (e.g., via mouse_move). No alternatives (click, drag) or when-not conditions are stated.

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

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

With no annotations, the description carries full behavioral burden but only adds 'without clicking' and a motivation. It omits the coordinate space (screen vs. window), whether motion is instant or animated, and any side effects. The screenshot_after parameter's behavior is not disclosed at all.

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

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

A single tight sentence that front-loads the action and destination and folds the usage example into the end. Zero wasted words.

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 pointer tool with no output schema, the definition is minimally adequate, but the unexplained coordinate space and the entirely undocumented screenshot_after flag leave an agent guessing at correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only restates 'to (x, y)' with no units or coordinate-space meaning. The third parameter, screenshot_after, is never mentioned, leaving a third of the parameters undocumented in both schema and description.

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

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

States a specific verb ('Move') and resource ('the pointer') with the destination coordinates, and the phrase 'without clicking' cleanly distinguishes it from the click sibling. It is clear enough to select against most siblings, though it does not explicitly contrast with drag or mouse_down/mouse_up.

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

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

The parenthetical '(e.g. to reveal hover menus)' implies a use case for hover-style interaction but is not an explicit when-to-use rule. No alternatives are named and there are no exclusions or prerequisites, leaving the agent to infer the context.

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

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

With no annotations, the description carries the full behavioral burden, but it only restates the operation. It does not disclose state requirements (e.g., whether a button must already be held), what happens if no button is down, or what screenshot_after actually captures. This is thin for a stateful 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?

One short, front-loaded sentence with zero filler and the core operation stated first. The terseness borders on under-specification rather than being genuinely economical, but structurally it is clean.

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

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

For a simple two-parameter tool with no output schema, the description is still missing the pieces an agent needs: the relationship to mouse_down, and the meaning of screenshot_after. Since the schema itself documents nothing, the definition leaves the caller guessing.

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 two parameters, so the description must compensate and does not. The button enum (left/right/middle/back/forward, default left) and the screenshot_after flag are entirely undocumented in prose; screenshot_after in particular is not self-evident about timing or scope.

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

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

The description gives a specific verb and resource ("Release a mouse button"), so an agent understands the operation immediately and can distinguish it from unrelated siblings like screenshot or type_text. However, it does nothing to differentiate itself from its nearest sibling, mouse_down, which is the operation agents will most often confuse it 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?

There is no guidance on when to use this versus alternatives. In particular, the paired sibling mouse_down exists and the natural usage pattern (a mouse_down must precede a mouse_up) is never stated, nor is any context about drag versus click workflows.

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 burden, but it is inherently a non-mutating info query and the text discloses the returned dimensions including the real-vs-screenshot-space distinction, which is genuinely useful. It stops short of stating that it takes no arguments or is side-effect free.

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

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

A single tight sentence with no filler, and the most important item (screen size in both spaces) is front-loaded. It could be marginally clearer about what 'scale' means, but it wastes nothing.

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 need not enumerate return fields, and it sensibly summarizes them. For a zero-argument info tool this is close to complete; only the relationship to cursor_position is left unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly focuses on the return payload instead.

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 exact data the tool returns — screen size in both real and screenshot coordinate spaces, scale, and pointer position — so the agent knows this is a read-only environment-info query. It is clear but does not distinguish itself from the sibling cursor_position, which overlaps with the 'pointer position' 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 when-to-use guidance and no mention of the cursor_position sibling, which appears to expose overlapping information. The agent must infer that this is the tool to call before converting between screenshot and real 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?

With no annotations, the description carries the full burden. It does disclose one important behavioral gotcha — that zoomed coordinates still map to full-screen coordinates for subsequent actions — which is real value beyond the schema. But it says nothing about the returned artifact (image format, resolution, how the agent consumes it), leaving a meaningful gap for an unannotated tool.

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

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

Two compact sentences with the core action front-loaded and the coordinate caveat placed where it matters. Efficient, though the second clause is slightly run-on and could be split for clarity.

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

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

No output schema and no annotations mean the description is the only source of truth, and it omits any description of the return value or default full-screen behavior. Parameter semantics and the coordinate caveat are covered, but the definition is not fully self-sufficient for an agent deciding how to consume 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?

Schema description coverage is 0%, so the description must compensate, and it does name all four params, labels them as screenshot coordinates, and explains their combined effect (region zoom). It stops short of stating units or that the four should be supplied together, so not a full 5.

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?

"Capture the screen" is a specific verb+resource that an agent can immediately match to a screenshot operation. It does not explicitly differentiate from siblings like ui_tree or screen_info, which also expose screen state, so it falls short of a 5.

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

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

It gives an implied use case for the optional region args ("zoom into a region for reading small text"), which is genuinely useful. However it never states when to prefer this over ui_tree/screen_info or that the no-arg form is the default whole-screen capture, so usage remains inferential.

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 says nothing about focus requirements, whether scrolling is instant or animated, what happens at scroll boundaries, or that modifiers (e.g., ctrl) change zoom rather than scroll. Only the meaning of 'amount' 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?

Two short sentences with no filler, and the action is front-loaded before the parameter note. The brevity is efficient, though it shades into under-specification rather than ideal 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?

For a 6-parameter, annotation-free, output-schema-free tool, the description covers only one of six parameters and no behavioral context. An agent cannot reliably know what modifiers or screenshot_after do, or what the side effects of scrolling are.

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 6 parameters, and the description only clarifies 'amount = number of wheel clicks'. The x/y coordinate semantics, the direction enum values, the modifiers array contents, and screenshot_after are all undocumented in both schema and description.

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

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

States a specific verb and resource ('Scroll the wheel') plus the coordinate anchor, which is enough to distinguish it from click, drag, and mouse_move siblings. It does not explicitly name those siblings or contrast its role with them, 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?

No guidance on when to use coordinate-based scrolling versus ui_tree, click_element, or set_text, nor when to prefer key (e.g., Page Down) instead. The agent must infer the context entirely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the fallback strategy (focus, select-all, typing) which implies existing content is overwritten, but it omits return behavior, error cases when the element isn't editable at all, and side effects like focus stealing.

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 with the primary action front-loaded and the fallback detail second. No wasted words, though the fallback clause is slightly run-on.

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 mutation tool with no annotations, no output schema, and 0% parameter coverage leaves meaningful gaps: 'screenshot_after' is unexplained and return/error behavior is unstated. The description covers the core action but not enough for an agent to call it confidently in all cases.

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 three parameters. The description only obliquely covers 'id' (the ui_tree element) and 'text' (the contents), and says nothing at all about 'screenshot_after', which is entirely 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?

States a specific verb and resource: 'Replace the contents of an editable ui_tree element.' The verb 'replace' (versus the sibling type_text's append/type behavior) gives the agent a usable distinction, though no sibling is named explicitly.

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

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

It implies usage by targeting 'an editable ui_tree element' and describes a fallback path, but it never states when to choose this over type_text, click_element, or key, nor any prerequisite such as the element first being located via ui_tree.

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, so the description carries the full burden. It discloses meaningful behavior: Unicode support, that newlines press Return, and that a mismatched expect_window results in no typing at all. It omits prerequisites such as focus requirements, accessibility permissions, and typing speed/delay 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 tight sentences, front-loaded with the core action, then edge-case behavior. Every sentence adds information 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?

For a simple input tool with no output schema, the description covers the main action, Unicode handling, newline semantics, and the guard parameter's failure mode. The undocumented screenshot_after parameter is the notable remaining 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 coverage is 0%, so the description must compensate. It explains expect_window in detail (substring match against title or class, with failure mode) and implies text semantics (Unicode, newlines), but the third parameter screenshot_after is never mentioned anywhere.

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

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

States a specific verb+resource ('Type text into the focused widget') and adds scope detail (Unicode, newline handling). It does not differentiate itself from the sibling set_text or key, which an agent must choose between, so it stops short of a 5.

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

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

Usage is implied through 'focused widget' and the expect_window guard, but there is no explicit statement of when to prefer this over set_text or key. The conditional 'nothing is typed' clause hints at a safety use case without naming 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 full burden and does well: it discloses the id lifecycle ('Ids are valid until the next ui_tree call'), the coordinate space, and the accessibility prerequisite that silently hides apps. It does not state that this is a non-mutating read, but the list semantics make that reasonably clear.

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

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

Front-loads the output format, then filters, then the id lifecycle and the accessibility caveat. Four dense sentences, no filler, and the most decision-relevant facts come first.

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 further explanation, and the id-invalidation warning is valuable. However, for a 5-parameter tool with zero schema descriptions and zero annotations, the unexplained only_interactive default and max_depth leave real gaps an agent would hit when widgets it expects are missing.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It explains app/window substring filtering and active_window_only, but says nothing about max_depth or only_interactive, whose default of true materially changes results (non-interactive widgets are silently omitted).

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

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

States a specific verb and resource (list visible widgets) and even pins down the exact output shape `[id] role "name" @(x,y)` in screenshot space. It is clearly distinguishable in substance from siblings like screenshot or list_windows, though it never names an alternative to route between 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?

Offers concrete usage mechanics (filter by app/window substring, or active_window_only=True) and a prerequisite (accessibility must be enabled, with the Chrome/Electron flag), but gives no explicit when-to-use-vs-screenshot/list_windows guidance or when-not-to-use condition.

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 30s cap and the default screenshot return. However it omits what happens on timeout (error, partial capture, or silent return) and whether waiting beyond 30s is clamped or rejected.

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 duration cap and default return front-loaded. Every clause carries information and nothing is wasted.

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

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

Adequate for a simple zero-required-param tool, but with no output schema, no annotations, and 0% schema coverage, the description should have covered the 'seconds' cap semantics and the timeout outcome. It leaves the agent guessing about edge cases.

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% and neither parameter is named, but the description maps to both: 'max 30s' constrains 'seconds' and 'by default return a screenshot' explains the 'screenshot_after' default of true. It conveys intent but no units, clamping behavior, or how to suppress the screenshot.

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 (wait) and target (the UI) plus the two key behaviors: a 30s ceiling and screenshot-by-default. It is clearly distinguishable from the sibling 'screenshot', though the relationship between 'wait' and 'screenshot_after' is only implied.

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 wait versus calling 'screenshot' directly, and no mention of typical placement (e.g., after click/type_text to let the UI settle). The default-return note hints at an alternative but never names a condition for choosing it.

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