Slipstack PDF

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

Annotations provide minimal info (no destructive/readonly hints). Description adds that validation occurs against official schematron and output is a 24-hour download URL plus totals, disclosing key behavior beyond annotations.

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

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

Three sentences, front-loaded with the main verb and standard. Efficient but could be more scannable with bullet points for extra fields.

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

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

Explains standard, extra fields, output (URL + totals), and validation. Lacks output schema but compensates with clear return description. Sufficient for a complex tool with nested objects.

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

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

Schema coverage is low (33%?), but description adds critical context: highlights e-invoice-specific fields (countryCode, vatId, paymentIban, etc.) and their conditions (e.g., vatId required when taxRate>0), going beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates EN 16931 e-invoice XML (CII), the format behind Factur-X and XRechnung, distinguishing it from sibling create_invoice_pdf which produces PDF.

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

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

It explains when to use this tool (for e-invoice XML compliance) and contrasts with create_invoice_pdf via 'same JSON shape plus extra fields', but does not explicitly exclude cases or mention alternatives like parse_einvoice.

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

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

Annotations are all false, so the description carries the full burden. It discloses that the tool returns a download URL valid for 24 hours and computed totals, and explains quota limits and auth requirements. This adds useful behavioral context beyond the annotations, though it could mention error handling or validation constraints.

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

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

The description is two sentences long, front-loaded with the action and resource, and contains no redundant information. Every sentence adds value: first explains what it does, second explains return value and auth/quota constraints. Highly concise and well-structured.

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

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

For a tool with nested objects and no output schema, the description covers the return value (download URL, totals), auth/quota context, and the general input structure. It lacks details on error cases or validation rules, but the schema covers required fields. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is 33%, meaning many nested properties lack descriptions. The tool description groups parameters into 'parties, line items, tax, discount' but does not specify which are required or explain individual fields. The schema itself provides descriptions for many nested properties, so the description adds moderate value but is not comprehensive enough to fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'generate', the resource 'invoice PDF', and the input 'structured JSON (parties, line items, tax, discount)'. It distinguishes from sibling tools like 'create_einvoice_xml' (XML) and 'create_receipt_pdf' (receipts), 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.

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

The description provides context on when to use the tool: for generating invoice PDFs with structured JSON. It mentions quota limits (10/day without key) and the optional auth key for plan quotas. However, it does not explicitly state when NOT to use it or compare directly with siblings like 'create_receipt_pdf', so it slightly lacks exclusion guidance.

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

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

Annotations provide no behavioral insights (all hints false). The description adds that it returns a 24-hour download URL and computed totals, but does not mention side effects, authentication needs, or rate limits. Adequate but not thorough.

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

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

The description is two succinct sentences, front-loading the core purpose and immediately providing key usage note and output format. No filler or redundancy.

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

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

Given the complex nested schema and lack of output schema, the description is minimal. It covers the basic operation and return value but does not fully equip the agent to correctly populate the 'data' object or understand the 24-hour URL lifecycle.

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

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

Schema description coverage is only 33%, and the description does not compensate by explaining the complex nested 'data' object or the 'options' parameter. It merely references the invoice schema, leaving much of the parameter semantics unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a payment receipt PDF from structured JSON, using the same schema as invoices. It distinguishes itself from siblings like create_invoice_pdf and create_einvoice_xml by specifying the receipt type and the input format.

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

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

The description provides a hint to use the `number` field for the receipt number, but lacks explicit guidance on when to use this tool versus alternatives like create_invoice_pdf or parse_einvoice. No when-not or comparative context is given.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns current month's usage, quota, and plan, and explains the authentication requirement. This provides additional behavioral context beyond the annotations.

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

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

The description is two sentences, each serving a clear purpose: first sentence states what the tool returns, second sentence states the authentication requirement. No unnecessary words or repetition.

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

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

The description covers what the tool does and the auth method. With no output schema, it could be more complete by briefly describing the response structure (e.g., fields returned). However, for a simple read operation with a single parameter, it is mostly adequate.

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

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

The schema has 100% coverage for the single parameter (api_key). The description adds that the api_key is optional if sent as a Bearer header, giving extra context about alternative ways to provide it. This enhances understanding beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'document usage, quota, and plan' for the current month, using a specific verb 'Returns' and identifies the resource 'Slipstack API key'. It distinguishes from siblings (create_invoice_pdf, create_receipt_pdf, get_document_schema) which are entirely different operations.

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

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

The description provides clear context that the tool is for retrieving account usage and requires authentication via api_key or Bearer header. While it doesn't explicitly state when not to use it, sibling tools are unrelated, so the usage context is sufficiently clear.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds that it returns plan limits, which are dynamic, and example payload, giving behavioral context beyond annotations. No contradictions.

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

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

Two sentences: first states output, second gives usage advice. Perfectly front-loaded, no wasted words, earns its place.

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

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

For a simple, zero-parameter, read-only tool with good annotations, the description covers what it returns and when to use. No output schema needed; returns are described adequately. Complete.

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

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

No parameters exist, so schema coverage is 100% trivially. Baseline for 0 parameters is 4. Description does not need to add parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns the JSON shape, example payload, and plan limits, and specifically names the sibling tools it supports (create_invoice_pdf, create_receipt_pdf, create_einvoice_xml), distinguishing it from document creation tools.

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

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

Explicitly advises to 'Call this first if you are unsure how to structure a document,' providing clear when-to-use guidance. It could add when not to use (e.g., if schema is already known), but the advice is strong.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by listing output fields (parties, line items, totals, VAT ids, payment details), but does not discuss error handling, size limits, or other behavioral traits.

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

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

The description is two sentences with no redundancy; the first sentence front-loads the main purpose, and the second adds detail. It is efficient but could be slightly more structured.

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

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

Given the tool's complexity (multiple standards, structured output), the description reasonably covers input format, standards, and output fields. However, it lacks mention of error behavior or output schema details, but these are not critical for selection.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds no new semantics beyond restating that the XML is passed as a string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool parses EN 16931 e-invoice XML (CII or UBL) into normalized invoice JSON, clearly distinguishing it from sibling tools that create 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.

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

The description implies when to use the tool (when you have an e-invoice XML and need structured JSON), but does not explicitly state when not to use it or mention alternatives like create_einvoice_xml.

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