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

With no annotations, the description must carry behavioral disclosure, and it does cover ordering, coordinate space ('same screenshot-space rule'), and the return shape (one result line per action). It says nothing about the failure model, which is the critical unknown for a batch tool — whether a failing action aborts the remaining actions or the batch continues, and whether completed actions can be undone.

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 value proposition and the batching constraint, with no filler sentences; the inline example is load-bearing rather than decorative. The telegraphic phrasing and the bare pointer to a 'screenshot-space rule' defined elsewhere make it slightly harder to parse than it needs to be.

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 the return value, so omitting return detail is fine, but with no annotations and an opaque array parameter the description is the only safety and failure-model signal available — and it omits error/partial-failure behavior for a multi-action tool. Adequate to invoke, not complete enough to predict outcomes.

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% — the single `actions` parameter is an untyped array of free-form objects with no property documentation — so the description must compensate, and it does: it specifies the per-item shape ({"action": <member name>, "input": <args dict>}) and supplies a three-element example. It stops short of enumerating the admissible action names or stating that they are the sibling tool members.

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?

A specific verb and resource — run multiple actions in one call — plus the discriminating property ('milliseconds apart in ONE call') that separates it from the single-action siblings like computer_click and computer_key. It also states why such batching matters (timing-critical UI, menus that close on blur).

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 when-to-use condition is explicit: timing-critical sequences where per-action latency would break the interaction. What is missing is an explicit exclusion — it never says to prefer the individual tools for ordinary, non-timing-sensitive steps.

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 disclosure burden and does well: it makes clear this is a non-mutating single-display capture and discloses the valid index range. It omits what happens with an out-of-range index and what the capture returns, which are the remaining behavioral gaps.

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

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

Three short sentences, front-loaded with the core action and scope, then alternatives, then the discovery helper. Every sentence earns its place with no repetition of the title or 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?

For a one-parameter read-only capture tool with no output schema, the description covers purpose, scope, sibling routing, and value discovery adequately. Error behavior for an invalid monitor index is the only substantive omission.

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 the single 'monitor' parameter has no schema description, but the description compensates by defining it as a physical display index in the 1..N range and directing the agent to computer_display_overview to enumerate valid values. The only missing piece is explicit mention of the default of 1.

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 ('Screenshot ONE physical monitor') and explicitly bounds the scope to a single display in the 1..N range, contrasting it with computer_screenshot's whole virtual desktop. An agent can distinguish it from every sibling without opening a schema.

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

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

Names both the alternative it replaces (computer_screenshot for the full desktop) and the condition that selects this tool (multi-monitor zoom on one display), plus a pointer to computer_display_overview for discovering valid display indices. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does disclose a major behavioral trait: an outbound gate because a click can press Submit/Send/Delete, requiring a fresh CONSENT.txt. It also discloses that clicks:3 selects a line/paragraph, but says nothing about failure modes when no screenshot exists.

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 lines, front-loaded with the action and coordinate frame, then parameter meanings, then the gate. Every sentence carries information the agent needs; nothing is padded.

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

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

Given an output schema exists and the description needn't explain returns, this covers action, coordinate space, all four parameters, and the safety gate. The main residual gap is what happens when there is no prior screenshot or how the gate failure is surfaced.

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: x/y are defined as pixel coordinates in the last screenshot, button is enumerated as left|right|middle, and clicks 1/2/3 is given concrete meaning including the triple-click text-selection case. Defaults and required-ness are left to the schema.

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

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

States a specific verb+resource (click at x,y) and pins the coordinate reference frame to the LAST screenshot's pixel space, which separates it from drag/mouse_down_up style siblings. It doesn't name an alternative sibling explicitly, so it stops short of full sibling differentiation.

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

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

