Server Quality Checklist

Tool Scores

• optimize_imageA
  4.2/5.0
  Behavior4/5

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

  The annotation 'readOnlyHint=true' is consistent with fetching and re-encoding without modifying the source. 'openWorldHint=true' aligns with fetching from a public URL. The description adds value beyond annotations by specifying the return of before/after sizes and the network access, providing helpful 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.

  Conciseness5/5

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

  The description is extremely concise, using two sentences to convey purpose, output, and usage guidance. Every sentence adds value without redundancy.

  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?

  Given the absence of an output schema, the description adequately explains the return value ('optimized image plus before/after byte sizes'). It covers the core functionality well, though it could briefly specify the return format (e.g., if it includes a URL or base64 data).

  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 baseline is 3. The description adds minimal extra meaning—only mentioning 'public URL' for 'image_url' and 'resizing to target width' for 'width'. The 'format' and 'quality' parameters are not elaborated beyond the schema, so no additional value is provided.

  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 ('fetch', 're-encode', 'resize'), the resource ('image from a public URL'), and the output ('optimized image plus before/after byte sizes'). It effectively distinguishes the tool from siblings like 'image_format_savings' by focusing on optimization rather than comparison.

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

  Usage Guidelines4/5

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

  The description provides explicit usage context: 'Use this when an AI-generated or dropped-in asset... is too large to ship.' However, it does not mention when not to use it or reference alternatives, such as 'image_format_savings' for format selection without re-encoding.

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

• qr_codeA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true, so agent already knows it's safe. Description adds that output is 'crisp, dependency-free SVG', clarifying the return format. No contradictions. Does not disclose additional traits like rate limits or auth needs, but given simplicity and annotations, it's sufficient.

  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?

  Single sentence that efficiently conveys purpose and output format. No wasted words. Front-loaded with key information.

  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?

  The description covers what the tool does, the output format (SVG), and usage scenario. No output schema exists, but the description sufficiently describes the return. The 3 parameters are well-documented in schema. Minor gap: does not mention that text is required or max length, but that's in schema. Overall complete for a simple tool.

  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 schema already explains all parameters (ecc, size, text). The tool description does not add any extra information about parameters beyond what's in the schema. Baseline 3 is appropriate.

  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 clearly states the tool's function: encoding text or URL into a QR code SVG. Uses specific verb 'Encode' and resource 'QR code SVG', and distinguishes from sibling tools which are unrelated (image_format_savings, optimize_image, storage_capacity).

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

  Usage Guidelines4/5

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

  Provides context for use: 'paste straight into a page, deck or doc'. Does not explicitly exclude use cases or compare with siblings, but the sibling tools serve different purposes, so no exclusion is necessary. Lacks explicit 'when not to use'.

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

• image_format_savingsA
  4.5/5.0
  Behavior5/5

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

  The description fully explains the tool's behavior: it reports benchmark-derived savings and the HEIC conversion tax. It is a read-only operation (consistent with readOnlyHint) and provides all key behavioral details beyond annotations, including the qualitative metric (SSIM) implicitly referenced.

  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 two sentences, efficiently delivering core purpose, bonus feature, and use case. No redundant or vague language; each sentence earns its place.

  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?

  Given the simple parameter set (2 optional enums with defaults) and no output schema, the description fully covers what the tool returns (savings numbers) and includes a notable extra detail (HEIC tax). It is complete and self-sufficient for agent understanding.

  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?

  Both parameters are fully described in the schema with enums and defaults. The description adds context by naming the target formats and quality levels, but does not significantly extend the meaning beyond the schema. Baseline 3 is appropriate given 100% 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 tool computes file size savings of WebP, AVIF, and JPEG XL over JPEG at matched perceptual quality, and mentions the HEIC conversion tax. It explicitly frames the tool for justifying format choices, distinguishing it from siblings like optimize_image and storage_capacity.

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

  Usage Guidelines4/5

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

  The description advises using the tool to justify format choices when building a site or app. It does not explicitly state when not to use or provide alternatives, but the context and sibling tools imply its comparative purpose. The guidance is clear but lacks exclusion criteria.

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

• storage_capacityA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, confirming it's a safe read. The description adds value by noting corrections for OS/filesystem overhead and that it is 'Backed by Cleanor Labs measured per-item sizes,' which provides transparency beyond annotations. No contradictions.

  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?

  Three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, data source, and use cases. No redundancy.

  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?

  Given the tool's simplicity (2 parameters, no output schema) and three siblings, the description covers everything: what it does, how it works, and when to use it. No gaps.

  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% with both parameters described. The description adds meaning by linking 'storage_gb' to 'advertised storage size' and 'content' to 'photos or minutes of video,' reinforcing the enum values. No additional schema is needed.

  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 function: counting photos or video minutes that fit in a given storage size, with real OS/filesystem overhead. It uses specific verbs and resources (e.g., 'How many photos or minutes of video actually fit') and distinguishes from siblings like 'image_format_savings' and 'optimize_image'.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases: 'Use for realistic sample copy, dashboards, or "how many photos fit in 128 GB" answers.' It does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent.

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