Server Quality Checklist

Tool Scores

• generate_pdf_from_htmlC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'using Puppeteer' which hints at browser-based rendering, but doesn't disclose critical behaviors like whether this is a blocking/long-running operation, error handling, file system impacts, or authentication needs. For a tool that generates files with 4 parameters, this is insufficient.

  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 directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward conversion tool and front-loads the core functionality. Every word earns its place.

  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?

  For a tool with 4 parameters, nested objects, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after generation (where the file goes, return values), error conditions, performance characteristics, or how it differs from sibling tools. The 100% schema coverage helps but doesn't compensate for missing behavioral context.

  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 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions 'HTML content' and 'PDF' which aligns with parameters but doesn't provide additional context about format requirements, constraints, or usage examples.

  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 clearly states the verb 'Generate' and resource 'PDF from HTML content', specifying the conversion purpose. It distinguishes from siblings by mentioning 'HTML content' (vs. markdown/text for other tools) and 'using Puppeteer' as the implementation method. However, it doesn't explicitly contrast with sibling tools like 'read_pdf'.

  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?

  The description provides no guidance on when to use this tool versus alternatives like 'generate_pdf_from_markdown' or 'generate_pdf_from_text'. It doesn't mention prerequisites, constraints, or typical use cases. The only implied usage is converting HTML to PDF, but no context for choosing between sibling tools is given.

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

• generate_pdf_from_markdownC
  2.9/5.0
  Behavior2/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. It states the tool generates a PDF but doesn't describe what happens during generation (e.g., file creation, overwriting behavior, error handling), permissions needed, or rate limits. For a tool that creates files, this is a significant gap in 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?

  The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or redundancy are present.

  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 (file generation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, file path), error conditions, or behavioral details. For a tool that creates output files, this leaves significant gaps for an agent.

  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 fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't compensate with additional context about parameter interactions or constraints.

  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 clearly states the tool's purpose: 'Generate a PDF from Markdown content' - a specific verb (generate) and resource (PDF from Markdown). It distinguishes from sibling tools like generate_pdf_from_html and generate_pdf_from_text by specifying the input format. However, it doesn't explicitly contrast with read_pdf, which serves a different purpose.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose markdown over HTML or text for PDF generation, nor does it address prerequisites or exclusions. The agent must infer usage from the tool name alone.

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

• generate_pdf_from_textC
  2.9/5.0
  Behavior2/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. It states the tool generates a PDF but doesn't mention critical behaviors: whether it overwrites existing files, requires specific permissions, handles errors, or what the output looks like (e.g., file path). For a tool that creates files, this lack of transparency about side effects and outcomes is a significant gap.

  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: 'Generate a PDF from plain text using PDFKit'. It's front-loaded with the core purpose, uses no unnecessary words, and clearly communicates the essential action. Every part of the sentence earns its place by specifying the output (PDF), input (plain text), and method (PDFKit).

  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 complexity (4 parameters including nested objects, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like file creation side effects, error handling, or output details. For a tool that generates files, more context is needed about what happens after invocation, especially without annotations or output schema to fill these 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 schema already documents all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. It doesn't explain parameter interactions, provide examples, or clarify semantics like what 'plain text' entails versus HTML/markdown. The baseline score of 3 reflects adequate schema coverage without description enhancement.

  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 clearly states the tool's purpose: 'Generate a PDF from plain text using PDFKit'. It specifies the verb ('Generate'), resource ('PDF'), and source format ('plain text'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like generate_pdf_from_html or generate_pdf_from_markdown, which handle different input formats.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (generate_pdf_from_html, generate_pdf_from_markdown, read_pdf) or specify scenarios where plain text conversion is preferred over other formats. There's also no information about prerequisites or constraints, leaving usage context unclear.

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

• read_pdfB
  3.1/5.0
  Behavior2/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. It states the tool reads from disk and returns text content, but doesn't mention error handling (e.g., what happens if the file doesn't exist or isn't a PDF), performance characteristics, or any limitations (e.g., file size constraints, text extraction accuracy). This leaves significant gaps for a tool that interacts with the filesystem.

  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 exactly what the tool does. It's front-loaded with the core action and includes the key details (source and output). There's no wasted language or unnecessary elaboration.

  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?

  Given the tool's moderate complexity (filesystem interaction, PDF parsing) and lack of annotations/output schema, the description is minimally adequate. It covers the basic operation but lacks details about error conditions, performance, or output format beyond 'text content'. For a tool with no structured safety or output information, more behavioral context would be helpful.

  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 fully documents the single parameter 'file_path'. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage, the baseline is 3 even with no param info in the description.

  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 clearly states the tool's purpose with specific verb ('Read') and resource ('PDF file'), and specifies what it returns ('text content'). It doesn't explicitly distinguish from sibling tools, which are all PDF generators rather than readers, so it's clear but lacks explicit sibling differentiation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tools (all PDF generators) or any other context for usage decisions. The agent must infer usage from the tool name and description alone.

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