Usage is only implied: the coordinate frame tells the agent it must screenshot first, and the CONSENT gate hints at when the tool is blocked. There is no explicit guidance on when to choose click over computer_mouse_down_up, computer_drag, or computer_type for a given interaction.

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 the read edge case (empty string when clipboard is empty), which is genuinely useful. However, it never states that write silently overwrites existing clipboard contents, nor any permission, focus, or platform constraints for a system-level mutation.

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, front-loaded with the verb/resource and then the mode semantics. Every clause carries information; nothing is padded or repeated.

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 re-explained, and the description still usefully notes the empty-clipboard case. For a 2-parameter, unannotated mutation tool the essentials are covered, though the overwrite behavior of write is a meaningful omission.

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 largely does: it enumerates the allowed `action` values (read|write) that the schema types only as a bare string, and ties `text` to the write case. It stops short of saying `text` is ignored or required on write, or what happens if text is 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 pair and resource: 'Read or write the system clipboard'. The two modes are enumerated inline (action read|write), so an agent knows exactly the capability offered. No sibling tool in the list operates on the clipboard, so no differentiation burden applies.

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 what each mode does ('write copies `text`; read returns current clipboard content'), which implies when to pick each. It gives no explicit selection guidance against alternatives (e.g., using computer_type versus clipboard paste) and no preconditions such as requiring focus or a non-headless session.

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 is clear the call is a cheap state read with no arguments, and the 'SCREENSHOT coordinates' phrase usefully discloses the reference frame. It does not say whether the value is live versus relative to the last captured screenshot, nor that it 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 front-loaded sentence with no filler. Slightly terse in that the key qualifier 'SCREENSHOT coordinates' is not unpacked, but 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?

Output schema exists, so return values need no explanation, and with zero params the surface is small. However, a stateless tool whose output is a bare coordinate pair is most useful only in relation to a screenshot, and the description never establishes that coupling or the timing semantics.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the schema is empty.

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 cursor position) and the coordinate frame it is reported in (SCREENSHOT coordinates), which is the crucial distinguishing detail. It does not name or contrast any sibling, so an agent must infer that this pairs with computer_screenshot and computer_click.

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

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

No when-to-use guidance at all. Nothing says this must be called after computer_screenshot to map onto a click target, nor when to prefer this over computer_display_overview or computer_read_screen.

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

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

No annotations are provided, so the description must carry the behavioral load. 'List' implies a safe read-only operation and the return shape (index, left, top, width, height) is disclosed, but there is no explicit statement about permissions, whether display indices are stable across calls, or any side effects.

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

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

Two tight sentences, front-loaded with the purpose and then the usage rule. No filler or redundancy.

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

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

For a zero-parameter read tool with an output schema, the description covers what it does, what it returns, and how it fits into the sibling workflow. Nothing an agent needs in order to call it correctly 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, so the baseline is 4. There is nothing extra the description could meaningfully add on parameter semantics.

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 all physical monitors') plus the data returned (resolution and virtual-desktop position). An agent can immediately distinguish it from computer_capture_monitor, which captures pixels rather than enumerating displays.

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

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

Explicitly says to call this 'before computer_capture_monitor to pick the right display index', which names the sibling and the sequencing condition. It stops short of stating when not to use it, but for a zero-param enumeration tool that is a minor omission.

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

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

No annotations are provided, so the description carries the full behavioral burden for a stateful UI interaction. It discloses that this performs a drag from one coordinate to another and can move files, but it does not describe press/move/release semantics, timing, modifier keys, coordinate system, safety implications, or reversibility of file moves.

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

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

The description is a single front-loaded sentence with no filler. The coordinate mapping comes first and the use cases follow immediately, making it efficient and easy to scan.

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, 0% schema description coverage, and an output schema present, the description is too sparse for a UI action that can move files. It covers the core coordinate mapping but omits behavioral details such as interaction sequence, coordinate system, timing, and side-effect confirmation that an agent would need before invoking it confidently.

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

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

Schema description coverage is 0%, but the description compensates by explicitly mapping start_x/start_y as the drag origin and x/y as the destination. It still does not clarify coordinate units, screen origin, or whether coordinates are absolute or relative, leaving a meaningful semantic gap.

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

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

The description states a specific verb (Drag) and the exact resource shape (from start_x/start_y to x/y), plus concrete use cases like file moves, sliders, and selection. It is clearly distinguishable from most siblings, though it does not explicitly contrast with computer_mouse_down_up, which could also produce dragging behavior.

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 examples 'file moves, sliders, selection' imply when this tool is appropriate, giving the agent some contextual guidance. However, it does not state when to prefer this over computer_click, computer_mouse_down_up, or computer_batch, nor does it mention prerequisites or exclusions.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses matching semantics, what is returned on success or failure, and the effect on subsequent keyboard actions. It does not cover edge cases such as multiple matching windows or minimized windows, so it is strong but not exhaustive.

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

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

