linux-computer-use-skill

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, and it does: sequential execution, stop-on-first-error, allowlist gate evaluated at call time, per-action re-evaluation of the gate, and the critical coordinate-caveat that mid-batch screenshots do not update the coordinate frame for later clicks. These are non-obvious traits an agent could not infer from the schema and would otherwise get wrong.

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 purpose, then rationale, then the allowlist gate, then the coordinate caveat — a sensible ordering. Five sentences for a tool with this many non-obvious runtime rules is dense but earns its length; minor compression is possible but no sentence is filler.

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

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

For a batch-execution tool with no annotations and no output schema, the description covers everything the agent must know: batching benefit, predictor condition, ordering/error semantics, auth gate behavior at both call and per-action granularity, and the coordinate-reference frame. Nothing about correct invocation is left to guesswork.

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 100% and the schema itself documents every sub-field (text, repeat, duration, coordinate, start_coordinate, scroll_amount). The description adds genuine cross-cutting semantics the schema cannot express: actions run sequentially, abort on first error, and that coordinates refer to the pre-batch screenshot rather than any mid-batch screenshot. Baseline would be 3 given full schema coverage; the pre-batch coordinate rule is strong value-add beyond the field descriptions.

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 ('Execute a sequence of actions in ONE tool call') and immediately differentiates from the 20+ single-action siblings (type, left_click, key, etc.) by explaining that each individual call costs a model→API round trip. An agent can tell this is the batch counterpart to the singular tools 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?

Explicit when-to-use with a concrete example ('click a field, type into it, press Return') and the selecting condition ('use this whenever you can predict the outcome of several actions ahead'). It also names the implicit alternative — the single-action siblings — via the round-trip contrast. No exclusions are needed beyond the predictability condition, which is itself the boundary.

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?

Description reveals important behavioral detail about coordinate reference (screenshot vs logical points), which is not covered by missing annotations. It adds value beyond the schema, though could mention stability or performance 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?

Two sentences with no excess. The first sentence states purpose, the second adds critical qualification. Every word earns its place.

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

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

For a parameterless tool with no output schema, the description covers purpose, coordinate system, and conditional behavior. No gaps remain.

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 zero parameters and 100% schema coverage, the baseline is 4. The description correctly adds no redundant parameter info, fulfilling its role.

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?

Description uses clear verb 'Get' and specific resource 'current mouse cursor position', with additional distinction between screenshot-dependent coordinate systems. This clearly differentiates it from sibling tools like mouse_move or click actions.

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?

Description implies usage for querying cursor position but provides no explicit comparison with sibling tools or guidance on when not to use it. It lacks alternatives or contextual cues.

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 discloses the allowlist precondition, the error-and-no-op behavior on failure, and the side effect (word selection). It doesn't cover return values or coordinate validation, but for a simple click tool this is largely sufficient.

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

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

Two sentences, zero waste, front-loaded with the action and immediately followed by side effect and precondition. All information is present and efficiently ordered.

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 the tool's simplicity, 2 parameters, no output schema, and no annotations, the description covers the essential action, side effect, and critical precondition. It is nearly complete, missing only minor details like coordinate source (though noted in schema) or failure error format.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter details beyond what the schema provides; it only implies a coordinate is required. The schema already documents both parameters thoroughly.

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 (double-click) and its location (given coordinates), and adds the concrete effect 'Selects a word in most text editors', which distinguishes it from left_click and triple_click siblings.

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 states the precondition: 'The frontmost application must be in the session allowlist at the time of this call', and describes the failure mode. This tells the agent when the tool will succeed versus error, which is crucial for routing between it and request_access.

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

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

No annotations exist, so the description carries full burden. It discloses error behavior if app not in allowlist, and mentions grants for system combos. It does not describe side effects or duration bounds beyond schema.

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, no wasted words. The action is front-loaded, and every sentence provides essential information.

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

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

For a simple hold action with two parameters and no output schema, the description covers prerequisites, error conditions, and basic behavior. It could mention return value but is mostly complete given low complexity.

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 100% with descriptions for both parameters. The description adds no meaning beyond 'hold' and 'duration' already present in the schema, so baseline 3 applies.

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

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

