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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the agent knows this mutates guest state. The description adds the useful detail that the host pointer is untouched, which is behavior beyond the annotations, but it says nothing about what the click affects in the guest, coordinate origin, or default button.

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, front-loaded with the action and immediately followed by the key constraint. There is no filler, though the brevity comes at the cost of the missing parameter detail noted above.

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 destructive, four-parameter tool with zero schema description coverage and no output schema, the description is far too thin. An agent cannot determine click count, button, coordinate frame, or any prerequisite session state without guessing.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the semantics and largely does not. 'Guest pixel' weakly implies that x/y are pixel coordinates in guest space, but count (1 vs 2 clicks), button (left/middle/right), and default values are never mentioned.

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 target: 'Click a guest pixel', and adds a differentiating clause ('without moving the host pointer') that separates it from the sibling 'move' tool. It is clear what action occurs, though 'guest pixel' assumes knowledge of the guest/host coordinate split.

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 no explicit when-to-use guidance, no preconditions (e.g. whether a session must be started first via 'start'), and does not name alternatives such as 'move', 'type', or 'key'. The only implicit routing signal is the contrast with host-pointer movement.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's burden is lower, yet it adds nothing about effects — that a chord like ctrl+alt+delete can alter or lock system state, or what happens if the target window lacks focus. The examples are format guidance, not behavioral disclosure.

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

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

A single front-loaded sentence with compact, high-value examples and no filler. Every token 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 one-parameter tool with no output schema this is close to sufficient, but it omits where the keypress lands (focused window), platform-specific key names, and how it differs from typing text. Those gaps matter for correct invocation.

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

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

Schema coverage is 0% and "chord" has no type-level description, so the description carries the load by demonstrating the expected syntax ("win+r", "ctrl+a", "ctrl+alt+delete", "enter"). That is a meaningful addition beyond the bare string schema, though modifier ordering and valid key names are never stated.

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 concrete verb+resource ("Press a key or chord") and illustrates with real chord forms. It does not, however, distinguish this from the sibling "type" tool, so an agent must infer that "type" writes text while "key" emits a single keystroke or combination.

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

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

Usage is only implied by the examples; there is no explicit statement of when to call this versus "type" or when a chord is inappropriate. An agent can reasonably infer the intent, but nothing routes it away from the wrong sibling.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond them: it does not say whether coordinates are absolute screen pixels or guest-relative, what happens if x/y fall outside the guest resolution, or whether out-of-bounds values error or clamp.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient rather than padded, though the terseness leaves little structure for the agent to anchor on.

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

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

For a two-required-parameter input tool with no output schema and a destructive annotation, the description should at minimum pin down the coordinate frame and bounds behavior. As written, the agent knows what the tool does conceptually but not enough to call it correctly in a specific guest environment.

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

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

Schema description coverage is 0% for both required parameters, so the description carries the full burden. "To a pixel" hints that x and y are pixel coordinates, but gives no origin, no unit conventions relative to guest resolution, no valid range, and no note that both are mandatory.

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 pairs a specific verb ("Move") with a specific target ("the guest pointer") and an outcome ("to a pixel"), so an agent can tell it apart from click/scroll/type siblings without opening a schema. It stops short of explicitly stating the move does not click, which is the main disambiguation an agent needs against the nearest sibling.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., that the session must be started first), and no statement about whether a move must precede click or whether hovering has side effects. The agent must infer the tool's role from the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral context beyond that: the image reflects the real guest desktop and defines the shared pixel coordinate space used by the input tools, which is the critical fact for interpreting results. It omits freshness/timing (e.g., whether a delay is needed after an action before re-capturing).

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 filler, and the core capability is front-loaded ahead of the coordinate detail. Nothing could be removed without losing 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 zero-parameter, non-destructive capture tool with no output schema, the description covers what is returned (an image of the guest desktop) and how its pixel space maps to other tools' inputs. The remaining gap is refresh/freshness behavior after prior actions, which is minor given the tool's simplicity.

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?

Zero parameters, so the baseline of 4 applies. The description correctly adds no parameter detail and instead spends its words on coordinate semantics, which is the relevant information for a parameterless capture 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?

"See the real guest desktop" states the resource and action precisely enough for an agent to understand this captures a live view of the guest machine, and "this image" confirms an image is returned. It does not explicitly name a sibling, so differentiation from status is left implicit rather than stated.

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

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

The coordinate sentence implies the intended workflow: capture this first, then feed pixel coordinates to click/move/scroll. However, it never states that guidance directly ("call before click"), nor when not to use it or how often to refresh, leaving the agent to infer the sequencing.

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?

Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=true, but the description explains none of this — notably why a scroll is flagged destructive, whether it can trigger hover actions or change application state, or where the scroll is anchored. Beyond the annotations, the one sentence adds no behavioral context at all.

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

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

The single sentence is front-loaded and free of filler, but its brevity stems from under-specification rather than economy. There is no wasted wording, yet almost nothing is said.

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 state-changing automation tool with no output schema and zero parameter documentation, one four-word sentence is wholly inadequate. Nothing tells the agent what the call returns, what gets affected, or how to size a scroll.

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 carries the full burden and provides nothing: "steps" is undocumented in meaning, unit, and bounds (1–100), and "direction" values are only implicitly conveyed by the word "scroll". No default behavior when steps is omitted is described.

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?

