model_preview

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that the operation renders the current view to a PNG, but it does not disclose whether the PNG is returned directly, saved to disk, or how the output is delivered. It also does not mention side effects, requirements about an open/active document, or how 'current view' relates to camera state.

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 with no filler. Every word contributes meaning: the action, the resource, the output format, and the purpose are all present and concise.

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 no output schema and no annotations, the description should explain what the agent can do with the resulting PNG and any prerequisites for calling the tool. It does not clarify whether the function returns binary image data, a file path, or a URL, nor does it specify whether the document must be open or active. This leaves an agent uncertain about how to proceed after invocation.

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 the description needs to compensate. It references 'the document' but does not explicitly explain that document_id identifies which document to render. While the schema property title 'Document Id' provides basic clarity, the description adds only minimal context about the parameter's role.

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 specific verb ('Render'), a resource ('the document's current view'), and an output format ('PNG image'). The added purpose ('for visual verification') distinguishes it from related tools like export_model or inspect_model by clarifying its role as a preview mechanism.

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 phrase 'for visual verification' implies the intended use case, giving some context for when an agent might choose this tool. However, it does not explicitly state when to use it versus alternatives such as blueprint_view, export_model, or create_standard_views, nor does it mention exclusions or prerequisites.

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