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 coordinate space, which is useful, but says nothing about blocking behavior, what happens with out-of-bounds coordinates, whether the cursor is moved as a side effect, or whether the click targets whatever is focused — all relevant for an input-injection 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?

A single sentence with the critical coordinate-frame constraint front-loaded in parentheses. Nothing superfluous and no buried 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?

The tool is simple, and the coordinate-space clarification covers the biggest mistake mode. But with no annotations, no output schema, and half the parameters undocumented, an agent still lacks confirmation of click semantics (single vs double, button default, 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 coverage is only 50%: x/y are documented in the schema, while 'button' (enum) and especially 'double' are undocumented in both places. The description does add real value by clarifying that coordinates are full-host-screen absolute pixels rather than window-relative, but it never explains that 'double' produces a double-click.

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 (clicks) and resource (absolute screen coordinates) and pins the coordinate frame to 'pixels of the full host screen', which is the key ambiguity for a GUI-automation tool. It does not explicitly differentiate from siblings like move_mouse or drag, and double-click is left to a parameter rather than called out.

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 pointer to 'screenshot metadata' implies the workflow (screenshot first, then click at those coordinates), but this is only implied. There is no explicit guidance on when to click versus drag/scroll/move_mouse, and no prerequisites or exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation uses the left button and follows a press-move-release sequence, but it omits coordinate space, timing, side effects, error behavior, and return semantics.

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 tightly structured sentence with zero wasted words. It is front-loaded with the action and immediately explains the role of all four coordinates.

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 pointer-automation tool, the core action and parameter roles are covered. However, with no annotations and no output schema, the description should also mention coordinate system, whether the drag is synchronous, and any meaningful side effects or return 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 the four undocumented numeric parameters. It does this well by mapping (x1,y1) to the press point and (x2,y2) to the release point, though it does not specify coordinate origin or units.

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 precise mouse operation: press the left button at one point, move to another, and release. This clearly identifies a drag action and distinguishes it mechanically from click or move_mouse, though it does not explicitly name those 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?

The description explains how the drag is performed but gives no guidance on when to use it instead of click, move_mouse, scroll, or other sibling tools. There are no stated preconditions, exclusions, or alternative-selection rules.

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

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

No annotations exist, so the description carries the entire behavioral burden, and it discloses very little. It implies an outbound lookup against the ASUS support page but does not state that network/Internet access is required, whether the tool is strictly read-only (i.e. never flashes or downloads firmware), how long the check takes, or what happens on failure or when the card model is unrecognized.

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 identifies the subject and the comparison target with no filler. It is perhaps over-compressed for a tool that performs an external network lookup, but nothing in it is wasted.

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

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

With no parameters and no output schema, the description is the only place an agent can learn what comes back, and it only hints at it via '(version, date, SHA-256)' without saying whether the result is an up-to-date flag, a latest-release record, or a diff. For a zero-arg tool with no annotations this leaves a real gap, though the core operation is understandable.

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

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

The tool takes zero parameters, which is the baseline-4 case; the schema has nothing to document and the description is consistent with a no-argument call. The mention of version, date and SHA-256 adds color about what is compared, but it is not parameter semantics.

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

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

The description names a specific action (compare card firmware against ASUS support-page releases) and scopes it to the hardware's firmware lineage. It is clearly distinguishable from the sibling tools (screenshot, click, kvm_status, system_info) without opening any schema. It stops short of a 5 only because it never frames the outcome (e.g. 'reports whether an update is available').

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 rather than stated: an agent can infer this is the tool to reach for when it needs to know if the IPMI card firmware is current, and no sibling competes for that job. However, there is no explicit when/when-not guidance, no mention of prerequisites such as network access to the ASUS page, and no alternatives named.

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

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

No annotations exist, so the description carries the full burden; it partly meets it by enumerating what the response reveals (connection state, resolution, blank display, mouse mode, other clients), which implies a non-mutating query. It does not state that it is read-only, side-effect free, or what 'other KVM clients' means in practice.

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 short sentence with no filler, front-loaded on the most decision-relevant item (connection state). It is terse to the point of being clipped, but nothing is wasted.

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

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

With no output schema, the description must report what comes back, and it does enumerate the returned fields. Given zero parameters and a simple read operation, this is close to sufficient; only the meaning of the client-list field is left ambiguous.

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

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

The tool takes zero parameters, so the baseline is 4; nothing about arguments needs explaining. The field list in the description maps to return content rather than inputs, which is the right emphasis for a parameterless tool.

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 is a telegraphic noun list of reported fields rather than a verb+resource statement, but the title and content make clear it reports KVM session state. An agent can infer it is a status read, though it is not explicitly differentiated from siblings like system_info or sensors.

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 call this versus system_info, sensors, or screenshot, nor any note about polling or prerequisites. The agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only status query by listing reported content, but does not explicitly state that it is side-effect free, what permissions or prerequisites are needed, or how the information is presented.

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 text is a single short fragment with no wasted words and the key resource term ('Remote-media settings') is front-loaded. However, the fragment lacks a verb and reads as a label rather than a sentence, leaving the description underspecified rather than genuinely concise.

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 zero parameters, no annotations, and no output schema, the description should explain what a call returns and when to use it. It enumerates three categories of remote-media data, which is a reasonable start, but without a verb or usage context the agent lacks a complete picture.

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 per the baseline there is no parameter semantics to document; the description cannot add value beyond the (empty) schema. Baseline 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?

The description lists the resource categories covered ('remote-media settings (share), images found on the share, active redirections') but supplies no verb, so it never states that it retrieves/reports status. It is distinguishable from siblings like kvm_status only because of the 'remote-media' wording, not because the description says what operation it performs.

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 indication of when to use this tool, when not to, or which sibling (e.g., kvm_status) is the alternative. The agent must infer usage from the tool name alone.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does surface one genuine side effect — waking a sleeping display — which is real behavioral value beyond the schema, but it omits whether the move is instant or animated, what happens with out-of-bounds or negative coordinates, and any permission requirements.

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

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

A single front-loaded sentence with the action first and the side-effect note in parentheses; every clause carries information and nothing is redundant.

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

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

For a two-parameter tool with no annotations, no output schema, and 0% parameter coverage, the description covers purpose and one side effect but leaves key calling details unspecified — coordinate origin, pixel units, and multi-monitor/bounds behavior. It is adequate to call the tool in the common case but thin for edge cases.

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

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

Schema coverage is 0%, so the schema only tells the agent that x and y are numbers. The description meaningfully adds that they are ABSOLUTE screen coordinates rather than deltas, which is the single most important semantic distinction here. It still omits the coordinate origin and units, so the two undocumented params are only partly compensated for.

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 ('moves') plus the resource ('the pointer') and the exact target space ('absolute screen coordinates'), which separates it from relative-motion siblings like drag or scroll. It does not explicitly name a sibling it replaces, so an agent must infer that click/drag are the alternatives when a click is also wanted.

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 'use this when…' or 'do not use this when…' guidance; the only usage signal is the parenthetical that it wakes a sleeping display, which implies a valid hang-recovery use case. The agent is left to infer that this is the hover-only alternative to click or drag.

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 carries the full burden of behavioral disclosure. It only lists example key values and sequence ordering; it does not state that input goes to the active/focused window, whether focus is required, how invalid keys are handled, or what side effects combinations like ctrl+alt+delete may cause.

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

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

The description is a single front-loaded sentence that states the action first, then gives compact examples and the ordering behavior. It is appropriately sized and contains no redundant explanation.

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 the schema fully documents its parameters, but with no annotations or output schema the description should say more about focus/active-window behavior and when to prefer type_text. It is adequate to identify the operation but has clear gaps for correct invocation in 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?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds useful meaning by giving concrete key-name and key-combination syntax examples and clarifying that multiple keys can be passed in order, which is not fully conveyed by the schema alone.

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

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

The description states a specific verb and resource: pressing keys, with concrete examples including combinations and sequences. It is clear what the tool does, but it does not differentiate from the sibling tool type_text, which is the main alternative for keyboard input.

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 examples of valid keys but provides no explicit guidance on when to use this tool versus type_text or other input tools. There are no when-not conditions, prerequisites, or alternatives named, leaving selection between siblings to inference.

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

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

With no annotations, the description carries the full burden and does disclose a genuine side effect: it nudges the mouse to wake a blanked display, which could disturb cursor state. It omits latency, error behavior when KVM is unavailable, and that the wake nudge may perturb coordinates, so it is good but not complete.

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 carrying distinct information: what it returns, the wake side effect, and the crop option. Nothing redundant and the core purpose is 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?

For a 3-parameter, all-optional tool with no output schema, the description covers the essential behavior and the non-obvious side effect. The one gap is the return shape (image payload vs. reference) and whether max_side defaults actually apply when a region is supplied.

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 schema already documents format defaults, region shape, and the max_side range. The description only reinforces the region/crop use case for small text and adds no syntax or default detail beyond what is structured.

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 ("Returns the current host screen") plus the mechanism (IPMI card KVM), which immediately distinguishes it from the action siblings like click, move_mouse, and wait_for_screen_change. An agent knows exactly what it gets 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?

It gives a usage hint for the crop path ("to read small text") and explains the blank-display wake behavior, but never states when to choose this over wait_for_screen_change or when a full-screen capture is preferred. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full disclosure burden. It reveals the sign convention and that units are wheel notches, which is useful, but it omits whether scrolling targets the window under the cursor or requires prior focus, whether it requires the app to be foreground, and what is returned or how to confirm the scroll took 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?

A single tight sentence with the direction rule front-loaded and no filler. Slightly dense parenthetical, but every clause carries information.

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

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

For a 3-required-parameter input tool with no annotations and no output schema, an agent still cannot tell what coordinate frame x/y use or how to verify success. The definition is under-specified relative to the tool's 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 description coverage is 0%, so the description must compensate. It clarifies only 'amount' (sign direction, wheel notches) and leaves x and y completely undefined — no indication of coordinate space (screen vs. window), units, or origin.

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 ('Scrolls') and resource/operation ('at a position'), which clearly separates it from siblings like click, drag, and press_keys. It does not explicitly name what it is not, but the purpose is 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?

It explains scroll direction semantics but gives no guidance on when to use this versus wait_for_screen_change, drag, or press_keys (e.g. Page Down). No preconditions or exclusions are stated, so the agent must infer usage.

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. Naming the BMC/Redfish source is genuinely useful (implies out-of-band access that can fail if the BMC is unreachable), but it never states that the operation is read-only, what happens on BMC timeout, or how results are shaped — gaps that matter for an unannotated tool.

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

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

It is a single short fragment with zero waste and the key content front-loaded, but it is under-specified rather than crisp — brevity here costs information rather than buying clarity.

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

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

For an unannotated tool with an undocumented parameter and no output schema, the description should say more about what a reading looks like (names, units, status/thresholds) and the failure mode. As written, an agent still cannot predict the call's behavior beyond 'reads sensors'.

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 include_absent has 0% schema description coverage and is not mentioned in the description at all, yet its meaning (include sensors that are present but not reporting/absent?) is not self-evident. The description does nothing to compensate for the coverage gap.

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

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

The description names the resource (sensor readings) and the exact data returned (temperatures, fans, voltages), plus the source (BMC via Redfish), so an agent knows what it is. It doesn't explicitly distinguish itself from siblings like system_info or media_status, so it stops short of a 5.

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

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

There is no statement of when to use this versus alternatives. The implied use case (checking hardware health/thermal state out-of-band) is never articulated, and no exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries the full burden. 'Via Redfish' implies a read-only query over the BMC network interface, but the description never states that it is non-mutating, that it requires BMC credentials/connectivity, or what happens when the host is off (power state still returned?). For a tool with zero annotation coverage this is a significant gap.

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

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

Extremely short and front-loaded, but it is a comma-separated fragment rather than a complete statement, which leaves the reader to infer that these items are returned rather than configured. Brevity here edges toward under-specification rather than crispness.

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

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

With no output schema and no annotations, the description is the only documentation the agent has. Listing the three data categories gives a rough sense of the return payload, but it omits return structure, degradation behavior when the host is powered off, and relationship to sibling status 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The '(via Redfish)' note usefully explains how the data is sourced.

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

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

The description names the resource domains retrieved (BMC firmware, host power state, host BIOS/model) and the protocol (Redfish), which is more informative than the bare name 'system_info'. But it is a noun fragment with no verb, and it does not distinguish itself from siblings such as kvm_status or firmware_check_update that plausibly expose overlapping information.

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 call this versus kvm_status (which may also report host state) or firmware_check_update (BMC firmware). An agent must guess whether this is the summary/status tool or a duplicate of those siblings.

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 discloses key traits: US layout, escape sequences for Enter/Tab, non-ASCII rejection, and a critical security risk of typing into a password field. It still leaves some behavior unstated (e.g., whether text requires an already-focused field, what happens on failure), keeping it short of 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?

Three tight sentences, each carrying distinct value: purpose, input constraints, and safety prerequisite. There is no filler, and the critical constraint is front-loaded after the purpose statement.

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 2-parameter tool with no output schema, the description covers the essential context: what it does, format constraints, and a safety check. It is nearly complete but omits return behavior and focus requirements, which are minor gaps for this tool type.

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

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

Schema coverage is 50% because the required 'text' parameter has no schema description. The description compensates by explaining escape sequences and the ASCII-only constraint for that parameter, adding meaningful semantics beyond the schema. It does not elaborate on delay_ms, which the schema already documents.

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: 'Types text on the host keyboard'. The scope is clear, but it does not distinguish itself from the sibling press_keys tool, which likely also sends keyboard input, so an agent must infer which one applies to string typing versus key combos.

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 prerequisite ('Take a screenshot first') tied to a real failure mode (locked screen), which is clear usage context. It does not, however, state when to prefer this over press_keys or other input tools, leaving the alternative implicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses the blocking/synchronous nature, the timeout escape hatch, and that a screenshot is returned, but omits failure modes (error vs. current screen on timeout), any session/KVM connection prerequisite, and whether the returned image is pre- or post-change.

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

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

Two tight sentences with the core behavior front-loaded and the usage guidance 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?

For a two-optional-parameter, no-annotation, no-output-schema tool, the description covers the essential contract: it blocks, it can time out, and it returns a screenshot. Only edge-case behavior on timeout and connection prerequisites are left implicit.

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 schema already documents both parameters and their defaults, giving a baseline of 3. The description mentions 'timeout' in passing but adds no meaning for min_changed_fraction or tuning guidance for either parameter.

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

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

States a specific verb and resource ('Blocks until the host screen changes noticeably') plus the outcome ('then returns a screenshot'), which cleanly differentiates it from the sibling 'screenshot' tool that presumably returns immediately.

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

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

Gives concrete usage context: 'Use after actions that take time (boot, install steps, page loads).' Clear positive guidance, but no explicit exclusions or named alternative (e.g., 'use screenshot instead if the screen is already stable').

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