nanokvm_move

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

No annotations are provided, so the description must carry the burden. It does add useful context by defining the coordinate origin (0 = left edge, top edge), which clarifies the coordinate system. However, it does not disclose any potential side effects (e.g., whether the move is instantaneous, whether it affects the physical mouse, or whether there are any state changes beyond cursor position). For a simple operation, the absence of warnings is not critical, but the description could be more explicit about the behavior's scope.

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 exceptionally concise: a single active sentence followed by two parameter definitions. Every sentence earns its place, and the main action is front-loaded. No redundant wording or unnecessary details.

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

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

Given the tool's simplicity, the description is nearly complete. It covers the core operation and parameter semantics adequately. An output schema exists, so return values need not be explained. The only missing elements are edge-case behaviors (e.g., handling of out-of-range coordinates) and precise units, but these are not critical for a basic move operation. Overall, the description provides sufficient context 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?

The input schema lacks descriptions for x and y (0% coverage), and the description compensates by explaining that x is the X coordinate with 0 at the left edge and y is the Y coordinate with 0 at the top edge. This adds meaning beyond the bare schema. However, it does not specify units (e.g., pixels), valid ranges, or behavior when out of bounds, which limits the compensation.

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 function: 'Move mouse cursor to absolute screen position.' It specifies the verb (move), the resource (mouse cursor), and the scope (absolute screen position), which immediately distinguishes it from the sibling tool nanokvm_move_relative. There is no ambiguity about what action is performed.

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

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

There is no guidance on when to use this tool versus alternatives. While the phrase 'absolute screen position' hints at a contrast with relative movement, no explicit comparison is made, and there is no mention of when not to use it or which sibling tools to prefer in different contexts. The description relies entirely on the agent inferring usage from the operation name.

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