Skip to main content
Glama

Save document

save_document

Create or update document(s) of ANY kind — all eight document types are supported here, not just invoices: invoice, quote, recurring, debit_note, credit_note, purchase_order, bill, grn (the type enum below documents what each one is for). Credit notes and debit notes are raised through this same tool — pass the matching type and, where it relates to an existing document, its id as parent. For one document, send its fields inline (pass an id to update, omit + include type 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 and must include type. This manages the document as a whole; to edit individual line items on an existing document use update_document_item (or update_document_items_bulk).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoDocument id. Present → update that document; omit → create a new one (must include type).
dateNoDocument date (ISO 8601).
nameNoDisplay name / title of the document.
sentNoWhether the document has been sent to the recipient.
typeNoThe kind of document. One of: invoice — Bill a customer for goods or services. Money in.; quote — A pre-sale estimate for a customer; becomes money in once accepted.; recurring — An invoice that repeats on a schedule. Money in.; debit_note — Reduce what you owe a supplier (offsets a bill). Money in.; credit_note — Refund or reduce a customer's invoice. Money out.; purchase_order — Order goods or services from a supplier. Money out.; bill — A supplier's bill that you owe. Money out.; grn — Record stock received against a purchase order. Money out..
itemsNoVector of document objects to create/update in one all-or-nothing batch. Preferred over repeated calls. Each item with an id updates; each without creates and must include type.
notesNoFree-text notes.
clientNoClient id, or an exact client name to resolve (see list_clients).
lockedNoWhether the document is locked against further edits.
numberNoDocument number; auto-generated if omitted.
parentNoId of the parent document this one derives from (e.g. the invoice a credit note relates to).
contactNoContact id, or an exact client/supplier name to resolve (client for money-in document types, supplier for money-out; see list_clients / list_suppliers).
duedateNoPayment due date (ISO 8601).
messageNoMessage shown to the recipient on the document.
settledNoWhether the document has been fully settled/paid.
showvatNoWhether to display the VAT/sales-tax line on the document.
acceptedNoWhether the recipient has accepted the document (e.g. a quote).
currencyNoISO 4217 currency code (e.g. "ZAR", "USD"). Defaults to the business currency.
shippingNoShipping amount added to the document total.
showbankNoWhether to display the business's banking details on the document. Defaults to true on create; only shown to recipients on money-in documents (invoices, quotes).
supplierNoSupplier id, or an exact supplier name to resolve (see list_suppliers).
accountidNoBank/ledger account id the payment moved through (see list_accounts).
descriptionNoFree-text description of the document.
showdepositNoWhether to display the deposit line on the document.
accepteddateNoDate the document was accepted (ISO 8601).
paymentnotesNoFree-text payment instructions shown on the document.
showdiscountNoWhether to display the discount line on the document.
showshippingNoWhether to display the shipping line on the document.
baseaccountidNoBase/control account id override; rarely needed — defaults from the category.
depositamountNoExplicit deposit amount; used instead of the percentage when deposituseamount is true.
accountpaymentNoAmount paid against the document at save time.
depositpercentNoDeposit as a percentage of the total.
discountamountNoExplicit discount amount; used instead of the percentage when discountuseamount is true.
discountpercentNoDiscount as a percentage of the subtotal.
showpaymentlinkNoWhether to include an online payment link on the document.
deposituseamountNoWhen true, use depositamount instead of the percentage.
discountuseamountNoWhen true, use discountamount instead of the percentage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations provide only readOnlyHint=false and destructiveHint=false, which already indicate mutation but not destructiveness. The description adds valuable behavioral context: 'the whole batch is one all-or-nothing transaction with a single ledger recompute' and explains the create/update distinction based on id presence. It also notes that batch is atomic. While it doesn't cover error handling or success returns, it adds meaningful transparency beyond the sparse annotations, so a 4 is warranted.

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?

The description is concise given the tool's complexity, spanning about five sentences. It front-loads the core scope (all document types) and then flows logically through batch vs single, create vs update, and sibling tool routing. There is no fluff or repetition of schema details. It could be slightly more structured into paragraphs for readability, but it earns its length.

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

Completeness5/5

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

With 37 parameters, no output schema, and many sibling tools, this description covers all critical decision points: single vs batch, create vs update, parent relationships for notes, and explicit alternatives for line-item editing. It addresses the whole-document scope and gives routing guidance. The schema handles parameter-level detail, and the description bridges the gaps, making it complete for an agent to invoke correctly.

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 each parameter already has a description. The tool description does not repeat those but adds essential inter-parameter semantics: how `parent` relates notes to existing documents ('where it relates to an existing document, its id as parent'), the batch behavior via `items`, and the requirement that creating items without id must include `type`. This significantly enriches understanding beyond the schema, justifying a 4.

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 clearly states the tool's scope: 'Create or update document(s) of ANY kind' and enumerates all eight document types, distinguishing it from invoice-only tools. It uses a specific verb (create/update) and resource (document), and explicitly contrasts with siblings like update_document_item, making its purpose unambiguous. The batch capability and parent logic further clarify what it does.

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?

The description explicitly says when to use this tool vs alternatives: 'This manages the document as a whole; to edit individual line items... use update_document_item (or update_document_items_bulk).' It also prescribes when to use batch (items array preferred over repeated calls) and when to create vs update (id present vs omitted). These are clear, actionable usage directives with no ambiguity.

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