preview_markdown

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key behavior (renders exact 1-bit image without printing) and that incomplete continuous-flow chunks are rejected before printing. However, it doesn't state what the return value/preview output looks like (since there's no output schema), nor side effects or limits. It covers the most critical behavioral facts but leaves return-format details unspecified.

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 front-loaded with the core purpose verb and constraint (render WITHOUT printing), immediately followed by the preview-before-print guidance. The extra context is pushed into the schema parameter descriptions rather than repeated. Slightly verbose only because of rich semantic content, but every sentence earns its place.

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 3 parameters fully described in schema (incl. enums and recommended defaults), no output schema, and rich parameter docs covering size guidance, flow modes, and markdown features, the description adds the critical preview-vs-print distinction and points to design_guide. It's reasonably complete; the only gap is the unspecified return/preview output format, but the title 'preview' plus the description strongly imply the rendered image is returned.

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 100%, so the schema already documents all three parameters in detail. The description adds a useful note about being the fastest way to print and pointing to html tools for full custom design, but it largely relies on the schema's already-rich parameter descriptions for the markdown, flow, and size semantics. Baseline 3 is appropriate given full schema 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 verb (render/preview), the resource (markdown), and the key distinction: it renders WITHOUT printing to show the exact 1-bit image before print_markdown. This directly distinguishes it from the sibling print_markdown tool while expressing the core purpose precisely.

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 explicitly warns against printing ("preview before print_markdown"), tells users to call design_guide first for size/style guidance, and the schema's flow/size params carry detailed usage guidance (RECOMMENDED medium default, when to use large/small, when to use continuous vs ticket mode). This exceeds baseline expectations for when-to-use guidance.

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