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

With no annotations, the description carries the whole burden and does substantial work: it blocks, it kills the command and everything it started after `timeout` seconds (capped at 300), stdin is empty, and its environment is isolated from the user's. What it leaves undisclosed is how non-zero exit codes and stderr are surfaced, and what happens to the output if it is large — meaningful gaps for a mutation-capable shell tool, but the core runtime contract is clearly 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?

Front-loaded with the verb and the environment boundary, then the scoping rules, then the alternative tool — a sensible order with little waste. The xclip/xdotool and 'stdin is empty' details all earn their place; the only slight cost is the fragmented line structure, which is stylistic rather than redundant.

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

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

An output schema exists, so return formatting need not be spelled out, and the description covers the behaviors that schema cannot: blocking, kill semantics/timeout cap, empty stdin, and environment isolation. The omissions (cwd default, error/exit-code behavior) are real but secondary for a tool this well-framed.

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 three parameters have only bare titles — and the description adds real meaning only for `timeout` (max 300, process-tree kill). `command` is self-evident, but `cwd` is never explained (default value or relative-path base), which is exactly the parameter that most needs prose given the schema provides nothing.

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

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

The description names a specific action and resource (run a shell command) and defines the exact execution environment ('inside the agent desktop's environment', 'sees the agent desktop's display and D-Bus, not the user's'), which cleanly separates it from GUI siblings. The explicit pointer that `launch` exists for GUI apps further disambiguates it from the rest of the sibling list.

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

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

It names concrete in-scope uses (xclip/xdotool, reading app logs, files under $HOME) and an explicit out-of-scope case with a named alternative: 'Use `launch` for GUI apps and anything long-running.' The exclusion is tied to a stated condition (blocking wait plus kill semantics), so an agent can decide without 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?

No annotations are provided, so the description carries full behavioral burden. It explains click counting but does not disclose side effects such as focus changes, whether clicks are OS-level, button behavior beyond the schema enum, or any permissions/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?

The description is one compact sentence that front-loads the primary action and then adds the important count behavior. Every clause adds useful 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?

An output schema exists, so return-value explanation is unnecessary. However, with no annotations and no schema parameter descriptions, the description omits meaningful context about button behavior, click side effects, and when this tool is preferable to related input tools.

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

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

Schema description coverage is 0% for four parameters, so the description must compensate. It helpfully explains that x/y are optional and default to the current pointer position, and it explains count semantics, but it does not describe the button parameter or its default.

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 (click) and resource/location (coordinates or current pointer position), and clarifies that count=2/3 produces double/triple clicks. It is clear what the tool does, though it does not distinguish itself from siblings like mouse_move or drag.

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

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

There is no explicit guidance on when to use click versus mouse_move, drag, or other interaction tools. The only usage-like information is the pointer-position fallback and click-count behavior, which is useful but not 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 at all, the description carries the full burden. It does add real behavioral insight — that this is a polite request and the app may present a confirmation prompt — which is more than the schema says. However, it omits whether the call blocks until the window is gone, what happens if the app refuses, and whether unsaved data could be lost, all of which matter for a destructive-feeling operation.

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

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

Two short sentences, zero filler, with the core action and its most important caveat (possible confirmation prompt) front-loaded. Nothing could be cut without losing meaning.

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 action itself is simple. Still, for a close operation the agent needs to know about the confirmation prompt's implications (does the call return before confirmation?) and the undocumented window_id, both gaps that keep this at merely adequate.

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 window_id has 0% schema description coverage, and the description says nothing about it — not where to obtain a valid id (presumably list_windows) nor what happens with an invalid or already-closed window. With a one-parameter tool the description had an easy opportunity to compensate and did not.

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

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

The description names a specific verb (close) and resource (window) and clarifies the mechanism — equivalent to pressing the window's close button. It reads clearly against siblings like list_windows or focus_window, though it doesn't distinguish itself from window_action, which could plausibly also close windows.

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: an agent should reach for this when it wants to dismiss a window. There is no explicit when-not guidance and no mention of window_action as an alternative, so the agent must infer which sibling to pick.

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 disclosure burden, yet it says nothing about whether a refresh or active connection is required, latency, or whether it is a passive read. The legend alias "* = shown, (n) = window count" is the only useful added detail, and it is marginal.

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 one short sentence and front-loads the data fields, but the compression comes at the cost of ambiguity: "how the user can watch" is unclear, and the parenthetical legend interrupts the field list. Brevity here is under-specification, not efficiency.

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 there are no parameters, so the agent's informational needs are modest and the field list roughly maps what is returned. However, the unclear "how the user can watch" clause and the absence of any usage or read-safety context leave it only minimally adequate.

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?

There are no parameters, so the baseline is 4, and nothing in the description is needed to clarify inputs. The schema is empty, so there is no ambiguity for the agent to resolve.

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

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

It's a noun-phrase list of the data fields returned (screen size, workspaces, focused window), giving an agent a reasonable guess that this reads desktop state. But it lacks a verb and any explicit statement like "returns the current desktop layout," and the final clause "how the user can watch" is too cryptic to tell which sibling it differs from.

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 about when to call this versus list_windows, view_workspace, or screenshot is given. The description only enumerates data fields and never states a use condition or exclusion.

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. It discloses the press-move-release sequence and that movement happens 'in steps,' which is useful beyond a bare name. However it omits which mouse button is held (the button parameter and its default), timing/step semantics, and any side effects of the drag.

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. It is efficiently sized, though the compactness contributes to the missing detail rather than balancing it.

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

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

For a 5-parameter GUI automation tool with no annotations and 0% schema description coverage, the description is too thin. It leaves the button parameter, coordinate system, and step behavior unexplained. The output schema covers return values, so that is not a gap.

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

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

Schema description coverage is 0%, so titles like 'X1' and 'Y1' provide no meaning. The description successfully maps x1/y1 to the press point and x2/y2 to the release point, adding real semantics. It ignores the button parameter entirely and does not specify the coordinate origin (screen vs. 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?

States a specific action sequence (press at x1,y1, move to x2,y2, release), which is clearly a drag and distinct from siblings click and mouse_move. It does not name or contrast with those alternatives, but the mechanics make the purpose 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?

No guidance on when to use drag versus click, mouse_move, or window_action. The agent must infer from the name alone that this is for drag-and-drop rather than simple movement.

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 behavioral burden. It usefully discloses that focusing may switch to the window's workspace and unminimize it, which are important side effects beyond the schema. It does not state failure behavior or what happens if the window_id 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?

It is a single front-loaded sentence with a concise parenthetical. Every part adds relevant information, and there is no wasted text.

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

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

The operation is simple, an output schema exists, and the description covers the main action plus key side effects. The main remaining gap is that it does not tell the agent where to obtain a valid window_id.

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?

There is one required parameter, window_id, with 0% schema description coverage. The description refers to 'a window' but does not explain the ID format, source, or validity requirements, so it does not compensate for the missing schema documentation.

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: 'Focus and raise a window.' The parenthetical further clarifies the effect, but it does not explicitly differentiate the tool from sibling window-management tools such as window_action or move_resize_window.

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 action name: use this when you need to focus or raise a window. However, it gives no explicit when-to-use guidance, no exclusions, and no named alternatives among the many sibling window tools.

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 to lean on, the description carries real weight: it discloses that the view switches to `workspace` before launching, that it blocks up to `wait_for_window` seconds (capped at 60), and that it focuses and reports the resulting window. It omits what happens on timeout or when no window appears, and does not characterize the arbitrary-command execution 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?

Three short sentences, front-loaded with the verb and examples, then the window/workspace behavior. Little waste, though the parenthetical max-60 note is slightly buried in the middle 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?

Output schema exists so return values needn't be explained, but for a 4-parameter process-launching tool with zero annotations, gaps remain: `cwd` semantics, timeout behavior, and whether the launched process is detached or blocks the session are all 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?

Schema coverage is 0%, so the description must compensate. It adds genuine meaning for `workspace` (the view switches there first, otherwise current) and `wait_for_window` (seconds, max 60, window is focused and reported), but `cwd` is never mentioned and `command` is only illustrated by examples rather than defined.

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?

Specific verb and resource: 'Run a shell command on the agent desktop', reinforced with two concrete examples ('xterm', 'firefox --new-instance'). It is not differentiated from the sibling `bash`, which is the obvious competing choice for running a command; the agent is left to guess why one exists over the other.

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 and the window/focus behavior imply this is for launching GUI applications on the remote desktop rather than generic scripting, but that is inference. There is no explicit statement of when to prefer this over `bash`, nor when not to use it (e.g. non-GUI or long-running commands).

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 must carry the full load. It discloses ordering (topmost-first), the significance of the returned ids, and the semantics of the frame/content geometry fields in screen pixels — real behavioral value. It says nothing about whether the list is empty or truncated in large desktops, or about permissions, which is a 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?

Two short paragraphs; the scope and ordering come first, then the geometry glossary. The fragmentary first sentence (no verb) is slightly awkward, but 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?

An output schema exists, so return values needn't be explained, yet the description still supplies the frame/content distinction and pixel units that make the results interpretable. What remains missing — workspace numbering and empty-list behavior — is minor for a one-parameter, read-only list tool.

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

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

The single workspace parameter has 0% schema description coverage, so the description must compensate. Its parenthetical "(or those on one workspace)" does clarify that the parameter filters the list, but it never explains what workspace identifiers mean or that null means all workspaces.

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 the resource (all windows, or those on one workspace), the ordering (topmost first), and the key output value (ids for the window tools). It lacks an explicit verb like "list", but the scope is specific enough to separate it from siblings such as view_workspace or desktop_info.

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 value of this call as a prerequisite for the window tools is only implied by "with ids for the window tools"; there is no explicit guidance to call it before focus_window, move_resize_window or close_window, and no sibling alternatives are named or ruled out.

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 disclose behavior. It says the pointer is moved but omits coordinate origin, whether the move is instantaneous, whether it affects focus/hover, and whether any buttons are pressed, though 'move' implies no click.

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

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

A single front-loaded sentence with no wasted words; it states action and target 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 simple two-parameter move tool with an output schema, the description covers the core action and coordinate space. However, with no annotations and no schema descriptions, it leaves origin/bounds and interaction side effects unspecified.

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 both params are required, but the description adds that x/y are screen pixel coordinates, which is meaningful beyond the bare integer schema. It still does not define origin, bounds, or per-axis 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 ('Move'), resource ('agent's pointer'), and target ('screen pixel (x, y)'), so the action is unambiguous. It does not explicitly contrast with click/drag/scroll siblings, so it falls short of the strongest 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?

No when-to-use guidance or alternatives are given; it doesn't say to use this before click/drag or when not to use it. The usage is only inferable from the verb.

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. It usefully discloses that apps with size steps or limits may end up smaller and that the result reports actual geometry. However, it does not cover permissions, failure modes, or whether the move is screen-absolute or workspace-relative, leaving significant gaps for a mutation 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?

The description is two focused sentences with no wasted wording. The core operation is front-loaded, and the caveat about size steps and actual geometry is relevant and brief.

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

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

An output schema exists, so the description need not explain return values, and it appropriately notes that the result reports actual geometry. However, for a mutation tool with five required parameters, no annotations, and no schema descriptions, it should say more about coordinate semantics, window_id expectations, and failure behavior.

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 five parameters. It meaningfully clarifies that x/y place the outer frame and that width/height refer to outer size including title bar and borders, which is important information beyond the bare schema. It still leaves window_id undocumented and does not specify the coordinate origin or units, so compensation is only partial.

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: place a window's frame at (x, y) with an outer size. It also clarifies that the frame includes title bar and borders, which distinguishes this from a generic position change. It does not explicitly differentiate itself from siblings like window_action or tile_windows, 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?

The description explains what the tool does but gives no guidance on when to use it versus alternatives such as window_action or tile_windows. It also omits prerequisites like whether the window must exist or whether coordinates are relative to the whole desktop or a workspace.

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 the focused window is the default target and that the view remains unchanged, but it omits failure conditions, workspace validity requirements, and any other 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 short sentences are front-loaded with the main action, and the key scoping detail about the view follows immediately. There is no wasted text.

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

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

The tool is simple, has only two parameters, and includes an output schema, so return-value explanation is unnecessary. However, the description leaves workspace semantics and window_id null behavior unclear, which matters given zero schema description coverage.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It partially explains window_id by saying the focused window is the default, but it does not clarify whether workspace is an index, ID, or existing workspace, nor does it explain null handling for window_id.

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: moving a window to another workspace. It also clarifies that the view stays put, which distinguishes it from a workspace-switching operation, though it does not explicitly name sibling tools such as view_workspace or move_resize_window.

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

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

The description implies when to use the tool: to relocate a window to another workspace without changing the current view. It also notes the default focused-window behavior, but it does not state exclusions or explicitly compare against alternatives like view_workspace.

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 explains the input format and X keysym naming, but does not disclose whether keystrokes go to the focused window, how repeat behaves, or what side effects/errors to expect.

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 useful examples and no wasted text. The essential invocation format is 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?

The tool is simple and has an output schema, so return values need not be described. However, with no annotations, the description should at least mention focus targeting and repeat semantics to be fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains the 'keys' parameter well with format and keysym examples, but it never mentions the 'repeat' parameter, leaving one of two parameters undocumented.

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

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

States a specific verb and resource ('Press key combos') and explains that keys are space-separated and X keysyms. It is clear enough to distinguish from a generic text-typing tool, though it does not explicitly name or contrast with the sibling type_text.

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 format examples and key syntax, but no guidance on when to use this versus alternatives such as type_text. It does not state prerequisites like window focus or 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?

With no annotations, the description carries the full burden and does disclose the critical behavior: everything running on the desktop is killed before a fresh one starts, which signals loss of unsaved app state. It does not cover whether the call blocks until the new desktop is ready, how long it takes, or whether session/auth state survives.

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

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

One sentence, zero waste, with the destructive action front-loaded ahead of the outcome. 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?

The tool is simple and parameterless, an output schema exists so return values need no explanation, and the main risk (all apps killed) is stated. What is missing is timing/synchronicity and whether the call returns before the new desktop is usable — relevant for an agent that must wait afterward.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to explain. Baseline of 4 applies.

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

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

A specific verb pair (kill ... then start) plus the resource (the agent desktop) and its blast radius (every app on it). An agent immediately knows this is a full teardown-and-relaunch, distinct from siblings like launch or close_window. It stops short of naming an alternative for a non-destructive start, so not a 5.

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

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

There is no explicit when-to-use or when-not guidance, no prerequisite conditions, and no pointer to launch/close_window as safer alternatives. The destructive framing hints at a recovery/reset scenario, but that is left entirely 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 does real work: it discloses that workspace capture switches the view there and back (a side effect on agent state), that hidden workspaces have no pixels until shown, and that returned click coordinates are always full-scale regardless of scale. Missing only the return payload shape and any latency/rate considerations.

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 region semantics before the token-saving tip and the workspace caveat. Nothing is redundant or padding.

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

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

For an 8-parameter, annotation-free tool with no output schema, the description covers the behavioral quirks well but leaves the format and cursor parameters plus the return value entirely unexplained. Adequate but with clear gaps an agent would hit on first use.

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 partially does: it defines the x/y/width/height tuple, explains `scale` semantics and its interaction with click coordinates, and explains `workspace`. But `format` (png/jpeg) and `show_cursor` (default false) are never mentioned, leaving 2 of 8 parameters undocumented 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 and resource: 'Capture the agent desktop, or a region of it', with the region parameterized. An agent can distinguish it from mouse/click/window tools, though the boundary with the sibling `view_workspace` is not explicitly addressed even though `workspace` capture here overlaps conceptually.

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

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

Gives actionable guidance on two conditions: use scale < 1 to save tokens, and use `workspace` to capture another workspace. However it never states when to prefer this over siblings like `view_workspace`, `zoom`, or `desktop_info`, nor any exclusion cases, so usage is implied rather than spelled out.

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 usefully discloses unit and sign conventions (negative down = up, negative right = left), which are genuine behavioral semantics, but says nothing about preconditions such as whether the target window or the point under the cursor must be focused, nor whether the pointer itself 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?

Two compact sentences with the action and target first, direction convention second. No filler, no repetition of the tool name.

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

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

An output schema exists, so return values need not be explained. However, for a pointer/window-interacting tool with zero annotations and zero schema descriptions, the definition leaves out focus requirements and coordinate frame, which an agent needs to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it explains that x/y select the scroll point (or the pointer when omitted) and that down/right accept signed notch counts with negative meaning the opposite direction. It omits the zero defaults and whether coordinates are absolute screen coordinates.

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 (scroll) with unit (wheel notches), target (coordinates or pointer), and axis semantics. It is immediately distinguishable from siblings like mouse_move, click, and drag, which move or activate rather than scroll.

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?

'At (x, y) or the pointer' implies the two usage modes (explicit coordinates vs. current cursor position) but never says when to prefer one or addresses any alternative tool for reaching content (e.g., focus_window). Usage is inferable but not guided.

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 delivers the key non-obvious side effect: windows on removed workspaces are relocated to the last remaining one. It stops short of saying whether increasing the count creates empty workspaces or what happens when the range is violated.

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; the operation and its valid range come first and the side-effect warning follows. No filler or restatement of the tool name.

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

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

For a single-parameter mutation with an output schema (so return values need not be described) and no annotations, the description covers the essential semantics and the destructive side effect. Missing only edge-case outcomes such as out-of-range input handling and behavior on increase versus decrease.

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 partially by supplying the 1-32 bound and clarifying that 'count' is the absolute target number rather than a delta. It could still spell out the failure behavior for out-of-range values or equal-to-current calls.

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 precise verb and resource ('change how many workspaces there are') plus the valid range (1-32), which clearly separates it from siblings like view_workspace, move_window_to_workspace, and tile_windows. An agent can identify the operation 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?

Usage is only implied: the agent must infer that this is the tool for resizing the workspace set. There is no explicit when-to-use, no mention of prerequisites, and no exclusion pointing at related siblings such as move_window_to_workspace for rearranging content.

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 discloses layout algorithms, window ordering, default workspace behavior, and excluded windows, but does not state whether windows are moved or resized, whether the change is reversible, or other side effects/failure modes.

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

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

The description is front-loaded and compact: the main action comes first, followed by concise layout definitions and constraints. Every sentence adds operational information without repetition.

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

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

Given only two optional parameters and an existing output schema, the description provides enough to invoke the tool correctly: layout meanings, default workspace, and which windows are affected or excluded. The main missing piece is explicit disclosure of side effects for a mutation 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?

Schema description coverage is 0%, and the description fully compensates for the layout parameter by mapping columns, rows, and grid to concrete arrangements. It also clarifies the workspace parameter by saying it defaults to the shown workspace.

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?

It names a specific verb and resource: arrange normal windows of a workspace side by side. The scope and layout definitions clearly separate it from single-window siblings such as move_resize_window, though it does not explicitly name 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?

Usage is implied for tiling windows, with useful details about the default workspace and that dialogs/minimized windows are excluded. It does not state when to choose this tool over move_resize_window or window_action, nor does it give broader when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that any Unicode works independent of keyboard layout and that newlines/tabs trigger Return/Tab, but it omits behavior around the delay_ms parameter, focus failures, or side effects of typing into the active window.

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

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

The description is three short sentences with no filler. The main action is front-loaded, followed by useful text-handling details.

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. However, for a two-parameter interaction tool with no annotations, the description is incomplete because it never explains delay_ms or what happens if no window is focused.

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?

With 0% schema description coverage, the description must compensate for both parameters. It adds some meaning for the text parameter by explaining Unicode and newline/tab handling, but it says nothing about delay_ms, leaving half the parameters undocumented.

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

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

The description states a specific verb and target: "Type text into the focused window." This clearly distinguishes the action from siblings like press_keys, though it does not explicitly name or contrast 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?

The description implies usage by explaining how newlines and tabs are handled, but it does not state when to choose this tool over alternatives such as press_keys or bash. No explicit when/when-not guidance is provided.

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 add genuine behavior: windows on other workspaces are hidden, not closed, which tells the agent this is non-destructive view switching. It omits what happens with an out-of-range index, whether set_workspace_count must precede it, or any permission/persistence notes.

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

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

Two short sentences, zero waste, with the indexing convention and the hidden-not-closed behavior both front-loaded.

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 tool is simple. Still, for a state-changing navigation tool with no annotations, the description leaves gaps around valid range and interaction with set_workspace_count.

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 'workspace' property has no description, so the description's 'numbered from 1' is the only source of indexing semantics. That is useful but incomplete — no upper bound, no interaction with workspace count.

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 ('Show a workspace') and clarifies the resource's indexing ('numbered from 1'). It does not name siblings like move_window_to_workspace or set_workspace_count, but the purpose is unambiguous on its own.

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 this versus moving a window to a workspace or changing the workspace count. The agent must infer from sibling names alone that this only switches the current view.

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 a hard cap ('Max 30s'), which is real behavior the agent could otherwise only discover by failure, but it doesn't say whether the call blocks, whether values over 30s are clamped or rejected, or what the result contains.

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 verb and followed by the concrete use case. Minimal waste; the only slight ambiguity is what 'Max 30s' means operationally.

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

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

For a trivial one-parameter sleep with an output schema, this is nearly sufficient, but the missing overflow behavior and the unmentioned relationship to `wait_until_idle` leave real gaps given that sibling 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?

The only parameter has 0% schema description coverage, so the description must compensate. 'Max 30s' does add a meaningful bound the schema lacks, but the units/type semantics and overflow behavior for `seconds` remain unstated.

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 (sleep) with a concrete motivating example (waiting for an app to load before a screenshot), so the agent knows exactly what it does. It does not distinguish the tool from the sibling `wait_until_idle`, which is the main alternative for the same need.

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 example implies when to use it (fixed pause before screenshotting), but there is no explicit guidance on when to use it versus `wait_until_idle`, nor any exclusion (e.g. 'prefer wait_until_idle if you need to wait for actual idle state').

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 idle condition, the 60-second timeout cap, and how min_area filters small redraws, including min_area=0. It does not describe the outcome when timeout is reached, though an output schema exists to cover returns.

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

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

Two front-loaded sentences; the first establishes the core wait condition and the second explains the min_area filter. No wasted prose, and the edge case min_area=0 is included compactly.

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 three optional parameters, no annotations, and an output schema, the description gives the essential semantics for a correct call. It omits guidance about when to prefer this over sibling wait, but not the call mechanics.

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 defines timeout as seconds with a max of 60, min_area as square pixels with a 20x20-style default and special zero behavior, and ties quiet_ms to the redraw-free interval. That covers all three parameters, though quiet_ms's unit is only implied by its name.

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?

It names a specific operation, waiting for screen redraws to cease, and defines the quiet interval and timeout condition. It is more specific than a generic wait, though it does not explicitly differentiate itself from the sibling wait 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?

The description never states when to use this instead of sibling wait, nor when not to use it. It implies a UI-settling scenario through the idle-redraw condition, but gives no explicit selection guidance or 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 zero annotations the description carries the full burden, and it does so for the risky path: it discloses the mechanism (XKillClient disconnects the client from the display), the escalation (it then kills the process if that survives), and the safer alternative. It does not state whether the toggles are reversible/safe or what happens on an invalid window_id, so it stops short of full disclosure.

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

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

Two sentences, front-loaded with the core action, followed by a focused hazard note. No filler and nothing repeated from the schema.

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

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

An output schema exists, so return values need not be explained, and the destructive semantics are covered well. Remaining gaps are the toggle actions' effects and error behavior for a bad or missing window_id.

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 covers window_id's default (the focused window) and details the 'kill' enum value, but adds nothing about the two toggle values or any constraints on window_id, leaving a meaningful share of parameter meaning unstated.

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+resource ("apply an action to a window") and scopes it with a default target. The action enum values are visible in the schema but only 'kill' is explained in prose, so the reader must infer what the two toggle actions do.

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

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

Gives explicit routing for the destructive path — "use close_window first" — which is the highest-value guidance here. However, no guidance is offered for choosing between the toggle actions or for when to supply an explicit window_id versus relying on the focused window.

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 meaningful behavior — the upscale cap ('about 1568px on the long side, at most 4x') and the pixel coordinate mapping — which is genuinely useful. It omits whether this is non-destructive/read-only, how the result is delivered (image payload vs handle), and any cost or rate considerations for repeatedly zooming.

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 blocks: purpose first, then the upscale rule, then the coordinate transform. Every sentence carries information the schema does not, and nothing is repeated from the input schema.

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

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

For a five-parameter, annotation-free tool with no output schema, the description covers the region semantics, the scaling behavior, and the coordinate math an agent needs to interpret the returned image. The remaining gap is the return payload itself and the zoom-vs-screenshot decision, which is where an agent is most likely to go wrong.

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 largely does: x/y/width/height are framed as a screen-pixel region, and `factor` gets both a default behavior and a hard ceiling. The inverse mapping formula makes the relationship between image pixels and screen pixels unambiguous. Minor gap: units for x/y/width/height are only implied by the mapping formula.

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 ('Magnify a region of the screen') plus the intent ('to read small text or icons'), which naturally separates it from the plain screenshot sibling. It stops short of naming screenshot explicitly, so differentiation relies on inference.

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

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

The phrase 'to read small text or icons' implies when to reach for zoom, but there is no explicit guidance such as 'use this instead of screenshot when detail is too small to read'. No prerequisites, no when-not-to-use, no named alternative among the many siblings.

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