The description is front-loaded with the action, then the matching behavior, then the return value and keyboard consequence. Every sentence adds useful information with no repetition or 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?

Although an output schema exists, the description still clarifies the key return behavior by stating that the exact focused title or 'not found' is returned. For a one-parameter focus tool with no annotations, it provides sufficient context to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must define the single parameter, and it does: title_substring is matched against the window title with case-insensitive substring semantics. It also establishes scope by selecting the first visible top-level matching window.

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: bring the first visible top-level window whose title contains title_substring to the foreground. It is clearly distinct from the sibling tools such as click, type, and screenshot.

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 clear usage context by saying keyboard actions land in the focused window afterward, implying it should be used before keyboard input. It does not explicitly name alternatives or exclusions, but no sibling appears to provide competing focus behavior.

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 auto-release semantics (hold then release after the duration) and the single-key limitation, but says nothing about focus requirements, whether the call blocks for the duration, or what happens if the key is invalid.

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, both front-loaded with the core behavior and the key constraint. Nothing is wasted and the most important restriction is stated last for emphasis.

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 explained, and the tool has only two simple parameters. The description covers the essential behavior; only the key-name format and focus/blocking behavior for the hold are left unstated.

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

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

Schema description coverage is 0%, so the description must compensate — and it does: it specifies that duration is in seconds and that key accepts only a single key, not a '+'-joined combo. It still omits the expected key-name format (e.g. 'Shift' vs 'shift' vs keycode), which is the main remaining gap.

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

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

States a specific verb and resource ('Hold a key for duration seconds then release') with an example use case. The clause 'One chord only — no '+' combos' implicitly differentiates it from the sibling computer_key tool, though it never names that sibling directly.

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 Shift-for-drag-selection example gives a concrete scenario, and the no-combos note hints the agent should use a different tool for chords. However, no alternative tool is named and there is no explicit when-not guidance, leaving the agent to infer that computer_key handles combinations.

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 adds real behavioral context beyond the schema by warning that Enter/Return in a chat app SENDS and requires consent, which is exactly the kind of side-effect disclosure needed. It remains silent on prerequisites such as whether the target window must be focused first, or whether the key is a real OS-level event.

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?

Very short and front-loaded: the verb and format examples come first, with the safety caveat second. Minor waste from inconsistent quoting around the examples, but nothing extraneous.

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

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

An output schema exists, so return values needn't be explained. Still, for a low-level input-injection tool with no annotations and a 20-sibling family, the definition should cover focus requirements and how it differs from hold_key to be fully sufficient.

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

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

The single `key` parameter has 0% schema coverage, so the description must compensate. The examples do establish the accepted format — camel-case key names and "+"-joined modifier chords like "ctrl+c" — which is genuinely more than the bare `string` type. But the chord grammar (modifier ordering, how many modifiers, whether "Enter" vs "Return" both work) is left implicit.

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

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

States a specific verb ("Press") and resource (a key or chord) and gives concrete examples. It does not explicitly distinguish itself from nearby siblings like computer_hold_key or computer_type, though the name and examples make the intent largely inferable.

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

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

Usage is implied by the examples (single keys and modifier chords) and there is a useful caution about Enter sending a message in chat apps. However, no explicit guidance on when to prefer computer_hold_key (hold/repeat) or computer_type over this tool, so the agent must infer the boundaries.

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 that the left button state is held or released and that no cursor movement occurs, but it omits permission requirements, global input-state effects, and whether an unmatched 'up' is safe or a no-op.

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 constraint ('LEFT', 'without moving') front-loaded and no wasted wording. The use-case sentence is compact and directly relevant.

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 and has an output schema, so return values need not be explained. The description covers the essential input and the key non-movement constraint, but a note about pairing down/up and global input state would make it complete for a mutation-style input tool with no annotations.

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

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

