view

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

Annotations already provide readOnlyHint=true, lowering the burden; the description adds operation semantics and notes that get_screenshot returns a PNG. However, it does not disclose the coordinate space for zoom_window (model/world vs screen), whether coordinates are effectively required despite schema null defaults, or what happens if coordinates are omitted or passed with other operations.

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 one-line purpose statement followed by three bullet-style operation lines; every sentence earns its place. The purpose is front-loaded, and each operation is a single scannable line with no redundant 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 dispatcher with an unconstrained operation parameter and no enums, the description supplies the critical operation vocabulary that the schema lacks, and the output schema presumably covers return values. However, it leaves notable gaps: coordinate semantics for zoom_window, whether coordinates are required for that operation, and whether the coordinate parameters should be null for the other two operations.

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 0% schema description coverage, the description partially compensates: 'zoom_window — Zoom to window: x1, y1, x2, y2' maps the four numeric parameters to the operation that consumes them, and the Operations list is the only source of valid values for the unconstrained operation string. But it leaves coordinate ordering, units, and coordinate system unspecified, and does not clarify that x1/y1/x2/y2 are effectively required for zoom_window even though the schema marks them optional with null defaults.

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 clear purpose ('Viewport control and screenshot capture') and enumerates three distinct operations, each with a specific verb, resource, and effect (zoom_extents, zoom_window, get_screenshot). It is immediately distinguishable from sibling tools like drawing, entity, or layer, which cover different AutoCAD domains.

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 operation list gives implicit selection guidance — zoom_extents for showing everything, zoom_window for a specific region, get_screenshot for capturing PNG output. However, there is no explicit when-to-use wording, no exclusions, and no stated alternative among the sibling tools; the domain separation from drawing/entity/layer/block is only implied by names.

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