The description clearly states the action ('Press and hold... then release') and resource (a key or key combination). It distinguishes from sibling tools like 'key' and 'type' that do not hold.

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

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

It provides prerequisites (frontmost app in allowlist, systemKeyCombos grant for system combos) but does not explicitly compare with alternatives like 'key' or 'type' or specify when not to use this tool.

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 provided, so description carries full burden. It discloses error behavior and grant requirement, which is good transparency for a key-press 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?

Single paragraph with no wasted words. Purpose is front-loaded, and every sentence adds critical 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?

Covers preconditions, error handling, special grants. No output schema needed; description is complete for an agent to use 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 has 100% coverage. Description adds value with examples and format (modifiers joined with '+'), beyond the schema's description.

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

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

The description explicitly states it presses a key or key combination, with concrete examples like 'return', 'escape', 'cmd+a'. It clearly distinguishes from siblings like 'hold_key' and '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?

Provides clear context: frontmost app must be in allowlist or tool returns error; system combos require `systemKeyCombos` grant. Does not explicitly name alternative tools but gives enough guidance.

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

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

With no annotations, the description carries the full burden and it does disclose a real behavioral trait: the allowlist gate and the failure mode (returns an error and performs no action). It does not cover timing, focus side effects, or what modifiers do, but the key safety-relevant behavior is 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?

Two short sentences with zero waste; the action is front-loaded and the constraint follows. Nothing is repeated and nothing needs expanding.

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 mouse action with no annotations and no output schema, the description covers the essential gating behavior. The only shortfall is that the meaning and consequences of the optional modifier parameter are left entirely to the schema.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema with detailed semantics (pixel coordinates read from the screenshot, modifier key syntax). The description adds nothing about parameters beyond 'given coordinates', so the baseline 3 applies.

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

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

States a specific verb (left-click) and a specific resource (the given coordinates). The word 'left' inherently disambiguates from the sibling tools right_click, middle_click, double_click and triple_click, so an agent can pick it without opening others' schemas.

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

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

Provides a concrete precondition for use: the frontmost application must be in the session allowlist, otherwise the call errors and does nothing. It does not explicitly say when to prefer this over left_mouse_down/left_mouse_up or double_click, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one important trait: the frontmost application must be in the session allowlist or the call fails and does nothing. That failure semantics is genuinely useful, but it says nothing about whether the operation blocks, timing/interpolation of the move, or permission prompts.

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

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

Two short sentences, no filler, with the action sequence front-loaded and the failure constraint second. It is tight, though the first sentence is terse enough to feel slightly clipped.

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 two-parameter input tool with no output schema and no annotations, the description plus the detailed schema covers the essentials: what it does, the endpoint semantics, and the allowlist failure mode. Only the blocking/timing behavior and the atomic-sibling tradeoff are absent.

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

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

Schema description coverage is 100% and both coordinate parameters are richly documented in the schema (end point, optional start point defaulting to current cursor, pixel origin, scaling handled). The description adds no parameter-level information beyond that, so the baseline of 3 applies.

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

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

The description spells out the exact action sequence (press, move to target, release), which unambiguously identifies a drag operation and distinguishes it from the atomic siblings left_mouse_down, mouse_move, and left_mouse_up. It never uses the word 'drag' or names the resource explicitly, but the sequence is specific enough to select correctly.

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 prefer this composite drag over manually chaining left_mouse_down / mouse_move / left_mouse_up, nor any mention of computer_batch for multi-step interactions. The allowlist statement is a precondition/error condition rather than usage guidance.

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

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

With no annotations, the description carries the burden. It discloses the hold action, error if already held, and the allowlist requirement. It does not discuss edge cases like dragging, but the core behavior is well covered.

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

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

The description is three sentences, front-loaded with the action, and every sentence adds value. No redundancy or unnecessary information.

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

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

For a param-less tool with no output schema, the description covers purpose, prerequisites, sequence, and error conditions. It is complete and leaves no ambiguity about how to use the 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?

There are no parameters, so the schema describes them all. The description adds context about usage that goes beyond the schema, making it helpful for an agent. Given zero parameters, a baseline of 4 is appropriate.

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

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