The schema description coverage is 0%, so the description must compensate. It does so by naming the action values down|up, though the schema provides the default and type; the description does not elaborate on the behavioral difference between the two beyond their names.

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 on a specific resource: hold or release the LEFT mouse button, with the down|up values named. 'Without moving' clearly distinguishes it from computer_drag and computer_click semantics.

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 a concrete use case: press-drag-press-drag sequences that pyautogui cannot perform in one call. It implies when not to use it through 'without moving', but does not explicitly name computer_drag or computer_click as alternatives.

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

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

With no annotations, the description carries the full burden and does add real behavioral context: it reports the actual outcome across four states (opened / running-no-window / crashed / nothing-launched) and discloses an 8-second wait for a visible window. It stops short of covering idempotency (relaunching an already-open app) or elevation/admin requirements.

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 action and the outcome-reporting promise are front-loaded, then platform specifics and the timeout follow in short clauses. The emphasized 'REALLY' is rhetorical but does signal that the tool verifies rather than merely launching; overall there is little waste.

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

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

An output schema exists, so return shape need not be spelled out, and the description still names the outcome categories an agent will see. For a single-parameter tool with no annotations, this is nearly sufficient; the residual gap is failure/permission semantics and behavior when the target process already exists.

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

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

Schema coverage is 0%, so the description must compensate, and it does: the single `target` parameter is explained as an app name or full .exe path, with `start` semantics and two concrete example values. That is meaningful added meaning beyond the bare string type, though format edge cases (spaces in paths, arguments) are unaddressed.

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 (open) and resource (application) plus the accepted target forms (name or full .exe path). It is clearly distinguishable in practice from the screenshot/click/type siblings, but it never explicitly names or routes away from an alternative, keeping it just 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 by the verb and reinforced with platform guidance ('Windows: use `start` semantics') and concrete examples ('notepad' or 'chrome'). There is no statement of when not to use it, what to do if the app is already running, or which sibling to reach for instead, so guidance remains implicit.

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

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

With no annotations, the description carries the burden and does disclose a key side effect: passing target_title changes OS focus (brings a window to the foreground). It also gives the return shape '(x,y) text' and language coverage (Arabic + English). Missing: behavior when no window matches the title (error vs fallback to current screen) and any rate/latency characteristics.

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

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

Three dense sentences with the core action front-loaded and no filler. The 'FIRST' capitalisation and 'atomic focus+read' shorthand are terse but readable; a slightly fuller phrasing of the default case would cost 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?

Output schema exists, so return value explanation is optional though helpfully given. For a one-parameter tool the definition is nearly complete; the main missing piece is the no-match / no-target_title fallback behavior, which an agent needs to call it safely.

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 the single parameter is undocumented in the schema, so the description must compensate — it defines target_title as a substring match on window title, picks the first match, and acts before the read. Slight gap: the empty/default case (read whatever is currently focused) is only 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 ('OCR the screen'), which immediately distinguishes it from the sibling computer_screenshot (image capture) and from computer_focus_window (no read). An agent can pick it 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?

The 'atomic focus+read — the read cannot miss the target' clause implicitly steers the agent away from calling computer_focus_window then reading separately, which is a real usage rule. There is no explicit when-not guidance, e.g. what to do if multiple windows match or if no title matches.

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 scope limit (only the LAST actions, not the entire log), the exact finding categories, and that it returns findings plus a verdict. It does not state that it is a read-only/non-destructive operation or what actions.log is or where it comes from.

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

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

Three dense sentences with the core purpose front-loaded and the flag list compactly enumerated. Every sentence contributes, though the terse label-style phrasing ('Flags: ...') and unexplained terms like 'consent-gate' add slight reading friction.

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

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

An output schema exists, so the description need not detail return structure, and it still summarizes that findings + verdict are returned. With one optional parameter and no nested objects, the only real gap is the missing guidance on invocation timing and on the empty task_description default.

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 single parameter is undocumented in the schema (0% coverage), so the description must compensate. Saying the log is audited 'against the stated task_description' gives the parameter purpose, but it never explains the empty-string default or behavior when task_description is omitted or vague.

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: it audits the LAST actions in actions.log against a stated task_description, then enumerates exactly what it flags (external-effect actions, consent-gate bypasses, unrelated actions, error-results) and what it returns. This is clearly distinguishable from every sibling tool, all of which perform computer actions rather than reviewing 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?

