Skip to main content
Glama

invoice_reissue

Voids a 'sent' invoice with no money on it and reissues it under the next number: 'sent', dated today, same client, currency, notes, terms and lines, tax on today's rules, the old days to pay unless due_date is sent. A foreign-currency sg_gst invoice issued before today needs fx_rate_to_sgd and fx_rate_date for today unless its rate is dated today. The old one is cancelled, its client link stops working, both trails link them. Paid, part-paid, credited or written-off invoices refuse: correct them with a credit note (invoice_adjustment_record). When present, the second content block is the new invoice as copy-ready text. Nothing is sent. NEXT: invoice_share only if the user asks for a link.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
idNoThe invoice to cancel and issue again (invoice_list shows ids); its invoice_number works too.
reasonNoWhy the invoice is reissued, kept in both invoices' activity (max 500).
due_dateNoEpoch milliseconds of the new due date, today or later. Omit it to give the new invoice the old one's days to pay, counted from today.
fx_rate_dateNoThe date the fx rate is for, YYYY-MM-DD. Send with fx_rate_to_sgd.
fx_rate_to_sgdNosg_gst invoices in a currency other than SGD: Singapore dollars per 1 unit of the invoice currency for today, the new invoice's date of supply ("1.3502", up to 6 decimals, from MAS, a local bank, Bloomberg, Reuters or Oanda). Send with fx_rate_date. Needed when the invoice was issued before today and its rate is not dated today; otherwise the old rate, if any, is kept.
invoice_numberNoAlias of id — the invoice's own number.
fx_rate_to_sgd_ppmNofx_rate_to_sgd in millionths (1.3502 → 1350200), instead of fx_rate_to_sgd. Send with fx_rate_date.
expected_updated_atNoOptional compare-and-set guard: the updated_at you last read. A mismatch returns CONFLICT and changes nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the annotations, it discloses what happens to the old record (cancelled, its client link stops working, both trails link them), how tax and fx rates are recomputed, the conditional fx_rate_to_sgd/fx_rate_date requirement, and what the second content block returns. The only nuance is that 'cancelled' plus 'client link stops working' is a substantial side effect while destructiveHint=false; the description compensates by disclosing it explicitly rather than hiding 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?

The action and its preconditions are front-loaded and nearly every sentence carries information: carry-over fields, fx rule, refusal routing, return block, next step. It is, however, a dense run-on block of sentence fragments that could be split into scannable lines for faster selection.

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?

For an 8-parameter, no-output-schema mutation-and-reissue tool, the description covers the eligibility gate, the field carry-over, tax and fx recomputation, the refusal path, the shaped return ('second content block ... copy-ready text'), and the recommended follow-up. Nothing an agent needs in order to call it correctly or refuse correctly is missing.

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%, so the schema already documents id, reason, due_date, fx_rate_* and expected_updated_at, including the 'omit it to keep old days to pay' rule and the fx-date condition. The description restates those rules in workflow terms but adds no syntax, format or fallback information the schema lacks, so baseline 3 applies.

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 opening clause states a specific compound action on a specific resource: void a 'sent' invoice with no money on it and reissue it under the next number. It then enumerates exactly what carries over (client, currency, notes, terms, lines, tax, days to pay), which no sibling tool does and which separates it from invoice_update, invoice_create and invoice_adjustment_record.

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?

Gives explicit preconditions ('sent' with no money on it), explicit exclusions with a redirect ('Paid, part-paid, credited or written-off invoices refuse: correct them with a credit note (invoice_adjustment_record)'), and an explicit next step ('invoice_share only if the user asks for a link'). It also states a negative boundary ('Nothing is sent').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources