Skip to main content
Glama

Save expense

save_expense

Create or update expense(s). 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 update_expenses_bulk when you only need to recategorise/relink existing expenses, or 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 amount including quantity; overrides amount×quantity if set.
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. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds concrete behavioral context: inline vs items batching, single all-or-nothing transaction with one ledger recompute, and id-based create/update semantics. It does not detail error/validation behavior, but the annotations already establish the mutation profile, so this is a strong but not exhaustive disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, all substantive and well ordered: core operation, batching, payment routing, and sibling alternatives. No filler and no repetition of schema boilerplate; every sentence earns its place.

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 write tool with rich schema descriptions, the description covers the essential operational context: single vs batch, atomicity, ledger recompute, and payment settlement via accountid. It stops short of describing return shape or error behavior, but the schema plus description give an agent enough to select and invoke it correctly.

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%, with every parameter already documented in the schema, including the detailed accountid payment semantics and the items batch description. The tool description reinforces the important accountid and items behaviors but does not introduce new parameter-level facts beyond what the schema already carries, so the high-coverage baseline 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 description opens with a precise verb and resource ('Create or update expense(s)') and immediately distinguishes the tool from siblings by naming update_expenses_bulk, create_income_expenses_bulk, and record_document_payment. An agent can tell when save_expense is the right tool without opening 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?

It gives explicit routing: prefer the items array over repeated calls, use update_expenses_bulk for recategorising/relinking, and use create_income_expenses_bulk for mixed income/expense transactions. It also gives the exact accountid pattern for paying bills/POs/GRNs, so the when-to-use guidance is unambiguous.

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