The description clearly states the action: press and hold the left mouse button. It distinguishes itself from siblings like left_mouse_up and left_click by explaining the hold behavior and the release step.

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 step-by-step context: use mouse_move first, call left_mouse_up to release. Also specifies the prerequisite that the frontmost app must be in the allowlist. No explicit when-not-to-use, but the guidance is clear.

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 provided, the description fully carries the burden of behavioral disclosure. It explains that the tool releases the button at the current cursor position, requires the frontmost app to be in the allowlist (otherwise error and no action), and is safe to call even if the button is not held.

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 concise (three sentences) and front-loaded with the main purpose. Each sentence adds value: core action, prerequisite, pairing, and safety. No unnecessary words.

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

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

For a simple tool with no parameters or output schema, the description covers all necessary aspects: action, location, prerequisites, pairing, and safety. It is complete for its intended 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?

The input schema has no parameters, so schema coverage is trivially 100%. The description adds no parameter-specific info but provides essential context about the action, which is sufficient given the absence of parameters.

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

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

The description clearly states the action (release) and resource (left mouse button) at the current cursor position. It distinguishes from siblings like left_click and left_click_drag by specifying it's a release without additional actions, and pairs with left_mouse_down.

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 explicitly mentions pairing with left_mouse_down, safe to call even if not held, and the prerequisite that the frontmost application must be in the allowlist. It provides clear context for when to use this tool, though it doesn't discuss when not to use it beyond the allowlist requirement.

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 takes full responsibility. It discloses that the tool lists three specific things (applications, grant flags, coordinate mode) and has no side effects. This is sufficient for a read-only query, though it could mention whether any permissions are 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?

The description is a single, efficient sentence that immediately conveys the action and scope. No unnecessary words.

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

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

The description hints at the return contents but provides no details on structure or format. Since there is no output schema, additional context about the expected output (e.g., list of strings, object keys) would improve completeness.

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 (0), so the baseline is 4 per guidelines. The description adds value by specifying what is listed, which is necessary since there is no output schema to describe the return value.

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 clearly states the verb ('List') and the resource ('applications currently in the session allowlist, plus active grant flags and coordinate mode'), which is specific. It distinguishes from sibling tools, which are predominantly action-oriented (e.g., click, type) or clipboard operations.

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 mentions 'No side effects,' implying safe usage, but does not provide explicit guidance on when to use this tool versus alternatives or any conditions. Given the simple nature, it is adequate but lacks contextual advice.

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 the key behavioral trait: the frontmost app must be in the session allowlist, otherwise it errors and does nothing. It doesn't cover modifier interactions or side effects beyond that, so not a 5.

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

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

Two compact sentences, front-loaded with the action, with the critical precondition second. 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?

A simple click tool with a fully documented schema and no output schema; the description covers the essential precondition (allowlist) that the schema can't express. Missing only minor detail about modifier-holding behavior, which is partly in the schema.

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 100%, so the schema already documents both the coordinate and text/modifier parameters in detail (including scaling and modifier syntax). The description adds nothing beyond the coordinate reference already in the schema, giving the expected baseline 3.

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 (middle-click at coordinates) and clarifies the gesture (scroll-wheel click), which distinguishes it from sibling click tools like left_click, right_click, and double_click. It doesn't explicitly name those siblings, so it stops short of a 5.

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

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

Conveys when the call will succeed via the allowlist prerequisite, but gives no guidance on when to prefer middle_click over left_click or right_click, and no exclusions. Usage is implied by the gesture name rather than explained.

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 burden and does well: it discloses non-clicking behavior, hover-state purpose, and a concrete failure mode with the allowlist precondition. It doesn't describe return values or coordinate validation behavior, but the critical behavioral trait (precondition gating) is covered.

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

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

Three tight sentences: action, use case, and precondition. Front-loaded with the verb, no wasted words, and the operational constraint is clearly separated.

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 one-parameter motion tool with no output schema, the description covers action, purpose, and the critical allowlist precondition that would otherwise cause silent failure. It's complete enough to use correctly, though it could mention whether error is returned vs no-op more precisely (it does both: 'returns an error and does nothing').

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 100%, so the single coordinate parameter is fully documented in the schema with pixel-position and scaling details. The description adds nothing parameter-specific, so baseline 3 is appropriate.

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

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

