Simpler.Asia

invoice_pdf

Make the PDF of an issued invoice (or of its receipt once paid): the same document as its print-ready page, printed on A4 with the business's fonts, brand colours and logo, and kept, so asking again for an unchanged invoice returns the stored file (cached: true) without printing it again. Totals are the stored figures (the same numbers invoice_read gives). It prepares a file and sends nothing. Returns version, pdf_path (downloads while signed in), and download_url when signed links are on; while they are off, download_url_unavailable says why and pdf_path still works. Refusals: a draft is refused CONFLICT SIMPLER_SALES_PDF_NOT_ISSUED (issue it first with invoice_update status 'sent'); a cancelled invoice is refused CONFLICT SIMPLER_SALES_PDF_CANCELLED; an unknown id is NOT_FOUND (find it with invoice_list); more than 50 new PDFs in 24 hours is refused RATE_LIMITED SIMPLER_SALES_PDF_DAILY_CAP (wait retry_after seconds; stored PDFs still download); when PDF printing is unavailable (no browser here, printer busy or failing) it answers SERVICE_UNAVAILABLE with a reason_code and retry_after, and the print-ready page stays the fallback. A read-only token or a viewer is refused FORBIDDEN before anything is made. Free.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "invoice_pdf"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The invoice's id, from invoice_list or invoice_read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only provide readOnlyHint=false, so the description carries the burden and does so richly: caching (cached: true), it 'sends nothing', returns version/pdf_path/download_url, permission requirements (FORBIDDEN for read-only/viewer), a 50-per-24h rate limit, and distinct error codes with retry guidance.

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?

Dense but front-loaded: purpose first, then behaviors, returns, and refusals. Every clause carries value (cache behavior, return fields, error codes), though the single long paragraph is heavier than strictly necessary.

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?

With no output schema, the description fully explains return values (version, pdf_path, download_url, download_url_unavailable) and enumerates all refusal scenarios. An agent has everything needed to call it correctly and interpret failures.

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 coverage is 100% and the single 'id' param is fully documented in the schema. The description only restates the id's source (invoice_list or invoice_read), adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb+resource ('Make the PDF of an issued invoice (or of its receipt once paid)') and clarifies it's the same document as the print-ready page with branding, caching, and that totals match invoice_read. This distinguishes it from siblings like statement_pdf and sales_document_show.

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 says when to use and when not: drafts must be issued first via invoice_update status 'sent', cancelled invoices are refused, unknown ids resolved via invoice_list. Also notes the print-ready page as fallback when printing is unavailable.

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

All Simpler.Asia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?