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

TableJSON 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.
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 / 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."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the real disclosure burden and does it: the batch path is 'one all-or-nothing transaction with a single ledger recompute', `id` present means update versus absent means create, and setting accountid to a document id makes the expense count toward that document's paid amount. These are non-obvious transactional and linking semantics that go well beyond the annotations.

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-loads the core scope/not-scope distinction and routing alternatives before the mechanics, and every sentence carries information. However it runs long and repeats itself — 'each item with an id updates; each without creates' appears twice, and the accountid-to-bill explanation is stated in both the description and the schema.

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 mutation tool with no output schema and only minimal annotations, the description covers the critical ambiguities: create vs update, single vs batch atomicity, and how to settle documents. Reasonably complete, though it says nothing about permissions/authorisation needs or failure behaviour for a rejected batch.

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 description coverage is 100%, so the baseline is 3, but the description adds conceptual meaning the schema states only per-field: the inline-fields vs `items` array choice, the create/update switch on `id`, and the accountid-as-document-id payment linkage. It does not explain the tax fields or the total-vs-amount precedence, which are left entirely 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?

States a specific verb+resource and immediately bounds the scope with a negative: 'Record spending that is NOT settling a document, or edit an existing expense's ACCOUNTING ENTRY'. It names the exact sibling tools that handle the excluded cases (record_document_payment, settle_bills, update_transaction), so an agent can distinguish this tool from its neighbours without opening any schema.

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 guidance with named alternatives: 'to pay a bill or PO prefer record_document_payment (one document) or settle_bills (several)', 'to change the BANK LINE ... use update_transaction', and 'Use create_income_expenses_bulk to add income and expenses together'. It also chooses between the single-item and batch invocation modes ('this is preferred over repeated calls').

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