Server Quality Checklist

Tool Scores

• fetch_offerA
  3.9/5.0
  Behavior3/5

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

  Discloses headless browser rendering, which is useful. However, with no annotations, more details about output format or potential limitations would improve transparency.

  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?

  Concise and well-structured: purpose first, then usage, then technical note, then parameter. Every sentence is essential.

  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?

  Covers main aspects: purpose, usage context, technical details. With an output schema present, the description is sufficiently complete for a simple fetch tool.

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

  Parameters2/5

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

  Only one parameter (url) described as 'the job offer URL', which adds minimal value over the schema's type string. With 0% schema coverage, the description should elaborate on expected format or examples.

  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?

  Clearly states the action 'Fetch a job offer' from a URL, returning visible text. Distinct from sibling tools like generate_letter_pdf and load_cv.

  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?

  Explicitly says 'Use this when the user gives a link instead of pasting the offer', providing clear context. Also notes it works on JavaScript-heavy job boards, aiding selection.

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

• generate_letter_pdfA
  4.1/5.0
  Behavior3/5

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

  Discloses use of local Chromium and return of path, but does not mention if files are overwritten, error behavior, or permissions. With no annotations, the description carries the burden and is adequate but not comprehensive.

  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 separate sentences and an Args section. It is informative but could be shortened slightly; however, it effectively communicates key details without significant waste.

  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?

  Covers input modes, output format, and dependency (Chromium). No output schema, so the return value is explained. Missing error handling and file overwriting behavior, but for a focused tool, it is fairly complete.

  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 schema has 0% description coverage, but the description compensates by explaining each parameter: text (Markdown structure), letter_path (alternative input), output_path (save location). Adds meaningful context beyond the parameter 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?

  Clearly states it renders a cover letter in Markdown to an A4 PDF, identifying the specific resource (cover letter) and output format. The sibling generate_pdf is more generic, so this tool's focus on cover letters distinguishes it well.

  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 guidance on when to use text vs letter_path, and mentions it works without Word. However, it does not explicitly compare to the sibling generate_pdf, which could cause confusion about which to use for general PDF generation.

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

• load_cvA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description explains the key behavior: the photo is removed from the returned text and reattached later. It implies a safe read operation without side effects, though it does not explicitly state non-destructiveness.

  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 concise sentences plus a one-line Args section. Every sentence adds value: purpose, rationale, usage guidance, and parameter definition. 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?

  With an output schema available, the description does not need to detail return format. It adequately explains the transformation (photo removal) and usage context. Could mention that the output is YAML text, but the title implies it.

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

  Parameters2/5

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

  The single parameter cv_path has a minimal description ('path to the CV YAML') that adds little beyond the property name. Given 0% schema description coverage, more detail would be beneficial, though the default value is noted in 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 clearly states it returns the CV YAML with the photo removed, a specific verb-resource pair. It distinguishes from siblings (fetch_offer, generate_pdf) by focusing on loading CV data only.

  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?

  Explicitly tells when to use this tool (instead of opening the file directly) and why (photo is huge and useless). Also notes that the photo is reattached by generate_pdf, providing context for downstream usage.

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

• generate_pdfA
  4.4/5.0
  Behavior4/5

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

  No annotations exist, so the description bears full responsibility. It discloses the external dependency (notboringresume.cloud), the output behavior (writes to output_path, returns {path, overflows}), the overflow handling pattern, and the photo reattachment logic. However, it does not mention authentication requirements or error behavior if the external service fails.

  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 well-structured: a one-line purpose, output note, overflow guidance, then a clear 'Args:' list. Every sentence adds value; no redundancy. It is appropriately sized and front-loaded.

  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 has no output schema and no annotations, the description provides adequate context: explains the transformation, the parameters, the external service dependency, and the overflow retry logic. It does not require additional detail for typical use.

  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?

  Schema description coverage is 0%, yet the description fully explains all three parameters via an 'Args:' section. It provides purpose, defaults, and usage context for each (e.g., yaml′s role in tailoring, cv_path′s photo reattachment, output_path′s default). This fully compensates for the schema gap.

  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 first sentence clearly states the action: 'Render a YAML CV into a one-page PDF via notboringresume.cloud.' This specifies the verb (render), resource (YAML CV), and output (one-page PDF). It distinguishes from siblings like load_cv (which loads CV data) and generate_letter_pdf (letter PDF).

  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 provides internal usage tips (e.g., handle overflow by shortening YAML and retrying, omit yaml for a quick test) but does not explicitly differentiate from sibling generate_letter_pdf or state when to use this tool over others. The guidance is partially present but lacks cross-tool context.

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