render_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. It discloses the output (PNG at authored size) and frames the tool as a visual checkpoint within an iterative process, implying it is non-destructive. However, it does not explicitly state that no changes are made to the canvas or clarify any potential limitations (e.g., resolution constraints), which would further enhance transparency. The strong feedback-loop context earns above-average credit.

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 tight and efficient: three sentences that immediately state the primary operation, then add workflow context and an alternative. Every clause earns its place, with no filler or redundancy.

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 single-parameter rendering tool without an output schema, the description is remarkably complete. It explains the output format (PNG), the purpose (visual layout check), how to integrate it into an iteration cycle, and when to prefer a sibling tool. No critical context is missing.

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 schema description coverage at 0%, the description must compensate. It does not mention page_id at all, leaving its meaning and format entirely to the schema's 'Page Id' title. While the parameter's name is intuitive, the description adds no semantic value or usage hints, making this a gap given the low coverage.

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 tool's function: 'Render the canvas to a PNG at its authored size and return the image.' It specifies the resource (canvas), the action (render to PNG), and distinguishes from the sibling render_report by contrasting the visual image output with machine-readable checks.

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?

It provides explicit guidance on when to use this tool—as part of an iterative feedback loop ('place → render_preview → adjust → set_canvas → render_preview again')—and explicitly names an alternative for different needs: 'use render_report()' for machine-readable checks. This exceeds simple descriptions and directly addresses tool selection.

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