Server Quality Checklist

Tool Scores

• ReadMassiveEstimateA
  4.3/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. It discloses that images are NOT returned, that the tool reports per-model estimates, and includes the cost. It explains the compression_ratio semantics. However, it does not mention error behavior, invalid-path handling, or any limitations, which keeps it just shy of a 5.

  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 structured with clear sections and uses a concise, front-loaded summary. The instructions are purposeful and not redundant. It is slightly longer than necessary but every part adds value, justifying a 4 rather than a 5.

  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 simple schema (1 param) and the presence of an output schema, the description covers the tool's purpose, usage, return format, and interpretation well. Minor omissions like error cases and concrete examples prevent a 5, but the description is complete enough for an agent to invoke the tool correctly.

  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?

  The schema provides only a name and type for 'paths' (string or array). The description adds 'A single file path or a list of file paths,' which clarifies the semantic meaning slightly but does not specify path formats, file type restrictions, or how paths relate to the estimation output. For a single trivial parameter, this is adequate but not rich.

  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 explicitly states the tool's function: 'Report text-vs-image token counts, compression ratio, and dollar cost per model — WITHOUT returning the images.' The verb 'Report' and the resource (token counts/cost) are specific, and it clearly distinguishes itself from ReadMassive by noting it avoids returning pixels.

  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 provides explicit when-to-use guidance: 'USE THIS FIRST to decide whether reading a file as a packed image is worth it, before spending context on the pixels via ReadMassive.' It also gives a clear exclusion: if compression_ratio < 1, 'just read the file normally.' This names the alternative tool and the decision rule.

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

• ReadMassiveA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the image-based output, the symbol encoding, blank-line omission, line wrapping, truncation reporting, caching by path+mtime, and concurrent rendering, far exceeding a basic read-only statement.

  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 long but highly structured, with a front-loaded summary followed by clearly tagged sections: how_it_works, symbols, how_to_read, when_to_use, and optimal_strategy. Every section contributes necessary operational detail, especially the symbol decoding rules and the admonition to view the image directly rather than OCR it. There is no redundant filler.

  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 three parameters, no output schema, and a complex image-based return format, the description is remarkably complete. It covers the return value, how to interpret the image, symbol reconstruction, line-number citation, truncation behavior, caching, cost estimation, and model compatibility caveats. An agent has everything needed to select and invoke the tool correctly.

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

  Parameters5/5

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

  Although the JSON schema provides no field descriptions, the 'Args' section documents all three parameters: paths accepts a single path or list, max_pages_per_file is a truncation safety cap that reports rather than silently omits content, and include_summary controls a cost summary prefix. This fully compensates for the 0% 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 opens by naming ReadMassive as a token-efficient replacement for the built-in Read/ReadFile tool and states its exact behavior: rendering files to compact, line-numbered PNG images for a high-resolution vision model. It clearly identifies the resource (file paths) and action (read/render), and positions itself against the built-in Read tool and the ReadMassiveEstimate sibling.

  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 'when_to_use' section provides explicit 'CHOOSE ReadMassive when ALL hold' and 'PREFER A NORMAL TEXT READ when ANY hold' criteria, including model type, file size, and multi-file loading. It also names ReadMassiveEstimate as a pre-check and lists high-value use cases, giving concrete guidance on when to use this tool versus alternatives.

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

• ReadMassiveTextA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses the tool's behavior: it returns an image with a specific packed, line-numbered layout (explaining ¶, N│, and →), warns against OCR, notes that truncation is reported never silent, and explains the summary option. It also instructs the agent to read the image directly as actual content, covering both output format and consumption method.

  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 front-loaded with the core purpose in the first sentence, then provides terse, high-value instructions in the <instructions> block. Every sentence serves a purpose — when to use, output decoding, sibling distinction, truncation handling, and the Args block adds parameter semantics without 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 absence of an output schema, the description thoroughly explains the return format (base64 PNG images), the visual layout and decoding rules, truncation reporting, and the optional summary. Along with default values in the input schema, the description leaves no significant gaps for an agent to select and invoke the tool correctly.

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

  Parameters5/5

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

  The input schema has no property descriptions (0% coverage), so the description's Args block carries the full explanatory burden. It adds meaningful per-parameter semantics: text is 'the text to render', title is 'a label drawn in each page's header band', max_pages is 'safety cap on pages; truncation is reported, never silent', and include_summary 'prepends a token/cost summary'. This fully compensates for the missing schema descriptions.

  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 opens with a specific verb and resource ('Render an arbitrary text blob to densely-packed base64 PNG image(s)') and immediately distinguishes from the sibling ReadMassive ('use this only for in-memory text', 'Prefer ReadMassive when the content is a file on disk'). This makes the tool's purpose unambiguous and sets it apart from ReadMassive and ReadMassiveEstimate.

  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 <instructions> block explicitly states when to use the tool ('compress bulky text you are about to keep in context') and provides direct alternatives: 'Prefer ReadMassive when the content is a file on disk; use this only for in-memory text.' It also includes operational guidance about truncation and how to handle it (raise max_pages), satisfying both when-to-use and 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.