Simpler.Asia

statement_pdf

Make the PDF of a client's statement of account (the same page statement_prepare's document_path shows), printed on A4 with the business's fonts, brand colours and logo, and kept, so asking again for an unchanged statement returns the stored file (cached: true) without printing it again. It prepares a file and sends nothing. Returns version, pdf_path (downloads while signed in) and closing_balances, and download_url when signed links are on; while they are off, download_url_unavailable says why and pdf_path still works. Refusals: a client_id that is not one of your clients is NOT_FOUND (find it with invoice_client_search or invoice_client_list); a date not written YYYY-MM-DD, a to after today, a from after to, or a period longer than 366 days is VALIDATION_ERROR naming the field; a client with more than 2000 issued invoices is PAYLOAD_TOO_LARGE SIMPLER_SALES_STATEMENT_TOO_LARGE (sales_receivables still ages them). More than 50 new PDFs (invoices and statements together) 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, storage not set up, 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": {
      "client_id": "<client_id>"
    },
    "name": "statement_pdf"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day of the period, YYYY-MM-DD in the business's time zone, today at the latest. Default: today.
`from`	No	First day of the period, YYYY-MM-DD in the business's time zone. Default: the first day of the month of to.
`client_id`	Yes	The client's id, from invoice_client_search (by name) or invoice_client_list.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes far beyond the single readOnlyHint=false annotation: caching semantics, a 50-PDF/24h cap with RATE_LIMITED and retry_after, SERVICE_UNAVAILABLE reasons during printing failures, FORBIDDEN for read-only tokens/viewers before any work, and the 2000-invoice PAYLOAD_TOO_LARGE path. The only real gap is that 'readOnlyHint: false' side effects aren't spelled out as stored artifacts persisting beyond the call, though the caching sentence implies it.

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?

Front-loaded with the core purpose and outcome, then error/limits in descending priority. It is a long single paragraph with heavy semicolon chaining, but nearly every clause carries operational information (cache, quota, fallbacks) rather than filler.

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 covers the return shape (version, pdf_path, closing_balances, download_url and download_url_unavailable) and the auth/error envelope for a mutating, rate-limited, storage-backed tool. An agent could call this correctly and interpret its responses from the description alone.

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 the formal constraint set is already documented; the description still adds value by restating the validation rules in error terms (date not YYYY-MM-DD, to after today, from after to, >366 days) and by pointing client_id lookups at invoice_client_search / invoice_client_list. Marginal addition, hence 4 rather than 5.

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?

Opens with a specific verb+resource ('Make the PDF of a client's statement of account') and immediately anchors it to the sibling statement_prepare's document_path so the agent can tell the two apart. It also implicitly separates itself from invoice_pdf by naming the statement-of-account artifact.

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 the alternative ('the print-ready page stays the fallback', the statement_prepare page) and when caching makes a repeat call a no-op (cached: true, nothing re-printed). It also states what the tool does NOT do ('sends nothing'), which is the key routing decision against invoice_share/message-prep tools.

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?