cad_view

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

The annotations declare readOnlyHint=false and idempotentHint=false, indicating a non-idempotent mutating operation, but the description doesn't explain what gets modified (e.g., view state vs. drawing data), whether changes are persistent, or what side effects occur. With annotations claiming a non-read-only operation, the description should clarify the behavioral implications, such as whether 'capture' creates a file or 'regen' forces recalculation. This gap is significant for a tool with 8 parameters and no output schema.

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 a single, front-loaded sentence that efficiently lists capabilities without waste. However, it's overly broad and lacks structure to guide correct invocation, such as grouping actions by type or specifying required parameters per action. It's concise but under-specified for the tool's complexity.

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?

With 8 parameters, 0% schema coverage, no output schema, and non-idempotent annotations, the description is inadequate. It doesn't explain parameter requirements per action, return behavior, or how to handle errors or view state persistence. The agent lacks necessary context to call this tool correctly, especially for actions like 'capture' that might produce output files or 'regen' that might alter the CAD model.

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 all 8 parameters are undocumented in both the schema and the description. The description lists action types but doesn't explain how to use parameters like 'path', 'delta', 'width', 'height', 'window', 'handles', or 'viewName' in conjunction with specific actions. For example, it doesn't clarify that 'setView' requires 'viewName' or that 'zoomWindow' requires 'window' coordinates. This leaves the agent guessing about parameter semantics.

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 uses specific viewport-navigation verbs (zoom, pan, orbit) and names the resource implicitly through the CAD context. This distinguishes it from siblings like cad_draw or cad_edit, which perform mutation operations rather than view changes. However, it doesn't explicitly differentiate from cad_layout, which also involves view configuration, leaving some 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?

The description provides implied usage by listing actions that map to the action enum, suggesting this tool is for visual navigation. However, it lacks explicit when-to-use guidance versus alternatives like cad_layout or cad_command, and offers no exclusions or prerequisites. An agent must infer that this is for viewport manipulation rather than model mutation.

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