Server Quality Checklist

Tool Scores

• printer_statusB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. The description says 'check' which implies a read operation, but it doesn't disclose whether there are side effects, what 'current configuration' reveals, whether transport state affects subsequent print calls, or any error conditions. For a status tool with zero annotation coverage, more behavioral disclosure would help.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that states the two aspects being checked (printer/transport status and current configuration). Zero waste, appropriately brief for a zero-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (0 params, no output schema), so the description doesn't need much. However, with no output schema and no annotations, the description could clarify what information comes back (device name, connection state, queue length, etc.) to help an agent know what to expect. Adequate but could be more informative about the return value.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters, the baseline is 4 per the rubric. There are no parameters needing documentation, and the description correctly implies the tool takes no input and simply returns current state. Nothing to add here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource goal: 'Check printer/transport status and current configuration.' It distinguishes from siblings (preview_html, print_html, etc.), which are about rendering/previewing output, while this tool inspects status. However, it could be more specific about what 'status' includes, though 0 params means no scope ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool vs the print/preview siblings. Given the sibling set (preview_html, print_html, etc.), it's only implied that this is a diagnostic/config tool rather than a rendering operation. No explicit when-to-use or exclusions are provided.

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

• preview_markdownA
  4.1/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• preview_htmlA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden. It clearly reveals the preview/print behavioral trait (returns exact printed output, no physical printing), explains rendering details (1-bit, dithering), and discloses capabilities like QR generation and remote image support. This is rich behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat long but every sentence earns its place: it describes output fidelity, canvas dimensions, style support, special features, and usage guidance. The key differentiator ('Render... WITHOUT printing') is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-param tool with no output schema and no annotations, the description is thorough. It covers canvas specs, supported features, QR generation, mode selection, and ties to design_guide and print_html. Minor gap: no mention of return value format (image data vs URL), but overall it's quite complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema documents all three parameters. The description adds meaningful value by explaining the html canvas spec (58mm, 384px wide, unlimited height), the QR data attribute feature, and clarifying mode/algorithm semantics (auto detects photos vs text, bayer gives halftone look). This goes beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource ('Render ticket HTML WITHOUT printing') and clearly distinguishes from the sibling print_html by emphasizing the preview-only behavior. It also explicitly notes it returns the exact 1-bit printed image, making its functional scope unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance: 'always preview before print_html', directly telling the agent when to use this tool relative to its sibling. It also instructs calling design_guide first or reading the thermal-print skill, adding clear context for proper usage.

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

• print_htmlA
  4.5/5.0
  Behavior4/5

  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 richly discloses behavior: 384px canvas, 1-bit black & white output, dithering support, data-qr feature, remote images/fonts supported. It doesn't state physical paper size (58mm implied), tearing behavior, or possible failure modes, but covers the major behavioral aspects thoroughly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Front-loaded with the core sentence, then layered technical details. It's a substantial paragraph but every sentence adds value—rendering constraints, dithering, QR, and guidelines are all non-redundant. Dense but justified given the complexity of a rendering tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  A complex tool (4 params, dithering, QR, rendering constraints) yet the description covers rendering canvas, output format, image handling, QR generation, mode/algorithm defaults, and guidance pointers. No output schema exists, but it accurately describes rendering behavior. Minor gaps: no physical print behavior details (paper, tearing) beyond feed_lines, and no error possibilities.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds substantial value beyond the schema: explains color/grayscale dithering quality, notes 'auto' keeps text razor-sharp, describes the data-qr replacement mechanism, and explains algorithm aesthetics (crisp vs smoother vs newspaper look). This adds depth beyond enum names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Specific verb+resource: 'Render ticket HTML and print it on the thermal printer.' Clearly distinguishes from siblings (preview_html just previews, print_markdown handles markdown). The purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Tells the agent to 'Preview with preview_html first,' explicitly names the alternate preview tool, and instructs calling design_guide for fonts/layout guidance or the thermal-print skill. Sibling differentiation is clear: preview before printing.

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

• print_markdownA
  4.5/5.0
  Behavior4/5

  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 disclosing behavior. It thoroughly describes features (code fences, mermaid, LaTeX math, checkboxes, tables, remote images) and the built-in minimalist stylesheet, plus important constraints on continuous flow (incomplete chunks rejected, FEED button instructions). Notable disclosure of type-size readability tradeoffs. Minor gap: no mention of where output physically goes beyond 'thermal printer', but the tool name and print terminology cover that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but front-loaded with the core purpose in the first sentence. The markdown param description is long but each clause adds genuine behavioral value (advanced features, stylesheet specifics, pointers to alternatives). The flow and size explanations are thorough but tightly written. Slightly long overall, yet every sentence earns its place given no annotations exist.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema and no annotations, so the description alone must cover complexity. For a tool rendering arbitrary markdown with advanced features (mermaid, LaTeX), it explains the styling and feature set well, covers all four parameters, and names alternatives and prerequisites. Missing only a note on what the return/result looks like (e.g., printed confirmation), but for a printing tool this is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so params are already documented. The description adds value through guidance beyond the schema: recommending 'medium' as the default size with clear when-to-use guidance for large/small, and explaining the continuous flow behavior (zero margins, no trailing feed, joining chunks). The feed_lines param default behavior in continuous flow is also clarified. Not a full 5 because the markdown format doc essentially mirrors the schema, but combined schema+description form a coherent picture.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states specific verb+resource ('Render markdown... and print it on the thermal printer') and clearly scopes behavior to the built-in ticket style. It explicitly distinguishes from sibling print_html for custom design, matching the sibling tool names in the context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly frames when to use this tool ('Quick path for notes/lists/receipts') and gives an exclusion with the alternative ('use print_html for custom design'). The markdown param description also reinforces this with 'Fastest way to print; use the html tools for full custom design' and 'Call design_guide first for size/style guidance.'

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

• design_guideA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It describes what the tool returns (the full design guide) and lists its contents: the two paths, type-size tiers, font/icon library, graphics helpers, house style, and layout best practices. It also discloses the client-agnostic behavior. It does not explicitly state that the tool is read-only, but the nature of 'Returns' implies no side effects, making this a strong but not perfect disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each earning its place. The first sentence is a directive, the second lists the guide's contents, and the third addresses a potential client-specific caveat. It is front-loaded with the most important instruction ('Read this FIRST') and contains no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description provides a complete picture: what the tool does, what it contains, when to use it, and a client-specific caveat. It fully covers the purpose and usage, and the absence of output schema means no return-form documentation is needed. The description is sufficient for an agent to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter details, but it adds context about what the guide contains, which is relevant for the user's decision to call the tool. The schema adds nothing since it is empty, so the description compensates appropriately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: to return the full design guide for thermal tickets. It uses a specific verb ('Returns') and distinguishes itself from sibling preview/print tools by positioning itself as the prerequisite guide, explicitly saying 'Read this FIRST before designing any thermal ticket.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use this tool: 'Read this FIRST before designing any thermal ticket.' This is a direct usage directive that tells the agent to use this tool before any other design-related actions. It also notes the client-agnostic nature, clarifying it works in Claude Desktop where the Claude Code skill is not loaded, which adds important context for invocation.

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