design_export_png

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

With no annotations, the description carries full behavioral burden and does disclose meaningful traits: rasterization uses local headless Chrome rather than Claude in Chrome, and serve_url is single-use and never persisted. However, it says nothing about failure modes, whether out_path is overwritten, permissions, or rendering side effects, leaving notable gaps for a file-writing 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-loads the core action and mechanism, then supplies concrete examples. Four compact sentences with no filler, though the mixed prose-plus-example formatting is slightly uneven rather than tight.

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?

Output schema exists so return values need no explanation, and the description covers the confusing inputs and the rendering mechanism. But with five parameters at 0% schema coverage and no annotations, an agent still lacks documented semantics for width/height and any guidance on output overwrite or error behavior.

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 must compensate, and it does for the two most ambiguous parameters: serve_url's origin/lifetime and scale's multiplicative behavior (440×956 at scale=3 → 1320×2868). out_path is illustrated via 'design/icon.png'. Only width/height are left merely implied by the example rather than stated.

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 ('Rasterize') and resource ('a Claude Design board') and explicitly disambiguates the mechanism from a similarly-named one ('with local headless Chrome (not Claude in Chrome)'). An agent can tell this apart from siblings like screenshot_capture or design_generate without opening the 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?

Concrete usage context is given: serve_url originates from mcp__claude-design__render_preview, implying this tool runs after a render step, and two example invocations (app icon, store layout check) show intended scenarios. No explicit when-not-to-use or named alternative tool is provided, so this is not a 5.

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