States a specific verb (Move) and resource (mouse cursor), and immediately clarifies scope with 'without clicking,' which cleanly distinguishes it from siblings like left_click, double_click, and left_click_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?

Explains the use case ('triggering hover states') and a key precondition (frontmost app must be in session allowlist). It doesn't name a specific alternative for hover-like positioning, but the context is clear enough to route correctly.

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

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

With no annotations, the description carries the full burden. It discloses that the tool may launch the application (a state-changing action) and requires prior access granting. However, it omits details on error handling, return values, or whether it silently fails if the app is not allowed. This is adequate 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 two concise sentences: the first states the action, the second the prerequisite. Every word is necessary, no fluff, and it is front-loaded efficiently.

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 the tool's low complexity and lack of output schema, the description covers the main behavior and a critical prerequisite. It references the sibling tool request_access appropriately. Minor missing elements like error behavior or return format do not significantly detract from completeness for this simple operation.

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 provides 100% coverage with a clear description of the 'app' parameter (display name or bundle ID). The tool description adds no additional parameter information, so it meets the baseline but does not exceed it.

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 clearly states the action 'bring an application to the front' and the resource 'application', with the additional nuance of launching if necessary. It distinguishes itself from siblings like request_access and list_granted_applications by directly mentioning the allowlist prerequisite, making its 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?

The description explicitly directs to call request_access first if the app is not in the allowlist, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, though the sibling list implies its specific role.

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?

Without annotations, the description explains the read operation and the grant requirement, which adds behavioral context beyond a simple statement. It does not detail error handling or empty clipboard behavior.

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

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

A single, front-loaded sentence that efficiently conveys the tool's purpose and a key requirement.

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 the simplicity of the tool (no parameters, no output schema), the description provides the essential information. It could mention error cases for missing grant or non-text content, but is adequate for most agents.

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

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

The tool has no parameters, and schema coverage is 100%. The description adds no parameter information beyond the schema, which is acceptable at baseline.

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 clearly states the tool reads clipboard contents as text, which is specific and distinct from sibling tools like write_clipboard.

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 explicitly mentions the required clipboardRead grant, providing a usage condition. However, it does not discuss alternatives 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, description carries full burden. It discloses: shows a single dialog, user allows/denies whole set, returns granted/denied apps and screenshot filtering capability, behavior on re-call (previously granted apps remain granted). This is thorough behavioral 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?

Description is a single paragraph with multiple informative sentences. It is well-structured and front-loaded with the most important information. Slightly lengthy but every sentence adds value.

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

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

Given no output schema, description explains return values (granted apps, denied apps, screenshot filtering). It covers prerequisites, behavior, and re-calls. For a tool with 5 parameters (all documented in schema) and no output schema, the description is 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 100%, so schema already describes all parameters. Description adds context about the dialog and overall behavior but does not add meaning beyond what the schema provides for individual parameters. Baseline 3 is appropriate.

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

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

Description clearly states the verb 'request permission' and the resource 'control a set of applications for this session'. It explicitly distinguishes itself from siblings by stating it must be called before any other tool, and no other tool in the list handles permission requests.

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 states 'Must be called before any other tool' and 'Call this again mid-session to add more apps', providing clear when-to-use guidance. However, it does not explicitly list when not to use or alternatives, though the context implies 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 it does disclose a real behavioral trait beyond the name: the frontmost application must be in the session allowlist or the call errors and does nothing. That failure-mode/auth gating context is valuable and non-obvious. It still omits timing/blocking behavior, keeping it out of 5 territory.

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

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

Three short sentences, each earning its place, with the core action front-loaded and the constraint placed after it. No 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 coordinate-based mouse action with no annotations and no output schema, the description covers what it does, the effect, and the failure precondition. Nothing an agent needs to invoke 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?