Usage is only implied by the word 'Reviewer' and the reference to actions.log – an agent can infer this is a post-hoc audit, but the description never says when to call it, whether it should follow a completed task, or how it differs from the sibling computer_selfcheck. No exclusions or prerequisites 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?

With no annotations, the description carries the load and does disclose the key traits: it returns an image (not text) and that image's pixel space is the shared coordinate frame for all computer_* actions. It does not mention read-only/no-side-effect status, image size limits, or cost/latency, so a small gap remains.

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 tightly written sentences with zero filler; the action and scope come first and the coordinate-system contract follows. 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?

There is no output schema and no annotations, yet the description covers both the return form (an image) and how that return value is consumed (coordinate reference for the other tools). Nothing essential to calling it correctly 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, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly makes no attempt to invent parameter semantics.

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

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

States a concrete verb (Take a screenshot) plus the exact resource and scope (entire virtual screen, all monitors). The 'all monitors' qualifier implicitly separates it from the sibling computer_capture_monitor, so an agent can pick correctly without opening a schema.

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

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

Adds real usage context by explaining that the resulting pixel space defines the coordinate system for every computer_* tool, which tells an agent when this call is a prerequisite. It does not explicitly say when not to use it or name the single-monitor alternative, so it falls 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?

With no annotations, the description carries the full behavioral burden but only states mechanics. It does not disclose whether scrolling affects the focused window, whether coordinates are screen-relative, what side effects occur, or what constraints apply.

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

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

The description is front-loaded, compact, and contains no wasted text. It states the action first and then the key parameter semantics in a single efficient 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 simple coordinate-based scroll tool with an output schema, the essential call mechanics are present. However, with no annotations and no schema property descriptions, the missing coordinate frame and side-effect context leave meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaning to all four parameters: x/y as the scroll location, direction with explicit allowed values, and amount in wheel notches, though it omits the coordinate reference frame and defaults.

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, 'Scroll at (x, y)', and names the direction and amount semantics. It clearly identifies a scrolling operation, distinguishing it from click/type/drag siblings by verb, though it does not explicitly compare itself to alternatives.

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

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

There is no guidance on when to use scrolling versus other computer interaction tools, no prerequisites, and no exclusions. The usage is only implied by the tool name and action phrase.

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 disclosure burden and does the most important part: it makes clear this is a mutating operation that applies "automatic repairs" and returns a list of them, so the agent won't mistake it for a passive health check. It falls short of stating what the repairs change, whether they are reversible, or whether confirmation is needed.

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

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

Two short sentences, front-loaded with the action and followed by the check list, with zero filler. Every clause (including the enumeration of subsystems) earns its place by telling the caller what will be inspected.

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, and the description still summarizes the return shape (per-subsystem status + repairs applied), which is sufficient for calling it. The remaining gap is that a repairing, state-changing tool with no annotations should say something about the safety or scope of those repairs.

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; baseline 4 applies. The listed subsystem names are not parameters but they usefully preview what the call covers.

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

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

The description opens with a specific verb phrase ("verify all server subsystems and FIX what it can") and then enumerates the concrete checks (heavy imports, audit log writability, capture, OCR engine load, screenshot scale, outbound gate). No sibling tool performs self-diagnosis or repair, so an agent can distinguish it from computer_screenshot/computer_review immediately.

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?

"Self-heal" and "FIX what it can" imply it should be called when the computer subsystem is suspected of malfunctioning or throwing errors, but the description never states that condition explicitly, nor does it name an alternative (e.g. computer_review for read-only inspection) or say when not to call it. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does the most important part: it discloses that this is a stub, that the only real effect is recording the human's intent, and that it returns guidance text rather than performing playback. It stops short of saying whether that record persists, is scoped per session, or has any side effect on subsequent computer_* calls.

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

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

Three short sentences, front-loaded with the 'stub scaffold' caveat and the redirect to computer_batch, with no filler. Slightly dense parenthetical phrasing but every sentence carries information.

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

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

An output schema exists, so the returned guidance text needs no further explanation, and the stub status is clearly flagged. However, with no annotations and an undocumented 'instruction' parameter, an agent still cannot tell what to put in the argument or whether the call changes any persistent state.

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

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

