app_canvas

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

No annotations are provided, yet the description carries the full behavioral burden: it distinguishes click vs drag, explains the stepwise drag motion (jump reads as click at destination), discloses there is no read-back at all, and prescribes a bridge read to confirm effects. This is unusually rich disclosure for a gesture 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?

Front-loaded with the core action, then behavior, then the read-back caveat—well ordered. Slightly wordy in the 'no named controls / there was no way to make one' passage, which restates the same point twice, but nearly every sentence contributes.

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?

An output schema exists, yet the description adds the crucial caveat that the reply reports only the gesture, not its effect, which an agent would otherwise miss. Drag semantics and the verification path are covered; only the `double` gesture is left unexplained, which keeps it just short of 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 0% and titles are bare, so the description must carry meaning. It clarifies x/y as screen coordinates and to_x/to_y as a drag target with stepwise motion, but leaves the `double` boolean completely undocumented in both schema and description—a meaningful gap since double-click is a distinct gesture.

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 set (click/drag) on a specific resource (editor canvas) at screen coordinates, and explicitly contrasts itself with siblings: the canvas has no named controls, so 'every other tool here could not touch it.' An agent can tell this apart from app_invoke_element/obj_select without reading either 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?

Clearly explains when to reach for this tool (canvas has no named controls, so pointer gestures are the only route) and points to a 'bridge read' for verification instead of this tool. It doesn't explicitly say to prefer app_invoke_element when a named control exists, so the exclusion is implied rather than stated.

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