Skip to main content
Glama

Save income

save_income

Create or edit income ACCOUNTING ENTRIES (category, client, tax); to change the BANK LINE itself (its description, ignored flag or notes) use update_transaction, and to record a payment against an invoice prefer record_document_payment. When the bank line that paid the invoice already has its own income (its $incomeids in list_transactions), settle by saving that income with id = the income and accountid = the invoice id instead, so the payment is not counted twice. For one, send its fields inline (pass an id to update, omit to create). To create/update many at once, send an items array — 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. Use create_income_expenses_bulk to add income and expenses together in one transaction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoIncome id. Present → update that income; omit → create a new one.
dateNoIncome date (ISO 8601).
nameNoDisplay name / description of the income.
alertNoAlert/reminder note to surface on this income.
itemsNoVector of income 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 income is one line of a split transaction.
amountNoUnit amount before quantity/tax, in the record's currency.
clientNoClient id, or an exact client name to resolve (see list_clients).
methodNoPayment method as free text (e.g. "cash", "card", "eft") — no fixed set.
unlinkNoId of a currently-linked invoice/asset to detach from this income. Ignored unless it is an invoice/asset id.
assetidNoAsset id to link this income to (e.g. proceeds from an asset).
groupidNoGroup id linking split lines of one real-world transaction together.
productNoProduct id this income is for (see list_products).
categoryNoIncome category name; forced to "Sales" when linked to an invoice.
currencyNoISO 4217 currency code (e.g. "ZAR", "USD"). Defaults to the business currency.
accountidNoChart-of-accounts income category account id, or an exact account name to resolve (see list_accounts).
invoiceidNoInvoice id this income pays toward.
incometypeNoIncome type/classification label.
exchangerateNoManual FX rate to the business base currency; omit to use the stored/auto rate.
baseaccountidNoBase/control account id override; rarely needed — defaults from the category.
transactionidNoBank transaction id to reconcile this income against.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only give the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds substantial context beyond that: the batch is one all-or-nothing transaction with a single ledger recompute, `id` present updates and omitted creates, and category is forced to "Sales" when invoice-linked. The double-counting rule is genuinely non-obvious behavior an agent could not infer.

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 front-loaded: purpose, then alternatives, then the settlement edge case, then single-vs-batch mechanics. Every sentence carries information; it is slightly long, but no sentence is filler.

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 22-parameter mutation tool with no output schema, the description covers the create/update/batch semantics and cross-tool routing well. It does not explain what the call returns or validation failure behavior, which is a minor residual gap.

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 per-parameter text is already documented (baseline 3). The description goes further by explaining the id/items create-vs-update contract and the non-obvious `accountid`=invoice-id settlement trick, adding meaning beyond 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 pair (create/edit) and resource (income accounting entries), and immediately distinguishes itself from update_transaction (bank line) and record_document_payment (invoice payments). An agent can pick the right tool without opening a 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?

Explicitly names alternatives and selection conditions: use update_transaction for bank-line edits, record_document_payment for invoice payments, create_income_expenses_bulk for combined income+expense batches. It even handles the edge case where the bank line already carries its own income (use `id`=income, `accountid`=invoice id) to avoid double-counting.

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