Server Quality Checklist

Tool Scores

• pdf_cache_clearC
  2.6/5.0
  Behavior1/5

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

  With no annotations, the description carries full burden for behavioral disclosure, but it fails to mention side effects (e.g., whether clearing cache is destructive, if it impacts ongoing operations, or any permission requirements). The single sentence 'Clear the PDF cache' provides no insight into behavior beyond the action itself.

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

  Conciseness3/5

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

  The description is extremely concise at four words, which is efficient but arguably too brief. It front-loads the action but omits necessary context. While there is no redundancy, the brevity compromises completeness.

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

  Completeness2/5

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

  Despite having an output schema (not shown), the description does not explain any return values or post-conditions. The tool's context is minimal: it clears a cache, but an agent would benefit from knowing what happens after execution (e.g., success indication, number of cleared entries).

  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 input schema provides 100% coverage for the single parameter 'expired_only', including its type, default, and description. The description adds no additional meaning beyond what the schema already conveys, so the baseline of 3 applies.

  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 uses a clear verb ('Clear') and resource ('PDF cache'), effectively conveying the tool's primary function. However, it lacks specificity about what 'clear' entails (e.g., removing all cached files or just marking for invalidation). It distinguishes from siblings like pdf_cache_stats, which likely provides statistics rather than mutation.

  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?

  No usage guidance is provided. The description does not indicate when to use this tool (e.g., before reading fresh PDFs) or when not to use it (e.g., if cache is needed for performance). No alternatives or prerequisites are mentioned.

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

• pdf_render_pagesA
  3.5/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 full burden. It correctly warns that images are untrusted, which is a behavioral trait. However, it does not disclose other behaviors like caching, performance implications, or handling of large pages beyond what the clip parameter schema describes.

  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 front-loaded with a critical security warning and then states the purpose concisely. It is structured but slightly verbose due to the warning; however, every sentence serves a purpose.

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

  Completeness2/5

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

  Given the tool's complexity and lack of output schema, the description is incomplete. It does not specify how images are returned (e.g., base64, URLs), size limits, or whether rendering respects any transformation settings. The security warning is important but does not fill all contextual gaps.

  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 parameter descriptions in the schema are sufficient. The tool description adds no additional information about parameters beyond the schema, meeting the baseline expectation.

  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 'Render PDF pages as PNG images,' which is a specific verb-resource pair. It distinguishes from sibling tools like pdf_read_pages by specifying image output, and adds context about untrusted data.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives like pdf_read_pages. It provides security warnings but lacks context on scenarios where image rendering is preferred over text extraction.

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

• pdf_corpus_overviewA
  4.1/5.0
  Behavior4/5

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

  The description discloses security concerns (untrusted data) and caching/warming behavior (time budget, unprocessed docs), which are key behavioral traits. No annotations were provided, so the description carries full responsibility.

  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 includes a necessary but lengthy security warning, yet the core functionality is stated concisely. It is front-loaded with important context.

  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 high schema coverage and presence of an output schema, the description covers essential behavior. However, it omits the file cap (100 files) mentioned in the schema, which is a minor gap.

  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 baseline is 3. The description repeats the idea of 'folder or list' and 'time budget' but does not add significant extra meaning 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 specifies a clear verb ('Get') and resource ('per-document triage card') with scope ('every PDF in a folder or list'), and the tool is easily distinguished from siblings like pdf_render_pages and pdf_extract_chart.

  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 context on when to call again ('unready docs appear in unprocessed; call again to continue'), but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.

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

• pdf_extract_chartA
  4.1/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and covers key behaviors: untrusted content, exact coordinates, gate-checked readings with verification cards, handling of ambiguous charts, and the need to confirm flagged readings via render. It is highly transparent.

  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 front-loaded with a crucial security warning and then details the extraction behavior. It is somewhat long but efficient for the complexity. No wasted words.

  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 no output schema, the description explains the verification_card, render_path, and conditions for decline. It could be more explicit about return format but is largely complete for a specialized chart extraction 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 coverage is 100%, so baseline is 3. The description does not add per-parameter meaning beyond the schema's own descriptions. It provides global context but no additional param-specific details.

  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 it extracts exact (x,y) data series from born-digital vector charts, which is a specific verb and resource. It distinguishes well from sibling tools like pdf_render_pages that focus on rendering rather than data extraction.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or when-not-to-use guidance relative to siblings. The security warning provides important context but does not help select this tool over alternatives. Usage is implied by the tool's purpose but not explicitly contrasted.

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

• server_infoA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It discloses that the call is cheap (no I/O beyond reading process state), results are stable for the server's lifetime, and lists the exact return contents (version, per-feature availability, search mode list, active config values).

  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 multi-sentence but each sentence adds value: purpose, usage context, return details, cost, and stability. It is well-structured and efficient.

  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 zero input parameters and an output schema (though not shown), the description provides sufficient information about what the tool returns and its behavior. It is complete for an agent to use 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 parameters (0 params, 100% coverage). The description does not need to add parameter details, and it correctly focuses on the tool's purpose and output.

  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 reports which optional features are installed and what configuration is active. It distinguishes itself from sibling tools like pdf_info and pdf_cache_stats by being a server-level introspection tool.

  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 advises calling this first when using semantic search, OCR, or column-aware extraction, and explains the consequences of not doing so (fallback or error). This provides clear 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.