Schema description coverage is 0% and the single required parameter, 'instruction', is never explained in the description — no guidance on whether it is a natural-language description of the demo, a step label, or free-form notes. For a 1-param tool this is the one place the description needed to compensate and it 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?

States a specific verb and object: it records that the HUMAN intends to demo an action for the agent to repeat, and it self-identifies as a 'stub scaffold' rather than a real recorder. It also names a sibling (computer_batch) that covers the real repeatable-sequence need today, so an agent can separate it from the click/type/key automation tools.

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

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

Explicitly gives the when ('the HUMAN wants to demo an action'), the when-not (full playback recording is not implemented yet), and the alternative ('use computer_batch scripts for repeatable sequences today'). Nothing about tool selection is left to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the clipboard-paste mechanism, the Arabic-safe intent, a hard consent-file gate with a 10-minute freshness window, and the risk that text lands in an app the user cannot see. It omits failure behavior (what happens when consent is stale) and whether the system clipboard is clobbered as a side effect.

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

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

Two short sentences, the operation and mechanism first, then the gate and the reason behind it. No filler and nothing important buried.

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

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

An output schema exists, so return values need no explanation, and the description covers the remaining essentials for a single-parameter input tool: mechanism, encoding caveat, consent prerequisite, and the blind-typing hazard. What an agent needs to call this correctly is present.

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

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

Schema coverage is 0% and the single parameter has no description in the schema, so the description must compensate. It does reasonably: 'text' is clearly the string to be typed, and the 'Arabic-safe' note signals that non-Latin/mixed-direction content is supported and passes through clipboard paste rather than simulated keystrokes.

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

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

States a specific verb ('type text') plus the target ('the focused control') and the mechanism ('via clipboard paste'), which implicitly separates it from sibling computer_key (keystroke-level input) and computer_clipboard (clipboard manipulation). An agent can tell what this does and roughly how it differs from the other input tools without opening any schema.

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

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

The description gives a concrete precondition ('requires fresh CONSENT.txt with an ALLOW line, <10 min old') and a rationale for caution, so the agent knows when it may call it. It does not explicitly route to alternatives (e.g. use computer_key for shortcuts/hotkeys, computer_clipboard + key combo for paste), which keeps it below 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?

With no annotations, the description carries the full burden and does disclose the key behavior: a pause of up to 10 seconds. However, it does not clarify whether the wait is blocking, how it behaves at the upper bound, or whether it can be interrupted, leaving some behavioral gaps for an operation with no annotation coverage.

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 definition is a single, front-loaded sentence with no wasted words, and the time limit and use cases are immediately visible.

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 wait tool with an output schema, the description is mostly complete: it states the action, maximum duration, and typical scenarios. Minor gaps remain around blocking behavior and parameter bounds, but nothing essential for correct invocation 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 schema has 0% description coverage and only documents type and default for the single optional "seconds" parameter. The description adds the important upper bound of 10 seconds, which is not in the schema, but it does not clarify minimum values, fractional seconds, or the default of 2.

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, "Pause," and scopes it to "up to 10s between actions," with examples of page loads and animations. It clearly distinguishes this timing tool from the action-oriented siblings such as computer_click and computer_type.

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

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

It gives clear context for use: between actions, specifically for page loads and animations. It does not explicitly state when not to use it or name alternatives, but the intended usage is easy to infer.

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 that coordinates remain in FULL-screenshot pixel space rather than crop space, but it does not clarify return behavior, whether a prior screenshot is required, or other operational constraints.

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, front-loaded with the purpose and followed by the critical coordinate-space constraint. There is no wasted wording.

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 no annotations, no output schema, and 0% schema description coverage, the description covers the key coordinate-space caveat but omits return behavior and any prerequisite about an existing screenshot. 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 description coverage is 0%, so the description must compensate. It provides important shared semantics for all coordinates by specifying FULL-screenshot pixel space, but it does not define x/y as an origin or explain width/height beyond the implicit region.

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, re-capturing a region at higher magnification, and states its intended use for reading small text. It is clearer than a generic screenshot tool, though it does not explicitly contrast itself with sibling tools like computer_screenshot.

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

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

The phrase 'for reading small text' implies when the tool is useful, but it does not state explicit when-not conditions or name alternatives such as using computer_screenshot first. Usage is implied rather than fully guided.

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