Skip to main content
Glama

invoice_update

Edits an invoice's header fields and status. status 'paid' cannot be set here — it derives from the payment ledger, so call invoice_payment_record instead. Status moves are machine-checked (draft to sent/cancelled, sent to cancelled); cancelled is terminal and a paid invoice never reopens by hand. A move to 'sent' stamps sent_at automatically when omitted, and currency is ledger-locked once any live payment exists. An agent's change to notes or payment_terms on an issued invoice waits for the owner's approval; on a draft it does not. tax_scheme and prices_include_tax are fixed at creation, as is the tax rate. NEXT: invoice_payment_record to settle money, invoice_read to verify.

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_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe invoice id (invoice_list shows them).
notesNo
statusNo
paid_atNo
sent_atNo
currencyNo
due_dateNo
cash_saleNo
client_idNo
source_idNo
issue_dateNo
tax_schemeNo
source_typeNo
fx_rate_dateNoThe date the fx rate is for, YYYY-MM-DD. Send with fx_rate_to_sgd.
tax_rate_bpsNo
payment_termsNo
ready_to_sendNoWhen the user wants to give the client a draft invoice (forward it, send it, get it ready): true issues it (status 'sent') and returns handoff, invoice_handoff's result: the client link, the PDF and the prepared message. Refused for a paid or cancelled invoice, or one with nothing owed. Nothing is sent: the user forwards it.
fx_rate_to_sgdNosg_gst invoices in a currency other than SGD: Singapore dollars per 1 unit of the invoice currency as a decimal string, up to 6 decimals ("1.3502"), from a source IRAS accepts (MAS, a local bank, Bloomberg, Reuters, Oanda) for the date of supply. Send with fx_rate_date. Or send fx_rate_to_sgd_ppm (1.3502 → 1350200).
invoice_numberNo
payment_methodNo
fx_rate_to_sgd_ppmNo
prices_include_taxNo
expected_updated_atNoOptional compare-and-set guard: the updated_at you last read. Mismatch returns CONFLICT with the current value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ready_to_send
      Added value: +{
      +  "description": "When the user wants to give the client a draft invoice (forward it, send it, get it ready): true issues it (status 'sent') and returns handoff, invoice_handoff's result: the client link, the PDF and the prepared message. Refused for a paid or cancelled invoice, or one with nothing owed. Nothing is sent: the user forwards it.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing a machine-checked state machine (draft to sent/cancelled, sent to cancelled), a terminal state, an auto-stamping rule for sent_at, currency locking once live payments exist, immutability of tax_scheme/prices_include_tax/tax_rate, and an owner-approval gate for notes/payment_terms on issued invoices. These are consequential behaviors an agent could not infer from readOnlyHint=false, destructiveHint=false, idempotentHint=false.

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 disciplined: rules, exceptions, and next steps are front-loaded with no filler sentences. The single paragraph is information-packed to the point of being hard to scan, and a light split into 'rules' versus 'follow-ups' would help.

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

Completeness4/5

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

For a 23-parameter mutation with no output schema and no annotations covering business rules, the description supplies the state machine, approval gate, and locking semantics an agent needs. It never states whether this is a partial update (omitted fields preserved versus cleared), which is the main remaining gap for a tool this wide.

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?

With only 22% schema coverage the description must compensate, and it targets the highest-risk parameters: status (explaining that 'paid' is in the enum but rejected here), currency's ledger lock, the immutable tax fields, tax_rate, sent_at auto-fill, and the approval-gated notes/payment_terms. The long tail remains unexplained — cash_sale, source_type, paid_at, client_id, and the integer timestamp semantics of due_date/issue_date get no guidance.

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 and resource ('Edits an invoice's header fields and status') and immediately scopes what it does not do, naming invoice_payment_record for paid status. An agent can distinguish it from invoice_create, invoice_read, and invoice_payment_record without inspecting schemas.

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 routes away from this tool for settlement ('call invoice_payment_record instead') and names a verification follow-up (invoice_read). The 'NEXT:' line gives concrete sequencing, and the approval note tells the agent that some edits will not take effect immediately.

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