"Scroll inside the guest" names a specific verb, but the object of the scroll and the meaning of "the guest" are never defined. An agent can infer it is a UI-automation scroll from siblings like click, move, and screenshot, yet nothing in the description distinguishes this tool's scope from those 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?

There is no when-to-use guidance, no mention of prerequisites (e.g., a running session or focused window), and no reference to alternatives among the eight siblings. The agent must guess the context in which scrolling is appropriate.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=true, so the agent knows this is a state-changing, externally visible operation. The description usefully adds that it will not provision or install an OS, which prevents a common misconception, but it never addresses the destructive flag, idempotency, or whether the call blocks until the VM is ready.

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

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

Two short sentences, front-loaded with the action and immediately followed by the key exclusion. No filler and nothing that could be trimmed without losing meaning.

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

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

For a zero-parameter action the description covers the essentials, and annotations carry the safety profile. It falls short on operational details an agent would want for an open-world, destructive operation: whether the call waits for readiness, what happens on an already-running VM, and what the return looks like (there is no output schema to fall back on).

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 and no risk of a parameter mismatch. The baseline for a no-parameter tool 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?

Names a specific verb (start) and resource (Windows VM) and scopes it with 'previously configured'. The opposite sibling (stop) is implicitly contrasted, though it is never named, so differentiation relies on the reader inferring it.

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 word 'previously configured' implies a prerequisite, and 'Does not create or install Windows' states one boundary. However, there is no explicit guidance on when to use this versus stop/status, no statement about behavior if the VM is already running, and no stated preconditions such as authentication or setup.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing beyond that: it does not say whether the call is cheap or slow, whether it polls a remote host (relevant given openWorldHint), or what the response contains. With no output schema, the description was the only place to disclose return shape and it does not.

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, and the key noun phrase is front-loaded after the verb. It is efficiently written; the brevity is a symptom of missing content rather than of wordiness, which is penalized under contextual completeness instead.

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

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

For a zero-parameter read tool, the surface area is small, so the description is almost adequate. The critical gap is that there is no output schema and the description does not describe what 'status' returns, leaving the agent unable to plan how to use the result – this is the one thing a status tool's description must supply.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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 pairs a specific verb ("Read") with a specific resource ("this VM's status"), which cleanly separates it from the action siblings (click, move, type, scroll, start, stop) that manipulate the VM rather than report on it. It stops short of 5 because "status" itself is undefined – an agent cannot tell whether this returns power state, health, connection info, or a full metadata blob.

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

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

There is no explicit when-to-use guidance, no mention of prerequisites, and no reference to any alternative or companion tool. The only hint is implied: an agent would infer it should call this before start/stop to check the VM's current state, but that inference is left entirely to the reader.

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?

Annotations already declare destructiveHint=true and openWorldHint=true; the description adds genuinely new behavioral information that this is a cooperative ACPI-style request and never a forced power-off, which qualitatively changes how an agent should reason about the risk. It still omits whether the call blocks until shutdown completes, timeouts, and what happens to running workloads, so it is not fully transparent.

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

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

Two short sentences, front-loaded with the action and immediately qualified by the most important constraint ('Never forces power off'). Nothing is wasted or padded.

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

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

For a zero-parameter tool with no output schema, the description covers the essential semantics of a graceful versus forced shutdown. It is only slightly short of complete because it does not say whether control returns immediately or after the guest actually stops, which matters for sequencing follow-up calls.

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 of 4 applies. The description correctly implies no arguments are needed to trigger a guest shutdown.

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 ('Request a graceful guest shutdown') and a clear resource (the guest), which is immediately distinguishable from the sibling 'start' and the observation tools like 'status'/'screenshot'. It stops short of naming a sibling explicitly, so it lands at 4 rather than 5.

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

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

Usage is only implied: an agent can infer this is the tool for shutting the guest down, but there is no statement of when to prefer it over other approaches, no prerequisite conditions, and no guidance on what to do if the graceful request is ignored. No exclusion or alternative is 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so safety is partially covered; the description adds genuine behavioral context by flagging the ASCII/US-layout restriction (non-ASCII input is a risk) and that the host clipboard is untouched. It does not say what happens on non-ASCII input, whether Enter is pressed, or how focus is established, so behavior under failure stays opaque.

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

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

Two sentences, front-loaded with the action and immediately followed by the distinguishing constraint. Nothing is redundant or padded relative to a one-parameter tool.

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

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

A simple tool with no output schema, so return values need no explanation. However, given destructiveHint=true, the description should clarify the irreversible side effects (typing into a focused app can submit commands) and the focus precondition; both 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?

With a single parameter at 0% schema description coverage, the description supplies the key semantic: the text must be US-layout ASCII, which is essential for correct invocation. The schema's maxLength of 20000 is not echoed or explained in the description, leaving chunking behavior for long text unaddressed.

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

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

States a concrete verb and target: 'Type US-layout ASCII into the guest's focused application,' and adds a negative scope claim ('Does not use the host clipboard') that distinguishes it from a paste-style operation. It stops short of distinguishing it from the sibling 'key' tool, which is the nearest ambiguity.

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: the clipboard note hints this is for text entry where clipboard usage is undesirable, and 'focused application' implies a focus precondition. There is no explicit when-to-use vs 'key' (single keystrokes, shortcuts, non-ASCII keys) and no statement of when to prefer the clipboard approach instead.

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