Server Quality Checklist

Tool Scores

• generate_reportA
  3.8/5.0
  Behavior3/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 the output is a base64-encoded PDF and lists included elements (TOC, headings, bookmarks, footers, tables, callouts). However, it does not mention potential limitations like file size, processing time, or error conditions (e.g., missing content).

  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 concise—a single sentence followed by a list of key features. Every element is relevant and directly helps the agent understand what the tool does. No unnecessary words or repetition.

  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 the return format (base64 PDF) and major output features (TOC, bookmarks, tables). Given the absence of an output schema, this is helpful. However, it could be more complete by mentioning error handling, required page margins, or content size limits to fully prepare the 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?

  The input schema has 100% description coverage for all 7 parameters, so the description adds no additional parameter information. The feature list in the description does not elaborate on parameter details beyond what the schema already provides.

  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 'Generate a professional multi-section report PDF', specifying the verb and resource. It lists features like TOC, headings, bookmarks, and footers, which distinguish it from sibling tools like generate_invoice, generate_from_markdown, and generate_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 implies usage for multi-section report generation with specific formatting features but does not explicitly state when to use this tool versus alternatives or provide any exclusions. It lacks guidance on scenarios where generate_from_markdown might be preferred.

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

• list_element_typesA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It states the tool returns a markdown reference but gives no detail about size, side effects, or authentication needs. The behavioral transparency is adequate but minimal for a read-only info tool.

  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?

  Two succinct sentences that are front-loaded and without filler. Every word adds value.

  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 tool's simplicity (no params, no annotations, no output schema), the description provides sufficient context: what it returns and when to use it. A minor improvement could be explicitly stating the output format, but it is not essential.

  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 input schema has zero parameters, and the description correctly adds no param info. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate here.

  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 that the tool returns a markdown reference of element types and properties, with a specific verb and resource. It distinguishes itself from sibling tools like generate_pdf by indicating its role as a preparatory step.

  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 explicitly advises using this tool before generate_pdf to understand available elements, providing clear context. It does not list exclusion scenarios, but the purpose is well-defined enough for an agent to infer when it is appropriate.

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

• generate_invoiceA
  4.4/5.0
  Behavior4/5

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

  Discloses behavioral traits beyond the schema: returns base64 PDF, currency symbols handling, tax column behavior, and IGST limitation. No annotations are present, so the description carries the full burden; it covers key aspects well.

  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: 7 sentences front-loaded with main purpose, then supplementary details. 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 tool's complexity (10 params, nested objects, no output schema), the description covers essential aspects: return format, supported currencies, tax behavior, and UPI QR. It is complete for an agent to use effectively.

  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?

  Adds meaning beyond input schema by explaining gst_rate usage, common Indian GST slabs, and UPI QR code embedding. With 100% schema coverage, the description enriches parameter understanding.

  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 generates a professional invoice PDF from structured data, specifying the return format (base64-encoded PDF) and key features. This distinguishes it from sibling tools like generate_from_markdown or generate_pdf.

  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 good context on when to use (structured invoice data, optional tax, multiple currencies) and notes a limitation (CGST/SGST routing not supported). However, it does not explicitly mention when not to use or compare with siblings.

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

• validate_documentA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It explains that validation returns immediately with errors, and that errors include structured path, message, and optional typo suggestion. No side effects are relevant.

  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?

  Two sentences, no filler. Front-loaded with purpose; efficient and clear.

  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 moderate complexity (2 params, nested object, no output schema), description covers validation behavior, error structure, and usage hint. Complete for its role.

  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% and description adds value: for 'document', it clarifies same shape as generate_pdf.document; for 'strict', it confirms default false and notes typo suggestions. Adds meaning beyond 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 the tool validates a pretext-pdf document schema without rendering, and contrasts it with generate_pdf. It distinguishes itself from siblings by being a cheap preflight check.

  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 explicitly recommends using this tool as a preflight check before generate_pdf. While it does not mention when not to use, the context makes the usage clear.

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

• generate_pdfA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses the return format (base64-encoded PDF bytes) and implies a non-destructive creation operation. However, it does not address authorization, rate limits, or error behavior. Still, key behavioral traits are covered.

  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: three sentences that efficiently convey purpose, differentiation, output format, and prerequisite. No unnecessary 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 the complexity of the nested document parameter and lack of output schema, the description provides essential context (base64 output, sibling tool references, element discovery). It is nearly complete, though error handling details are absent.

  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%, so baseline is 3. The description adds value by directing to call list_element_types for element shapes, which is critical context not present in the schema. This elevates it beyond the baseline.

  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 action ('Generate a PDF from a custom PdfDocument JSON descriptor'), provides concrete examples of use cases (resumes, contracts, etc.), and explicitly differentiates from sibling tools (generate_invoice, generate_report).

  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?

  Explicitly states when to use this tool vs alternatives ('Use this for any layout not covered by generate_invoice or generate_report') and advises calling list_element_types first, providing clear guidance on prerequisite and alternative selection.

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

• generate_from_markdownA
  4.7/5.0
  Behavior5/5

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

  Despite missing annotations, the description fully informs about behavioral traits: it notes that fenced code blocks are rendered as plain indented text (not styled monospace), output is base64-encoded PDF, and implicitly reveals safe read-only behavior. This exceeds expectations for an unannotated tool.

  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 concise (three sentences) and front-loaded with purpose. Every sentence earns its place: purpose, supported features, alternative, output format. No redundant information.

  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 complexity (many supported Markdown features) and absence of output schema, the description is remarkably complete. It covers input constraints, output format, key behavioral notes (code blocks), and provides a clear alternative.

  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 does not add new parameter-specific semantics beyond what the schema already provides, but it does not contradict or omit any necessary 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 'Convert a Markdown string to a PDF' with specific verb and resource. It distinguishes itself from sibling tool generate_pdf by specifying that generate_pdf offers richer layouts or styled code blocks, making the purpose unambiguous.

  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 when to use an alternative: 'For richer layouts or styled code blocks, use generate_pdf instead.' It also lists supported Markdown elements, implying appropriate usage contexts for this tool.

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