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

Beyond the accessible readOnlyHint and destructiveHint annotations, the description discloses that it returns both an image/svg+xml content block and raw SVG text, and that AI-authored items are visually marked with a purple border. It also sets accurate size expectations (a few kB) that help the agent predict the response type and size.

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 front-loaded with the core output characteristic, then adds actionable usage guidance, a critical visual differentiator, and an alternative-tool pointer. Every sentence contributes meaningful selection or invocation information, with no wasted prose.

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?

Given no output schema, the description adequately fills in what the tool returns (SVG image block and raw text), the visual format, and why an agent would call it. It orients the agent within the larger tool family and provides enough behavioral detail to make a confident selection and invocation decision.

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?

The schema already fully documents `access_key`, and `board_id` is straightforwardly identified by the tool name and preview context. The description adds little parameter-level meaning beyond that, but given only two parameters and one requiring no special semantics, the gap is acceptable.

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 this tool renders a compact schematic SVG of the board and distinguishes it from `get_board` by noting that `get_preview` is for visual/spatial understanding while `get_board` is preferred for precise text content. The verb+resource pair is specific: it shows/serves board preview, not general board data.

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 gives explicit use cases: use it before placing new items, before deciding whether the canvas is crowded, and before picking a free region. It also names an alternative, `get_board`, for precise text needs, providing clear when-to and when-not-to guidance.

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