Schema description coverage is 100%, so both the coordinate and modifier-key parameters are already documented (including pixel origin and scaling). The description only refers to 'the given coordinates' and adds no meaning beyond the schema, matching the baseline 3.

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 ('Right-click at the given coordinates') and adds the observable effect ('Opens a context menu in most applications'), which clearly separates it from left_click, middle_click, double_click and the other mouse siblings.

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 mention of opening a context menu gives agents a clear reason to choose this over left_click/middle_click, and the allowlist constraint signals the precondition for use. It stops short of naming an explicit alternative, but the usage context is well implied.

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 provided, the description takes full responsibility for behavioral disclosure. It reveals that screenshots are unfiltered, that actions are rejected if apps are not in the allowlist, and that the returned image is the reference for click coordinates. This adds significant context beyond the schema.

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 four sentences with no redundant information. Every sentence adds value, covering purpose, behavior, and a practical note about coordinate reference. It is front-loaded and efficient.

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 the tool's simplicity (one optional param, no output schema), the description covers key aspects: what it does, behavioral constraints, and how the output is used. It explains error conditions and the relevance of the returned image. Minor omissions (e.g., explicit format of non-saved image) are acceptable given the context.

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 already provides a detailed description for the single parameter (save_to_disk), achieving 100% coverage. The tool description does not add any extra parameter semantics beyond what's in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Take a screenshot of the primary display', specifying verb and resource. It distinguishes from siblings by noting that screenshots are not filtered and includes context about allowlist rejection, which differentiates it from other tools like cursor_position or mouse_move.

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

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

The description provides guidance on when to use the tool (e.g., for looking at screen) and includes behavioral notes like allowlist rejection and error conditions. However, it does not explicitly contrast with alternatives or state when not to use it.

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

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

With no annotations, the description carries the full burden, and it discloses an important behavioral trait: the frontmost application must be in the session allowlist or the call returns an error and does nothing. That failure mode is exactly the kind of context an agent needs. It still omits rate limits, return format, and whether a prior screenshot is required to obtain coordinates.

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, zero filler, with the action front-loaded and the precondition immediately following. Every sentence earns its place.

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

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

Given a 3-parameter tool with 100% schema coverage and no output schema, the description only needs to add the invocation precondition, which it does. It is close to complete, though a hint about deriving coordinates from the latest screenshot would make the workflow self-contained.

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

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

Schema description coverage is 100%, so coordinate, direction, and amount are already fully documented by the schema, including the enum and tick semantics. The description's 'at the given coordinates' adds no meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (scroll) and target (the given coordinates), which is enough for an agent to distinguish it from click/key/drag siblings. However, it does not name a sibling or scope the tool relative to alternatives like screenshot or mouse_move.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative. The allowlist sentence implies a precondition for successful invocation, which is real context, but it is a call-time constraint rather than usage routing.

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

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

The description discloses the behavior: it changes the monitor for subsequent screenshots, the screenshot tool provides the monitor names, and after switching, one should call screenshot to see the new monitor. No annotations are present, but the description fully handles transparency.

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 concise with four sentences, no wasted words, and front-loads the main purpose. Every sentence adds necessary context.

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 tool with one parameter and no output schema, the description covers the workflow: how to get the parameter, what the tool does, and what to do after (call screenshot). It is complete and actionable.

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 100%, so baseline is 3. The description adds value by explaining that the monitor name comes from the screenshot tool's note and that 'auto' re-enables automatic selection, going beyond 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?

The description clearly states the tool's purpose: 'Switch which monitor subsequent screenshots capture.' It specifies the action (switch), the resource (monitor for screenshots), and distinguishes from sibling tools like 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 explains when to use the tool ('when the application you need is on a different monitor than the one shown'), how to obtain the required parameter (from screenshot tool's note), and mentions alternative actions ('auto' for automatic selection).

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 a genuinely useful behavioral trait by naming the allowlist gate and the resulting error-with-no-action failure mode. It still omits whether the action is reversible, timing/ordering behavior relative to other mouse tools, or what the error looks like.

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; the action is front-loaded, followed by the user-visible effect and then the precondition. Nothing is redundant with the name or title.

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 two-parameter tool with full schema coverage and no output schema, the description supplies everything an agent needs: what it does, the semantic effect, and the blocking precondition. No return-value explanation is required.

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 100%, with both coordinates and modifier-key syntax documented in the schema itself, so the baseline of 3 applies. The description adds no format or semantic detail beyond what the schema already states.

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 ("Triple-click at the given coordinates") and adds the semantic outcome ("selects a line in most text editors"), which lets an agent differentiate it from double_click and left_click 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?

