Server Quality Checklist

Tool Scores

• generate_invoice_pdfA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must bear full burden. It discloses that save_path triggers file output, and that a hosted link expires in 7 days. However, it doesn't specify the impact of missing API key, confirmation of non-destructiveness, or any rate limits, leaving gaps.

  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 sentences, each adding essential information: purpose, mode selection, and configuration. No redundant or filler content; highly efficient.

  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 high complexity (21 parameters, nested objects, no output schema), the description is too brief. It lacks details on API key consequences, hosted link format, failure modes, and overall behavior, leaving an agent under-informed for correct invocation.

  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 input schema covers 62% of parameters with descriptions, but the tool description adds little beyond mentioning save_path. It does not explain the return behavior beyond the two modes, and does not clarify the meaning or interaction of many parameters (e.g., templates, color, payment info).

  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 PDF invoice', specifying both the verb and resource. It distinguishes from sibling tools by focusing on PDF output and mentions two modes of return (hosted link vs file), making its purpose specific and unambiguous.

  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 describes two distinct usage paths: default for chat (hosted link) and local file via save_path. Mentions the need for an API key for reliable output. While it doesn't directly compare to siblings, the differences are clear enough.

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

• generate_invoice_ublA
  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 the return type (XML as text) and the API key requirement. However, it does not mention any side effects, rate limits, or confirm that the tool is non-destructive. More behavioral context would be beneficial.

  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 two sentences, front-loading the core purpose and exclusions, then providing return type and prerequisite. Every word adds value, and no unnecessary detail is present.

  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 complexity (20 parameters, nested objects, no output schema), the description covers the essential return type and non-compliance caveat but lacks guidance on parameter usage, error handling, or the expected XML structure. It is adequate for a simple tool but incomplete for a complex one.

  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 description does not elaborate on any parameters, leaving all semantic value to the input schema, which has 60% coverage. The schema provides some descriptions, but the description itself adds no additional meaning for the remaining 40% of parameters. This is insufficient compensation.

  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 generates a UBL 2.1 XML invoice for interoperability/archival, and explicitly distinguishes from regulated e-invoice transmissions (Peppol/Factur-X/XRechnung). This uniquely identifies its purpose relative to siblings like generate_invoice_pdf and calculate_invoice_totals.

  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 notes when to use (for interoperability/archival) and when not (not for regulated compliance). It also mentions the prerequisite INVOVATE_API_KEY. However, it does not explicitly compare to sibling tools or provide alternative recommendations.

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

• calculate_invoice_totalsA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided; the description discloses it computes totals and does not render a file, but does not mention output format, side effects (none expected), or any rate limits. For a read-only computation, the transparency is moderate.

  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 concise sentences with no unnecessary words. The key information is front-loaded.

  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?

  The tool is complex (20 params, nested objects, no output schema). The description lists computed fields but does not explain calculation precedence, return value structure, or edge cases, leaving 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 60%, so the baseline is 3. The description adds no new parameter information beyond listing the computed fields (subtotal, discounts, etc.), which is helpful but not supplementary to 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 explicitly states 'Compute invoice totals ... without rendering a file' and contrasts with generating a PDF, making the purpose clear and distinguishing it from siblings like generate_invoice_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?

  It advises 'Use this to validate amounts before generating a PDF' and notes 'No API key required', providing good context. However, it does not explicitly state when not to use or list alternative tools.

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

• get_invoice_capabilitiesA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It correctly describes a read-only listing operation with no destructive or authorization concerns, though it could mention that it is a safe, idempotent call.

  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 two short, front-loaded sentences with no wasted words. Each sentence provides essential information about purpose and usage.

  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 parameters and no output schema, the description is complete. It explains what the tool returns and how to use it, and sibling tools provide additional context for when to invoke this one.

  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?

  No parameters exist, so the input schema is fully covered. The description adds value by specifying what the tool lists, which is sufficient.

  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 lists supported languages, PDF templates, and notable features for the Invovate invoice API, distinguishing it clearly from sibling tools that calculate or generate invoices.

  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 advises using this tool to pick valid language/template/currency values, providing clear context for its use. It does not explicitly state when not to use it or mention alternatives, but the sibling tools make the distinction clear.

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