Skip to main content
Glama

Save expense

save_expense

Record spending that is NOT settling a document, or edit an existing expense's ACCOUNTING ENTRY (category, supplier, tax); to pay a bill or PO prefer record_document_payment (one document) or settle_bills (several), and to change the BANK LINE itself (its description, ignored flag or notes) use update_transaction. For one expense, send its fields inline (pass an id to update, omit to create). To create/update many at once, send an items array — this is preferred over repeated calls: the whole batch is one all-or-nothing transaction with a single ledger recompute. Each item with an id updates; each without creates. To pay a bill / purchase order / GRN, set accountid to that document's id. Use create_income_expenses_bulk to add income and expenses together in one transaction.

Input Schema

NameRequiredDescriptionDefault
aiNoInternal: set when the expense was produced by AI enrichment.
idNoExpense id. Present → update that expense; omit → create a new one.
dateNoExpense date (ISO 8601).
nameNoDisplay name / description of the expense.
paidNoWhether this expense has been paid.
alertNoAlert/reminder note to surface on this expense.
itemsNoVector of expense objects to create/update in one all-or-nothing batch. Preferred over repeated calls. Each item with an id updates; each without creates.
notesNoFree-text notes.
splitNoWhether this expense is one line of a split transaction.
totalNoTotal including quantity. Used only when amount is omitted: amount becomes total ÷ quantity, and must come to whole cents. If amount is also sent, amount wins.
amountNoUnit amount before quantity/tax, in the record's currency.
methodNoPayment method as free text (e.g. "cash", "card", "eft") — no fixed set.
unlinkNoPass the id of a currently-linked transaction/document to detach it.
groupidNoGroup id linking split lines of one real-world transaction together.
taglistNoTag ids to set on this expense (replaces the existing set).
currencyNoISO 4217 currency code (e.g. "ZAR", "USD"). Defaults to the business currency.
paiddateNoDate payment was made (ISO 8601).
quantityNoNumber of units.
salestaxNoWhether sales tax (VAT) applies. May also be an array of salestax refs.
supplierNoSupplier id, or an exact supplier name to resolve (see list_suppliers).
accountidNoChart-of-accounts account id (or an exact account name to resolve) used to categorise this expense (see list_accounts). ALSO how a payment is recorded against a purchase document: set this to the bill / purchase order / GRN document id (cont-…) and the expense counts toward that document's paid amount, inheriting the document's accounting category. This is how a money-out document is settled via a pre-existing expense. To record a fresh payment against a bill / purchase order / GRN, prefer record_document_payment — it now handles both directions, minting the accountid-linked expense for you from the payment details. To refund a customer, set this to their id (cli-…): it posts once to Receivables, tagged to them, with no VAT.
exchangerateNoManual FX rate to the business base currency; omit to use the stored/auto rate.
showquantityNoWhether to display the quantity column on the document.
bankaccountidNoBank account id the money moved through (see list_accounts).
baseaccountidNoBase/control account id override; rarely needed — defaults from the category.
transactionidNoBank transaction id to reconcile this expense against.
salestaxamountNoExplicit sales tax amount; used instead of the percentage when salestaxuseamount is true.
salestaxpercentNoSales tax rate as a percentage (e.g. 15 for 15%).
salestaxuseamountNoWhen true, use salestaxamount as the tax figure instead of computing from the percentage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / accountid / description
      Previous value: -"Chart-of-accounts account id (or an exact account name to resolve) used to categorise this expense (see list_accounts). ALSO how a payment is recorded against a purchase document: set this to the bill / purchase order / GRN document id (cont-…) and the expense counts toward that document's paid amount, inheriting the document's accounting category. This is how a money-out document is settled via a pre-existing expense. To record a fresh payment against a bill / purchase order / GRN, prefer record_document_payment — it now handles both directions, minting the accountid-linked expense for you from the payment details."New value: +"Chart-of-accounts account id (or an exact account name to resolve) used to categorise this expense (see list_accounts). ALSO how a payment is recorded against a purchase document: set this to the bill / purchase order / GRN document id (cont-…) and the expense counts toward that document's paid amount, inheriting the document's accounting category. This is how a money-out document is settled via a pre-existing expense. To record a fresh payment against a bill / purchase order / GRN, prefer record_document_payment — it now handles both directions, minting the accountid-linked expense for you from the payment details. To refund a customer, set this to their id (cli-…): it posts once to Receivables, tagged to them, with no VAT."
    • addedInput schema / properties / items / items / properties / accountid / description
      Added value: +"Chart-of-accounts category account id, or an exact account name to resolve (see list_accounts). Set to a bill / purchase order / GRN document id (cont-…) to record this expense as a payment against that document. Set to a customer id (cli-…) to record a refund paid to that customer: it posts once to Receivables, tagged to the customer, with no VAT, and draws down their credit balance."
  2. Changed2 schema fields changed
    • changedInput schema / properties / items / items / properties / total / description
      Previous value: -"Total amount including quantity; overrides amount×quantity if set."New value: +"Total including quantity. Used only when amount is omitted: amount becomes total ÷ quantity, and must come to whole cents. If amount is also sent, amount wins."
    • changedInput schema / properties / total / description
      Previous value: -"Total amount including quantity; overrides amount×quantity if set."New value: +"Total including quantity. Used only when amount is omitted: amount becomes total ÷ quantity, and must come to whole cents. If amount is also sent, amount wins."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds real behavior: the batch form is one all-or-nothing transaction with a single ledger recompute, and per-item id presence determines create vs update. What it does not cover is failure behavior beyond all-or-nothing (validation errors, whether partial-permission failures abort the batch) or what the call returns, so it falls short of a 5 for a 29-parameter mutation tool.

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 primary exclusion (NOT settling a document) and the sibling routing before the mechanical how-to. It is dense but almost every clause carries routing or mode information; the parenthetical about `id` appears twice (top-level and items) and the sentence structure is long, which costs a point.

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 29-parameter create/update tool with no output schema, the description supplies the decision-critical context: which sibling to use, inline vs batch, update vs create, and the `accountid` overloading. It omits what a successful save returns (id of the created expense?) and any permission or locked-period constraints, which matters given there is no output schema.

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 baseline is 3, but the description adds routing semantics the schema presents only per-field: the inline-vs-`items` mode split, the create-vs-update meaning of `id` at both levels, and the overloaded meaning of `accountid` (category vs cont-… document vs cli-… refund), which is a genuinely tricky parameter. It still delegates all the other 25 field meanings to the schema.

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 description names a specific verb and resource (record/edit an expense's accounting entry) and immediately bounds the scope: spending that is NOT settling a document. It then explicitly contrasts itself with record_document_payment, settle_bills, update_transaction and create_income_expenses_bulk, so an agent can route correctly without opening the schemas of five tools.

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 when-to-use and when-not-to-use rules: use this for spending that is not settling a document, use record_document_payment for one bill/PO, settle_bills for several, update_transaction for the bank line itself. It also states a preference rule (batch `items` over repeated calls) and a mode rule (pass `id` to update, omit to create). Little is left to inference.

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