Gives clear context for when the tool is the right one (selecting a line in text editors) and states a hard precondition (frontmost app must be in the allowlist). It stops short of explicitly naming alternatives such as double_click for word selection or drag for range selection.

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 condition about the allowlist, support for newlines, and what happens (returns error) if the app is not allowed. However, it doesn't specify what occurs if no keyboard focus exists, which is a minor 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?

Three sentences, each serving a distinct purpose: purpose, condition, and alternative. No wasted words, front-loaded with core action.

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 one-parameter tool with no output schema, the description covers functional behavior, error handling, and alternative tool usage. It is complete given the tool's simplicity and the context of sibling 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 coverage is 100% (single parameter 'text' described in the schema). The description adds only the note that 'Newlines are supported,' which provides marginal extra value beyond the schema's 'Text to type.' Baseline 3 is appropriate.

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

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

The description explicitly states 'Type text into whatever currently has keyboard focus,' which is a specific verb-resource pair. It clearly distinguishes from the sibling tool 'key' used for keyboard shortcuts.

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 provides clear when-to-use guidance: the frontmost application must be in the session allowlist, and it explicitly directs 'For keyboard shortcuts use `key` instead,' naming the alternative tool.

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, and the description does not specify behavioral traits like blocking behavior or precision. However, for a simple wait operation, the lack of detail is acceptable as the behavior is straightforward.

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 sentence that efficiently conveys the tool's purpose without any extraneous information. Every word 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?

Given the tool's simplicity (single parameter, no output schema), the description is complete and sufficient for an agent to understand and invoke 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 coverage is 100% with the duration parameter described clearly. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description 'Wait for a specified duration' clearly identifies the tool as a delay mechanism, distinct from all sibling tools which involve user input or output actions.

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 explicit guidance on when to use this tool versus alternatives, but sibling tools are all different actions, making usage implicitly clear. No explicit exclusions or recommendations 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 provided, the description bears full responsibility. It discloses the need for a specific permission but does not mention side effects like overwriting existing clipboard content or behavior on failure, leaving behavioral aspects partially uncovered.

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, efficient sentence that includes both the core functionality and a key requirement. Every word serves a purpose with no 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?

Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it lacks details on synchronous behavior, error handling, and whether the operation is idempotent, making it less complete than it could be.

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 one parameter 'text' with no description coverage (0%). The description adds no additional meaning about the parameter, such as format restrictions, length limits, or encoding, failing to compensate for the schema's lack of detail.

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 'Write text to the clipboard' clearly states the action and resource, with a specific verb and target. It effectively distinguishes itself from the sibling 'read_clipboard'.

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 mentions a required grant ('clipboardWrite'), which provides a usage condition. However, it does not offer explicit guidance on when to use this tool versus alternatives nor 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 full burden. It explicitly states 'This tool is read-only for inspecting detail' and warns that coordinates in subsequent clicks refer to the full-screen screenshot. It does not describe all edge cases but covers the key behavioral trait.

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 short (4 sentences), every sentence adds value, and the key information is front-loaded. It is well-structured and easy to parse.

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 description covers purpose, usage guidance, and behavioral transparency. Given no output schema, it does not need to detail return values. It is complete for the tool's complexity, though could mention the result type briefly.

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

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

The schema coverage is 100% for both parameters. The description adds minimal additional meaning beyond the schema, such as confirming the coordinate space for 'region'. This meets the baseline but does not significantly enhance understanding.

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 clearly states the tool's purpose: 'Take a higher-resolution screenshot of a specific region of the last full-screen screenshot.' This distinguishes it from the sibling tool 'screenshot' which captures a full screen.

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 advises to 'Use this liberally to inspect small text, button labels, or fine UI details that are hard to read.' It also provides a critical warning about coordinate systems. However, it does not explicitly mention when not to use it or alternatives.

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