computer_drag

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 describes the mechanical action (press, move, release) and that it returns a JSON response, but does not mention side effects, prerequisites (e.g., device connection, permissions), whether it blocks, or error conditions. It also does not clarify if the drag triggers events or if coordinates are absolute relative to the screen origin. This is minimal behavioral information.

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 and front-loaded with the core action in the first sentence. It then lists arguments and returns in a clean structure. Every sentence serves a purpose, with no filler or redundant information. The formatting is easy to parse for an agent.

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 has 5 required parameters and no annotations, so the description is the only source of operational context. It covers the action and parameters adequately, but omits when to use it (usage guidelines), potential error cases, and any sequence dependencies (e.g., ensuring a device is connected). Given an output schema exists, the return format is sufficiently disclosed, but overall the agent is left without enough context to decide when and how to invoke it safely beyond the basic mechanics.

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

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

Given the input schema has 0% description coverage, the description effectively compensates by explaining each parameter: serialno is from list_devices, and coordinates are 'screen pixels.' It adds meaningful context beyond the bare type definitions. However, it does not specify the coordinate origin (e.g., top-left corner) or whether coordinates are relative to the primary display, which is a minor 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 clearly states the action: 'Press the left button at one point, move to another, and release.' This unambiguously describes a drag operation with a start and end point, distinguishing it from siblings like computer_click (press and release at same point), computer_move (move without pressing), and computer_scroll. The verb 'drag' is implicit but the action is specific and self-explanatory.

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 does not provide any guidance on when to use this tool versus alternatives. It neither mentions contexts (e.g., dragging files, windows, or selecting text) nor excludes scenarios better suited for computer_move, computer_click, or other sibling actions. An agent must infer usage purely from the tool name and action, which is insufficient.

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